насчет побьется я не совсем уверен, так как неделю назад вообще про nginx не слышал. Но я думаю ты ошибаешся… Пройдись по конфигу nginx и посмотри логику. Я вчера часов 6 с этим конфигом провозился, так что испробовал различные варианты. Смотри вот правило: # Именнованная лакация (правило)     location @modx {         # выполняем подмену на index.php         rewrite ^/(.*)$ /index.php?q=$1 last;     } Так как ЧПУ MODX-а построено полностью на реврайтах, а не на реальных файлах, именно благодаря ему все УРЛы и преобразуются в index.php Но это происходит только потому что запрашиваемый файл не найден. Но если файл будет найден, то этого преобразования не будет, а останется реальный УРЛ. И в итоге ключ /index.php не будет соответствовать никогда в этом случае. Но это конечно же ситуация исключительная, поэтому конечно ты можешь пренебрегать этим моментом и сделать так, как ты предложил — в 99% случаев оно действительно будет работоспособным. Но у меня свои тараканы в голове и я терпеть не могу неуниверсальность, поэтому у себя оставлю так.

да настройки есть конечно, аналогичные кстати… но не получилось, возможно механизм сжатия по другому работает. насчет побьется я не совсем уверен, так как неделю назад вообще про nginx не слышал. Но я думаю ты ошибаешся… Пройдись по конфигу nginx и посмотри логику. $expire работает — уже проверял.

Скажите пожалуйста, зачем обновлять контекст? Если вы про это: // На всякий случай меняем контекст, если MODX сам не поменял на контекст документа         $origin_context = null;         if($modx->context->key == 'mgr'){             $origin_context = $modx->context->key;             $modx->switchContext('web');         } то причина следующая: дело в том, что TV-параметры привязываются к источникам файлов (индивидуально для каждого контекста). Но нельзя указать связку TV-поля с конкретным источником файлов в контексте mgr. Если вы не используете отдельного источника файлов. используя по умолчанию filesystem (который от корня сайта работает), то вам бояться нечего. А если у вас в web-контексте другой источник (я часто в основном использую Images (/assets/images/)), то без смены контекста будет использован тот же filesystem и пути побьются, файлы просто не будут найдены. И что делать на мультиязычных сайтах? Мультиязычных или мультидоменных? Мультиязычность здесь никакой роли не играет, а если мультидоменный (мультиконтекстный), то используйте во всех контекстах один и тот же источник файлов, что и в web, и никаких проблем не будет. P.S. на самом деле эта смена контекстов больше имеет значение при выполнении кода в консоли, когда по умолчанию используется текущий контекст mgr, но при редактировании документа через родной редактор страниц, проблем не должно никаких встать. P.P.S -лучше использовать pThumb вместо phpthumbof, так как первый, в случае если картинка не найдена, использует указанный УРЛ картинки без изменения (то есть просто УРЛ будет на оригинал), в то время как второй или ничего не отдает, или записывается ошибка в TV.

memcache зараза страницу компрессирует как ни крути А ты смотри phpinfo() раздел memcache. У него тоже свои настройки есть, типа max_chunk_size или типа того. Наверняка тоже можно поднять значение. вообще лишнее, можно выкинуть… и в nginx правильнее наверно будет «default/$args» Да? А кто запрещает создать еще какой-нибудь внутренний php-файл? И что тогда? И тогда нафиг все побьется. А ты предлагаешь все жестко завязать на единственный php-файл. Не, я так не буду делать. и добавить еще $expire Это я может позже поковыряю, но у меня есть подозрение, что это не так работает, как хотелось бы. Думаю, что это значение для самого MODX-а, а не для мемкеша. То есть как работает этот параметр для MODX-а? — кеш есть, но время уже не актуальное, и MODX его игнорит. Но если это так, то gnixn-у на это пофигу будет, он получит кеш и все. Хотя это только предположение, проверять надо.

Скажите пожалуйста, зачем обновлять контекст? И что делать на мультиязычных сайтах?

memcache зараза страницу компрессирует как ни крути, а вот с memcached все нормально) вот это у тебя <code>$key = '/index.php?';</code> вообще лишнее, можно выкинуть… и добавить еще $expire <code>$modx->cacheManager->set($key , $modx->resource->_output, $expire);</code> выставить время жизни кеша. и в nginx правильнее наверно будет "default/$args"

Так я сказал «пока». Докрутить многое можно. Да и на уровне плагина можно разрулить что кешировать так, а что нет (допустим, личный кабинет не кешировать). Но это так, эксперимент. Я более плотно планирую делать это на уровне node.js То есть нода не все еще умеет, чтобы так сразу фрейм заменить, но ее можно использовать как умный кешер. То есть и данные в памяти держать, и логику рулить можно. В общем, планирую nginx+MODX+node.js

Молодец! все толково расписал. Насчет только для визиток, я бы не был так категоричен. Nginx много чего умеет…

Кстати, стандартным $modx->cacheManager-ом кеш сохранял. Само собой мемовским. И все ОК, ничего лишнего не понадобилось делать.

Тест не сохранил, так как бесплатный всегда хрень показывает. Показывал, что секунду с лишним ответ. Нагрузке на сервере вообще не ощущал. Вот статья: modxclub.ru/blog/research/210.html А я пошел спать. Удачи