Сравнение способов оптимизации drupal

Прислано: andypost@drupal.org

ср, 10/02/2010 - 11:46

Оптимизация производительности drupal В февральской рассылке Zend первой строкой идет сравнение способов оптимизации drupal посредством выбора движка для кеширования op-code (фактически компиляция и кеширование php).

Как и ожидалось, а также подтверждается личными сравнениями - лидер zend. Но он интересен не только опережением APC на 10-15%, а еще и кешированием пользовательских данных - Zend Data Cache.

Цифры из графиков говорят сами за себя, включение оптимизации не только экономит память, но ускоряет выполнение в 3-5 раз, windows немного отстает от linux, вероятно из-за типа файловой системы, но не сильно.

Радуют результаты полного кеширования страницы - фактически страница отдается из памяти (shm) или диска (disk) не поднимая ядро drupal. Данный функционал реализован в presslow и портирован в drupal7 - в тестах прирост отдачи 26, но это реализовано пока только в коммерческой версии Zend Server.

Очень странно, что не учтен механизм page_fast_cache, доступный при использовании модулей  memcache,  Cache Router - он должен давать близкие результаты, так как страница отдается из кеша без поднятия drupal - исполняются всего несколько файлов.

ЗЫЖ читающим только по-русски можно посмотреть диаграммы :)

PS: Новый eAccelerator 0.96 перестал предоставлять пользовательские функции кеширования, xcache практически не развивается, APC завяз в beta версиях - ZDC, кстати, прекрасно эмулирует функции apc

Прикрепленный файлРазмер
Optimizing-Drupal-Performance-Zend-Acquia-Whitepaper-Feb2010.pdf516.6 кб

Комментарии


Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Применить"
Опубликовано Irbis в ср, 10/02/2010 - 13:43.

Спасибо.


Опубликовано SkyD в ср, 10/02/2010 - 14:37.

Спасибо, интересная тема, буду читать.

P.S.
Если вы разбираетесь, уточните пожалуйста один вопрос:

Я представляю что такое Зенд, но сталкивался с ним лишь для работы с защищёнными скриптами, для оптимизации - не изучал.
Так вот, если я использую shared hosting (который у нас не очень корректно называют виртуальным), то можно особо и не дергаться или всё-таки можно управлять Зендом и в этом случае?


Опубликовано Valeratal в ср, 10/02/2010 - 14:53.

а кто даст зенд на виртуальном?


Опубликовано Skorpva в ср, 10/02/2010 - 15:40.

Мне тоже пришла эта рассылка, выкладки очень интересные :)


Опубликовано vgoodvin в ср, 10/02/2010 - 15:41.

Жалко что Page caching есть только в платной версии.


Опубликовано SkyD в ср, 10/02/2010 - 15:52.

"Valeratal" написал(а):

а кто даст зенд на виртуальном?

Зенд установлен на сервере, а любой из клиентов имеет к нему доступ, например, как к PHP - т.е., как минимум, запустить защищённый Зендом скрипт получится безо всяких проблем.


Опубликовано andypost@drupal.org в ср, 10/02/2010 - 18:59.

Page caching есть только в платной версии, но он успешно эмулируется page_fast_cache с совсем небольшим оверхэдом


Опубликовано vgoodvin в ср, 10/02/2010 - 16:42.

"SkyD" написал(а):

Такое надо спрашивать у хостера.


Опубликовано vgoodvin в ср, 10/02/2010 - 16:46.

"andypost@drupal.org" написал(а):

Page caching есть только в платной версии, но он успешно эмулируется fast_page_cache с совсем небольшим оверхэдом

Ну и ладненько.
Кстати есть еще  cache. Там появилась поддержка redis в качестве хранилища кэша.


Опубликовано andypost@drupal.org в ср, 10/02/2010 - 19:01.

 cache неплохой форк, к сожалению  cacherouter долго был в заброшеном состоянии...


Опубликовано Crea в чт, 11/02/2010 - 13:30.

Обычное маркетологическое "исследование". В таких случаях какие надо циферки, такие и нарисуют. Поэтому замечание "странно, что не учтен механизм page_fast_cache" - достаточно наивно ;)
Особенно забавно, что туда запихнули page cache - видимо, так графики опережения решений от Zend красивее. На самом деле, кеш всей страницы бессмысленно сравнивать в контексте запуска php - с таким же успехом можно поставить Boost и показать на графиках тысячекратный рост производительности. Узкое горлышко у друпала уже давно не при отдаче целиком кешированных страниц, а при работе залогиненных пользователей.


Опубликовано gor в чт, 11/02/2010 - 17:10.

Пожалуйста не путайте ZendOPtimizer ( который обычно подразумевают когда говорят о Zend) и продукт Zend Server который промоутается.
Последний на обычный хостинг не поставить. Необходимо делать хостинг на базе Zend Server.

Так что это решение больше всего подходит для клиентов с выделенными серверами.


Опубликовано vgoodvin в пт, 12/02/2010 - 09:48.

По сути от этого сервера нам надо только Bytecode accelerator (Optimizer+) и Zend Data Cache. Скачать бы отдельно.


Опубликовано andypost@drupal.org в пт, 12/02/2010 - 14:12.

@Crea если бы я лично не наблюдал эти циферки, то не постил бы это сообщение. Дело вовсе не в маркетинге, хотя и имеет место быть. Вы наверно слишком поверхностно изучили файл, что сделали такие выводы... php поднимается во всех случаях!

 boost хоть и развивается активно, но даст только приближенные результаты с отдачей из памяти, болезней у файловой системы побольше будет.

Отдача кешированных страниц значительно важнее работы авторизированных пользователей, не стоит проецировать свои задачи на более частое применение drupal.

@gor zend server всё-таки сборка php использующая веб-сервер, OPtimizer - один из модулей

Использование ZS community edition тоже не возбраняется, хоть он и лишен некторых фич.


Опубликовано Crea в пт, 12/02/2010 - 18:00.

@andypost

Цитата:

Дело вовсе не в маркетинге, хотя и имеет место быть. Вы наверно слишком поверхностно изучили файл, что сделали такие выводы... php поднимается во всех случаях!

Я не спорю что php поднимался. Однако, много ли надо от php при отдаче полностью кешированной страницы ? И хотелось бы видеть независимое исследование.

Цитата:

болезней у файловой системы побольше будет

Каких. например ?

Цитата:

Отдача кешированных страниц значительно важнее работы авторизированных пользователей,

Бред пишете. Есть boost, есть varnish, есть page_fast_cache. Начиная с определенного порога, уже не важно, сколько полностью закешированных страниц в секунду вы отдаете анонимным пользователям, 100, 200, или 1000 - все равно этого хватает с лихвой. А вот для авторизованных пользователей искоробочных производительных решений нет.

Цитата:

не стоит проецировать свои задачи на более частое применение drupal.

Я не проецирую задачи - я проецирую решения. Проблемы отдачи страниц анонимным посетителям нет - есть только неумение применить готовое решение этой проблемы у отдельных пользователей (не имею ввиду вас).


Опубликовано Химический Али в сб, 13/02/2010 - 10:52.

Прошу прощения, может не в тему - как (чем) в домашних условиях корректно протестировать производительность той или иной конфигурации?


Опубликовано vgoodvin в сб, 13/02/2010 - 12:29.

"Химический Али" написал(а):

Прошу прощения, может не в тему - как (чем) в домашних условиях корректно протестировать производительность той или иной конфигурации?

Вместе с апачем идет утилита ab. Она в большинстве случаев и служит для тестирования веб-серверов/приложений. На юниксах есть. На на виндовсе не знаю, на денвере врятли а вот на полностью установленном апаче должна быть.


Опубликовано Crea в сб, 13/02/2010 - 17:22.

Кстати, есть такой проект Mercury. Это пакет, куда ЕМНИП входят Pressflow и Varnish в режиме reverse proxy, уже настроенные для совместной работы. Пока что проект ориентирован на установку в Amazon EC но в будущем обещают поддержку обычного железа и виртуальных машин. Так что любой человек сможет установить Mercury и отдавать анонимным пользователям на средненькой VPS сотни страниц в секунду.


Новое на сайте