ЗАЧЕМ?.......
Лоботомией.
Ну и что "некультурного" Вы усмотрели в первом?
А второе - не было сказано в адрес "оппонента". Это он сам его к себе применил, "расписавшись" в собственной характеристике.
Ага. Вешаем обработчик, лезем в базу, сравниваем...
Што-то слабо верится что эта быдлокодерская хренотень обгонит простой дедушкин способ с RewriteMap. Зато с симлинками, епт.
Это обычное pecl расширение. Просто соберите его и установите.
http://php.net/manual/en/install.pecl.php
Оскорблять начал вот кто. В ответ на замечания (вот и вот) совершенно невинного характера: "прочитайте ТС, прежде чем что-то писать".
Зато человек вежливо задает тупой вопрос:
Ну ее нафиг, такую "культуру" - пусть сперва культуре читать и думать научится.
Вы разве не поняли кому пишете? :) Зря стараетесь - только минус в репу схлопочите от защитников разных убогих...
Объясняли:
Ну, сервер не будет "накрываться", если Вы поставите MaxClients в 3 и отключите KeepAlive (как тут советовали). Просто для клиентов он будет, скажем так - "малодоступен".
Произведет. Ровно то, на что расчитан.
Неплохие попугаи. И сколько/на сколько в них?
Ну и где результаты - тоже на уровне ощущений?
В том и проблема, что включать это Вы советуете в общем случае. Когда профит, мягко говоря - не очевиден. Узким местом отдача статики становится далеко не на рядовом сайте, который хосттрекер способен положить...
Что значит "не только"? Это просто несвязанные вещи.
А почему Вы считаете, что они не оптимизированны? Создаются временные таблицы, и? Если это настолько фатально - ORDER BY & GROUP BY в запросах с JOIN (данный сценарий подробно описан в документации) просто не было бы.
Я не вижу вообще пока реальной проблемы - в этом, собственно, и есть основная проблема у ТС.
Есть "почти", а есть стандарты. Апач - следует стандартам, в чем одно из его достоинств.
"Лучше серверу" - это вообще какая-то странная идея... Если проект приносит прибыль - логично исходить из того что лучше для клиентов. Иначе они уйдут.
"Очень хороший" - это в каких попугаях?
Не очевидно. Может и будет, но на уровне "отключения .htaccess", как тут один клоун советовал. Или даже хуже. Вы померять попробуйте.
Не nginx, а его бездумное использование.
Разуйте глаза. На апаче я кешировать не предлагал. Раз Вы поставили nginx проксировать - и кешируйте на нем.
На проксирующем сервере - кешировать, имхо - логичнее.
На том, что апач умеет готовить?
Переусложнять не нужно. _Два_ веб-сервера, раздающих файлы из одного и того же каталога - это уже повод для "приятных" неожиданностей.
Почему Вы уверены, что такие запросы у ТС - есть?
Он попросту не может. nginx не умеет (не умел?) HTTP/1.1 при проксировании. Так что если он стоит перед апачем - кипалайв на последнем всегда отключен.
Но речь шла о кипалайве для клиента. Его отключать не следует (как сделала ТС, у которой только апач).
Только не для среднестатистического сайта, предназначеного для полудохлого VPS. Лучше кеширование сделать, помимо проксирования - вместо всякой-то порнографии...
Такие "оптимизации" - только повод для очередных анекдотов конфигурации. Заметно выделяется этой блажью ispmanager.
