кинь тест глянуть. Нагрузку не мониторил в это время?

ну нормал 100 мс...))) На самом деле меньше. У меня 70+- несколько мсек показывает. Из них минимум 40 — это пинг :-) ты только время кеша маленькое выставил… или еще делаешь что то… Вообще-то когда ты смотрел, лоэдимпакт в 50 клиентов фигачил по сайту)))

ну нормал 100 мс...))) ты только время кеша маленькое выставил… или еще делаешь что то… как интерпрайз летает)))

Пока топик пишу, погоняй: evropa-clinic.modxdev.webtm.ru Смотри в файрбаге время отклика при повторном заходе.

Ок!) С нетерпением жду… Молодчик!

Ну все, я получил результат конечный. Было несколько подводных камней, так что оформлю в новый топик. Сегодня опубликую, но чуть позже.

Не за что!

Да, так действительно лучше будет.

Спасибо большое! Протестировала, теперь все правильно. А про доставку я ничего и не говорила. Это отдельная тема, которая требует ещё проработки в дальнейшем.

В продолжение темы. Очень кратко опишу свой опыт с экспериментом сохранения кода страницы в memcached, который в дальнейшем уже отдает nginx без лишних запросов, получая код непосредственно из memcached. Общая идея: генерировать страницу средствами MODX-а и сохранять ее код полностью в memcached, чтобы в дальнейшем nginx проверял наличие кода страницы в memcached-е, и если есть, отдавал код сразу, не отправляя запрос на php. Пока что это только для сайтов-визиток и т.п. (так как на таких страницах нельзя использовать логику с учетом авторизации пользователей и т.п.), но в дальнейшем планирую страницы делать полностью статическими, а всю динамику переносить на Javascript + AJAX. Основные проблемы, с которыми столкнулся:

1. Больше всего времени потратил на настройку правил для nginx-а (свой вариант покажу ниже).
2. Битая кодировка кеша больших страниц. Как выяснилось, в php для memcached стояла настройка по умолчанию memcached.compression_threshold=2000. То есть если кешируемая строка больше 1999 символов, то php компрессирует ее. Если получить кеш средствами php, то проблем нет, он и декомпрессирует. А вот nginx за этим не следит и отдает как есть. Полечил топорно: в настройках php указал memcached.compression_threshold=9999999 Итак, код плагина: Да, плагин вешаем на событие OnWebPageComplete. Здесь мы этот момент обсуждали. Настройка для nginx: Напоследок хочу отметить, что в запросах учитываются все GET-параметры, так что этот метод годится и для постраничности и т.п. Любое изменение параметров запроса — это новая страница, новый кеш. UPD: Забыл сказать, что в MODX-е еще надо сменить кеш-провайдер на memcached. По умолчанию в настройках MODX-а указано cache_handler=xPDOFileCache, то есть используется файловый кеш-провайдер. Надо поменять на cache.xPDOMemCached. И еще момент: чтобы сразу есть настройки, которые необходимо и в сам конфиг-файл переносить. Дело в том, что для чтения системных настроек из базы данных требуется инициализация самого MODX-а. Это звучит очень логично, но не все на этом внимание заостряют. Так вот, инициализация требует предварительного чтения конфигов. И вот что получается — пока MODX не получил данные из базы данных, он использует конфиги файловые, в том числе и значения по умолчанию. А так как настройка cache_handler=cache.xPDOMemCached хранится в базе данных, то в момент инициализации MODX еще ничего о ней не знает, и соответственно использует стандартный файловый кеш-провайдер. И получив настройки из БД, он только потом очухивается, и начинает использовать Memcached. Но до этого успевает записать конфиги в файлы, и вообще каждый раз при старте читает конфиги из файлов. Вот чтобы этого не происходило и чтобы он сразу использовал Memcached, зайди в core/config/config.inc.php и в $config_options пропиши эту настройку тоже: Вот тогда он сразу будет мемкешед юзать.