Drupal 7 + nginx + memcached получается быстрее чем с Varnish, так же памяти меньше расходуется. Точные замеры не делал. Как настроить, написал топиком выше.
Тут явно I/O просаживается, а не drupal. Помониторьте работу БД и I/O, ясное дело что Redis даст прирост. Хостера поменяйте и будет счастье, так как с 2014 года и даже раньше все вменяемые хостеры перешли на SSD. user_load грузит не просто пользователя в виде одной записи из БД, а все его поля которые хранятся в отдельных таблицах для поддержки версионности. Т.е. для загрузки 1000 пользователей нужно сделать раз в 5 больше запросов (они всё же быстрее выполняются чем если бы всё сериализовано хранилось в одной таблице) к б.д. и база мрёт на I/O. Поэтому Drupal тут ни при чём, статья любопытная, но не о чём.
Внутренний продукт :), собираем данные финансовой статистики на основе этого генерируем прогнозы. Краулер собирает данные и отправляет их в ZeroMQ, который раскидывае их на несколько серверов в кольце для дубликации данных (на случай если сервер умрёт — останется копия на другом сервере, на подобии как apache cassandra но с возможностью цеплять Hadoop отдельно к каждому серверу). Отдельно Hadoop — генерирует прогнозы обрабатывая данные из Firebird, при этом отдельно словари храним в Redis при расчётах. В принципе в такой схеме важно уже было удобство работы с базой данных из языка программирования на котором писал система (у нас freepascal + php), а производительность упиралась в производительность i/o, а не базы данных (Firebird или MySQL, PostgreSQL).
Спасибо. Ещё бы подробнее бы рассказали про HL на Firebird. Покорила база своей надёжностью, а в купе с Hadoop + ZeroMQ (кластер управляется через очереди) на нескольких серверах получается неплохо выжимать и по производительности.
Есть ещё более радикальные способы оптимизации от установки Varnish до варианта как описан в статье «Отдаём кэш анонимов без поднятия бэкэнда. Drupal 7 + nginx + memcached.» (ищется в любой поисковой системе). В таком случае прирост в скорости будет ещё больше.
>>> с 51-го запроса цена составит $0,035 за штуку
>>> непосредственно покупка/бронирование авиабилета осуществляется через GDS
Добавьте пожалуйста ссылку на страницу где описаны проценты отчислений за продажу билетов, для полноты статьи. Иначе из статьи не получается понять, где же именно «бизнес по продаже авиабилетов не вставая с дивана» так как описан только поиск билетов не вставая с дивана.
Если модулей очень много, то с APC есть тарбл что опкод страницы начинает подходить под 150 мегабайт, который долго грузится с HDD в память, особенно если это многострадальный HDD замученный раздачей картинок заодно. Это очень много, ещё на 5.3 стал использовать вместо APC — eAccelerator. PHP 5.5 c OPcach и быстрее и памяти меньше ест.
Тут поддержу Влада Савицкого, Вы решили сделать анитипатерн магазина и я счастлив, что у Вас получилось.
1. Хорошо, что не стали с нуля писать свою CMS, а взяли Drupal Commerce — проект в который вложено 15 млн. $ с кучей модулей из коробки и огромной россыпью в репозитарии. Плохо, что скорее всего вы половину модулей не выключили (если они Вам не нужны), не взяли более лёгкий дистрибутив Drupalife Store.
2. Если пользуете Российский хостинг, то вторые грабли тормознутость HDD, DigitalOcean или подобный хостинг с SSD это ускорение на 1000% (модулей много читаются они долго).
3. PHP 5.5 c OPcach именно только так и никаких других акселераторов — прирост скорости в несколько раз в отличие от голого PHP 5.3 (а если он с APC то там акселерация начинает борется с недостатком памяти сервера — но так уж работает именно APC).
4. SOLR — отказ от него вторые крупные грабли так как он именно для этого предназначен. После этого следует что Вы строите свой HighLoad.
5. Своя entity — всё в одной таблице, что исключает JOINы (внимание нужно только для HighLoad и только когда без этого нельзя обойтись). Третьи грабли на которые Вы наступили. Но не нужно писать entity для каждого материала, только для тех, чьи поля постоянно используете. У магазина — поиск это обычно до 70% просмотренных страниц, у тематических сайтов обратное.
6. Есть модуль Database logging — если не всё хорошо с верстальщиками и т.п. может генерировать большой объём лога об ошибках в базу данных, база от этого тоже начинает тормозить переваривая большой insert перед показом каждой страницы. Поэтому нужно или исправить все ошибки, что падают в лог или отключить модуль. Правда об подозрительных дествиях на сайте Вы перестаёте быть настолько осведомлены после отключения модуля.
7. Ладно раз используете поля для тяжёлых выборок, то если не используете ревизии нод, то поставьте Field SQL norevisions — пусть база будет меньше, а диску легче (внимание нужно только для HighLoad и только когда без этого нельзя обойтись).
8. Entity cache + Memcache API and Integration или Redis и пусть Ваш кэш материалов живёт в памяти сервера а не на диске. А для магазинов ещё и commerce_entitycache обязателен.
9. Подключение модуля memcached для кэша всего остального в памяти это правильно.
10. Про cache_form хорошо Spleshka написал в статье: «Система кэширования Drupal 7. Часть первая: сегменты кэша», там всё от и до от того как и заканчивая зачем.
11. Просматривайте чего генерит views (у него на странице со списком представлений есть вкладка настройка и там галочка — показывать SQL), иногда то, что накидают через UI (например 500 связанных полей (реальный пример)) генерит не реальный JOIN.
1. Как попасть на курсы и сколько они стоят если они платные?
2. Будет ли онлайн вариант обучения?
3. Интересно ли сотрудничать с лекторами в этой области?
Хочется и поучиться, но удаленно. И есть, что рассказать студентам по систем понимающих текст (разрабатывал систему понимающую текст и отвечающую по нему на вопросы). С онлайн обучением просто хочется поспособствовать хорошему начинанию.
Летом 2009 мы с товарищем предлагали вложиться «Яндексу» в подобную технологию. Но только наш вариант технологии ещё мог сортировать письма по тематикам (не на основе вхождения слов, а смысла), искать по смысловому вхождению (письмо от Ивана про какую то машину (а в письме — мой зверь опять ест масло и недавно колёса поменял)) ну и до кучи смысловой спам фильтр предлагали.
К концу 2010 плюшки были в почте, а стартап превратился в под-проект Яндекса. Но к сожалению Яндекс на тот момент только арендовал готовые технологии. А инвесторы в России вкладываются только в готовые проекты.
Так, что есть что улучшать ещё в Яндекс.Почте, давно ей пользуюсь и жду дальнейшего её развития.
Ребята мы ждём от Вас ещё больших прорывов, мы с Вами!!!
Тоже штатная, правда апарат один из первых белых в России, поэтому возможно глюк конкретного экземпляра тока с таким глюком вроде как не меняют аппараты.
Главное чтоб не зависал после каждого принятого звонка как мой Sony Xperia S (lt26i) — а то флагман, флагман, но музыку послушал или принял звонок — перегрузись а то зависнет. Если бы не дизайн давно пылился бы в шкафу.
Для кэширования статей в Drupal рекомендую статью: Отдаём кэш анонимов без поднятия бэкэнда. Drupal 7 + nginx + memcached — drupalace.ru/lesson/otdayom-kesh-anonimov-bez-podnyatiya-bekenda-drupal-7-nginx-memcached от нашего общего товарища с ником: Spleshka.
>>> непосредственно покупка/бронирование авиабилета осуществляется через GDS
Добавьте пожалуйста ссылку на страницу где описаны проценты отчислений за продажу билетов, для полноты статьи. Иначе из статьи не получается понять, где же именно «бизнес по продаже авиабилетов не вставая с дивана» так как описан только поиск билетов не вставая с дивана.
1. Хорошо, что не стали с нуля писать свою CMS, а взяли Drupal Commerce — проект в который вложено 15 млн. $ с кучей модулей из коробки и огромной россыпью в репозитарии. Плохо, что скорее всего вы половину модулей не выключили (если они Вам не нужны), не взяли более лёгкий дистрибутив Drupalife Store.
2. Если пользуете Российский хостинг, то вторые грабли тормознутость HDD, DigitalOcean или подобный хостинг с SSD это ускорение на 1000% (модулей много читаются они долго).
3. PHP 5.5 c OPcach именно только так и никаких других акселераторов — прирост скорости в несколько раз в отличие от голого PHP 5.3 (а если он с APC то там акселерация начинает борется с недостатком памяти сервера — но так уж работает именно APC).
4. SOLR — отказ от него вторые крупные грабли так как он именно для этого предназначен. После этого следует что Вы строите свой HighLoad.
5. Своя entity — всё в одной таблице, что исключает JOINы (внимание нужно только для HighLoad и только когда без этого нельзя обойтись). Третьи грабли на которые Вы наступили. Но не нужно писать entity для каждого материала, только для тех, чьи поля постоянно используете. У магазина — поиск это обычно до 70% просмотренных страниц, у тематических сайтов обратное.
6. Есть модуль Database logging — если не всё хорошо с верстальщиками и т.п. может генерировать большой объём лога об ошибках в базу данных, база от этого тоже начинает тормозить переваривая большой insert перед показом каждой страницы. Поэтому нужно или исправить все ошибки, что падают в лог или отключить модуль. Правда об подозрительных дествиях на сайте Вы перестаёте быть настолько осведомлены после отключения модуля.
7. Ладно раз используете поля для тяжёлых выборок, то если не используете ревизии нод, то поставьте Field SQL norevisions — пусть база будет меньше, а диску легче (внимание нужно только для HighLoad и только когда без этого нельзя обойтись).
8. Entity cache + Memcache API and Integration или Redis и пусть Ваш кэш материалов живёт в памяти сервера а не на диске. А для магазинов ещё и commerce_entitycache обязателен.
9. Подключение модуля memcached для кэша всего остального в памяти это правильно.
10. Про cache_form хорошо Spleshka написал в статье: «Система кэширования Drupal 7. Часть первая: сегменты кэша», там всё от и до от того как и заканчивая зачем.
11. Просматривайте чего генерит views (у него на странице со списком представлений есть вкладка настройка и там галочка — показывать SQL), иногда то, что накидают через UI (например 500 связанных полей (реальный пример)) генерит не реальный JOIN.
Самое главное — спрашивайте. Про оптимизацию Drupal 6 я ешё в 2009 году писал, про оптимизацию Drupal 7 Spleshka (например: drupalace.ru/lesson/otdayom-kesh-anonimov-bez-podnyatiya-bekenda-drupal-7-nginx-memcached). К его статьям мне и добавить то нечего. Если есть вопросы по HighLoad, я всегда отвечу тут: www.drupal.ru/username/irbis
2. Будет ли онлайн вариант обучения?
3. Интересно ли сотрудничать с лекторами в этой области?
Хочется и поучиться, но удаленно. И есть, что рассказать студентам по систем понимающих текст (разрабатывал систему понимающую текст и отвечающую по нему на вопросы). С онлайн обучением просто хочется поспособствовать хорошему начинанию.
К концу 2010 плюшки были в почте, а стартап превратился в под-проект Яндекса. Но к сожалению Яндекс на тот момент только арендовал готовые технологии. А инвесторы в России вкладываются только в готовые проекты.
Так, что есть что улучшать ещё в Яндекс.Почте, давно ей пользуюсь и жду дальнейшего её развития.
Ребята мы ждём от Вас ещё больших прорывов, мы с Вами!!!