Comments 71
Схема стандартная, но верная. Еще бы добавить склейку js / css файлов в один js / css с трансляцией относительных путей на пути от корня и обновление сжатого файла автоматом, при обновлении несжатого.
0
Да, и gzip_comp_level лучше 5-6 ставить. 9 — перебор.
+10
Я бы добавил так: gzip_comp_level выставить на 9, прогнать любым скриптом для создания нагрузки задачу со списком статики и выставить на 5-6. В итоге получим максимальное сжатие статики и приемлимую нагрузку во время сжатия динамики.
0
Тут дело в том, что сжатые на 9 данные и разжимаются (браузером) медленнее… А разница между 0 и 5 гораздо больше чем между 5 и 9.
Вот гляньте: habrahabr.ru/blogs/client_side_optimization/24325/
Вот гляньте: habrahabr.ru/blogs/client_side_optimization/24325/
+4
Спасибо! Очень познавательно.
-1
Из выше-указанного непонятно почему нельзя использовать nginx для обработки php и отказаться от Apache, что освободит еще немного памяти, да и системных коннектов будет жрать в 2 раза меньше. Обычно установка nginx предполагает высокую нагрузку, если же mod_php отрабатывает долго то никакой nginx и lighttpd не поможет.
Автор пробовал lighttpd, при грамотной настройке он вел себя стабильнее чем nginx при обработке статики и динамики, по крайней мере ветка 1.4, и в нем также имеется сжатие статики.
Автор пробовал lighttpd, при грамотной настройке он вел себя стабильнее чем nginx при обработке статики и динамики, по крайней мере ветка 1.4, и в нем также имеется сжатие статики.
+1
Лишь предположу.
Дело в архитектуре nginx. Скажем nginx настроен на 8 воркеров. Это значит, что одновременно может исполняться только 8 скриптов. Остальны ждут своей очереди. При большом кол-во запросов и медленных скриптах, это очередь может быть очень длинной, и пользователь будет видеть лишь белую страницу.
Apache, наоборот, обрабатывает все скрпиты параллельно, лишь бы ресурсов хватило.
Дело в архитектуре nginx. Скажем nginx настроен на 8 воркеров. Это значит, что одновременно может исполняться только 8 скриптов. Остальны ждут своей очереди. При большом кол-во запросов и медленных скриптах, это очередь может быть очень длинной, и пользователь будет видеть лишь белую страницу.
Apache, наоборот, обрабатывает все скрпиты параллельно, лишь бы ресурсов хватило.
+2
spanw-fcgi проблему решает чуть больше чем полностью. По крайней мере на lighttpd никаких проблем при 30-40 параллельных запросов на скрипты не было, всё работало быстро.
+1
Ну так и nginx можно настроить так, чтобы он работал в связке со spawn-fcgi. В интернете полно мануалов.
+1
Не сказал бы что это проще настраивать, чем поднять apache с php. И с Apache'м приходит много разных плюшек, по типу rewrite в .htaccess.
+1
Во-первых, настроить не так и сложно, есть куча мануалов.
Во-вторых, реврайт настроить не проблема — есть и mod_rewrite (который настроить не тяжелее, чем аналог из Apache) и mod_magnet для более тяжелых случаев. Более того автор пишет
В-третьих, есть достаточно много плюшек и для lighttpd.
Во-вторых, реврайт настроить не проблема — есть и mod_rewrite (который настроить не тяжелее, чем аналог из Apache) и mod_magnet для более тяжелых случаев. Более того автор пишет
если ваш сайт использует mod_rewrite, то реврайты тоже можно делать на Nginx, а .htaccess файлы просто выкинуть
В-третьих, есть достаточно много плюшек и для lighttpd.
0
использовать nginx для обработки php и отказаться от Apache
Обрабатывать PHP прям внутри Nginx? Так он же асинхронный однопоточный…
Или вы все же про php-fpm/fcgi?
0
Прежние ветки лайти текли дай бог. Поэтому все давно на него забили и перешли на nginx.
Кроме того, какое-то время проект просто не развивался вообще, в том время как nginx почти еженедельно выпускал обновления.
> Автор пробовал lighttpd, при грамотной настройке он вел себя стабильнее чем nginx при обработке статики и динамики
Что значит «стабильнее», и какие ваши доказательства? :)
Кроме того, какое-то время проект просто не развивался вообще, в том время как nginx почти еженедельно выпускал обновления.
> Автор пробовал lighttpd, при грамотной настройке он вел себя стабильнее чем nginx при обработке статики и динамики
Что значит «стабильнее», и какие ваши доказательства? :)
0
Стабильнее значит, что на продакшене у него было более быстрое время ответа и он не «залипал» периодически, как это часто было с Apache и реже с nginx. Например, на статическом сервере, который отдавал «потоковое» видео (mp4 и flv) и скрины к нему, nginx через некоторое время начинал отдавать даже мелкие картинки (4-5кб) по 5-10, на лайти такого замечено не было.
0
А есть аналогичная сжималка, но не на яве? Уж очень не хочется ее ставить на сервер.
0
Вы всегда можете заливать на сервер уже сжатые скрипты, задачи для сжатия css и js существуют для многих систем сборки, вот для Ant например. Еще есть вариант использовать расширение для Апача от Google — кроме возможностей по сжатию CSS и JS еще много функционала для ускорения сайта.
0
Есть много разных сжималок на php, с помощью которых можно в рантайме/по крону сжимать/объединять, вот например или более массивный Minify.
0
При правильно настроенной конфигурации Nginx+Apache, когда статика отдается фронтом, рекомендую обязательно установить в Apache относительно небольшим MaxClients.
Нужно выбрать число таким, чтобы система не свопировала и оставалась память для MySQL и системы. Обычно достаточно 10-25. Увеличить таймаут на NGINX, чтобы он удерживал запросы и защищал бекэнд от перегрузки.
Нужно выбрать число таким, чтобы система не свопировала и оставалась память для MySQL и системы. Обычно достаточно 10-25. Увеличить таймаут на NGINX, чтобы он удерживал запросы и защищал бекэнд от перегрузки.
+4
google closure compiler сжимает js лучше чем yuicompressor, особенно в advanced mode =)
0
UFO just landed and posted this here
Хранить текст в Javascript'ах не комильфо, а длинные Unicode-последовательности кагбэ намекают на это ;-)
0
UFO just landed and posted this here
Например, хранить отдельные файлы для языка/модуля с расширением .json
В плюсах:
— мультиязычность, с возможностью динамической смены языка
— основной скрипт одноразово сжимается с помощью GCC|gzip
— можно легко генерировать из php, а потом кешировать тем же nginx'ом
Минусы исходят из плюсов:
— отдельный файл, а значит требуется дополнительное время на его загрузку, хотя этим можно пренебречь
В плюсах:
— мультиязычность, с возможностью динамической смены языка
— основной скрипт одноразово сжимается с помощью GCC|gzip
— можно легко генерировать из php, а потом кешировать тем же nginx'ом
Минусы исходят из плюсов:
— отдельный файл, а значит требуется дополнительное время на его загрузку, хотя этим можно пренебречь
+2
UFO just landed and posted this here
Не забываем выключать keep-alive в apache.
+1
А нет ли решения, которое позволяло бы сжимать css/js на лету, кэшировать результат, и в следующий раз, если файл не изменился, отдавать из кэша?
+1
UFO just landed and posted this here
Можно сделать rewrite добавляя .gz в конце, а на 404 = 200 и скрипт, который делает gz и отдает его же.
0
Проблема будет в том, что при реврайте на .gz файл, заголовок Content-Type будет соответствовать .gz файлу. В принципе можно сделать что-то вроде:
Но это делается в контексте location, поэтому придется писать location на каждый тип файла.
types { }
default_type application/javascript;
Но это делается в контексте location, поэтому придется писать location на каждый тип файла.
+1
да будет дефолтовый
типы можно пропистаь и в контексте html. sample инклюдит mime.types именно там.
не знаю может и js.gz воспримется нормально, типа
application/x-javascript js js.gz;
типы можно пропистаь и в контексте html. sample инклюдит mime.types именно там.
не знаю может и js.gz воспримется нормально, типа
application/x-javascript js js.gz;
0
Да, mime.types инклудится в контексте http (поправка). В контексте location это делается для того, чтобы переопределить типы:
Прописывание application/x-javascript js js.gz; не помогает, только что проверил.
location ~ \.js$ {
types { }
default_type application/javascript;
}
Прописывание application/x-javascript js js.gz; не помогает, только что проверил.
+1
UFO just landed and posted this here
мои 2 копейки:
1. ошибки лучше на продакшене закрывать статикой
2. Для CMS с ЧПУ надо делать наоборот все в дефолтовом location а статитку по регулярке, ну и заглушка на техработы
3. заглушка для нежелательных файлов
1. ошибки лучше на продакшене закрывать статикой
error_page 404 500 501 502 503 504 /error.html; location = /error.html { internal; }
2. Для CMS с ЧПУ надо делать наоборот все в дефолтовом location а статитку по регулярке, ну и заглушка на техработы
try_files /maintenance.html @apache; location @apache { proxy_intercept_errors on; # тут еще вставляем управление кэшем proxy_pass http://127.0.0.1:8080; } location ~* ^.+\.(jpg|jpeg|gif|css|png|js|ico|xml|swf)(\?.*)?$ { expires max; }
3. заглушка для нежелательных файлов
location ~ /\.ht { deny all; }
+6
пардон, спрошу нубские вопросы:
1. internal — означает, что nginx в случае ошибки при запросе к несуществующему example.com/aybabtu перенаправляет /error.html в корень example.com (т.е. example.com/error.html)?
2. обработка ошибок из первого случая не работает без proxy_intercept_errors из второго?
1. internal — означает, что nginx в случае ошибки при запросе к несуществующему example.com/aybabtu перенаправляет /error.html в корень example.com (т.е. example.com/error.html)?
2. обработка ошибок из первого случая не работает без proxy_intercept_errors из второго?
0
1. internal означает что запрос /error.html получит 404
2. верно, я его поэтому и оставил
2. верно, я его поэтому и оставил
+1
1. internal означает что запрос /error.html получит 404
2. верно, я его поэтому и оставил
2. верно, я его поэтому и оставил
0
try_files /maintenance.html @apache;
Поисковики не одобряют см habrahabr.ru/blogs/webdev/103406/#comment_3217649
0
mod_rpaf работает некорректно. В частности перестают работать директивы allow from, deny from в .htaccess из-за того что не происходит подмены ip из X-Real-IP. Я использую mod_realip2, который полностью решил эту проблему.
+1
вообщем-то для полного офигения не хватает убрать отсюда апач, прикрутить оптимизацию картинок через www.smushit.com или через набор оптимизаторов
0
не максимально, есть CSS Tidy | Google Compiler
0
gzip_static по умолчанию в nginx отключен, и обычно надо пересобирать nginx чтобы ее использовать
0
Не понял принципиального отличия между моделью работы nginx и prefork Apache…
На 2-х ядерном процессое у nginx'а 2 потока, так же можно сконфигурировать Апач:
StartServers = 2
MinSpareServers = 2
MaxSpareServers = 2
MaxRequestsPerChild = 10000000…
запрос передавать на fastcgi — и получится тот же nginx?
На 2-х ядерном процессое у nginx'а 2 потока, так же можно сконфигурировать Апач:
StartServers = 2
MinSpareServers = 2
MaxSpareServers = 2
MaxRequestsPerChild = 10000000…
запрос передавать на fastcgi — и получится тот же nginx?
0
Дело в том, что поток Apache занимается лишь одним клиентом — такая архитектура. Поток же nginx в цикле пробегает по коннектам и уделяет каждому понемногу времени. Объясняю своими словами, надеюсь корректно описал суть :)
0
а апач как это делает?
я так понял, что это работает приерно так: процесс получил, запрос, передал его fastCGI, получил следующий, передал, получил результат от fastCGI, передал его сокету, полуил запрос на статику, считал, передал сокету… и т.д. В чём тогда разница между nginx и prefork Apache?
я так понял, что это работает приерно так: процесс получил, запрос, передал его fastCGI, получил следующий, передал, получил результат от fastCGI, передал его сокету, полуил запрос на статику, считал, передал сокету… и т.д. В чём тогда разница между nginx и prefork Apache?
0
Один поток Apache делает вот что: получает запрос от клиента, обрабатывает запрос, выдает результат клиенту. Один поток занимается одним клиентом и больше ничем. Т.е. с параметрами, которые Вы привели выше, Apache не сможет обработать более двух клиентов параллельно.
А один поток nginx работает иначе: в бесконечном цикле он пробегается по массиву сокетов, при необходимости считывает/записывает небольшой блок данных из/в сокет(а). Т.е. за каждый цикл он обслуживает сразу кучу клиентов (не более значения опции worker_connections). Это принцип работы poll. epoll работает еще эффективнее, но суть примерно такая же.
А один поток nginx работает иначе: в бесконечном цикле он пробегается по массиву сокетов, при необходимости считывает/записывает небольшой блок данных из/в сокет(а). Т.е. за каждый цикл он обслуживает сразу кучу клиентов (не более значения опции worker_connections). Это принцип работы poll. epoll работает еще эффективнее, но суть примерно такая же.
0
Использование NGINX перед апачем имеет одну проблему. которую нужно иметь ввиду.
Иногда некоторые криворукие программисты делают из флэшек запросы на получение других флэшек методом GET.
Apache такие запросы обрабатывает нормально. а вот nginx их не разрешает.
Т.е. если вы берёте абстрактнгый веб проект и хотите его ускорить, то без переписывания кусков флэша — может не обойтись.
+ Не забывайте что использование front'end'a автоматически лишит вас информации об IP пользователя. и вам придется обязательно в настройках NGINX позаботится о правильной конверсии header'ов
Иногда некоторые криворукие программисты делают из флэшек запросы на получение других флэшек методом GET.
Apache такие запросы обрабатывает нормально. а вот nginx их не разрешает.
Т.е. если вы берёте абстрактнгый веб проект и хотите его ускорить, то без переписывания кусков флэша — может не обойтись.
+ Не забывайте что использование front'end'a автоматически лишит вас информации об IP пользователя. и вам придется обязательно в настройках NGINX позаботится о правильной конверсии header'ов
0
ошибка в посте… не GET a POST
следует читать
>>Иногда некоторые криворукие программисты делают из флэшек запросы на получение других флэшек методом POST.
следует читать
>>Иногда некоторые криворукие программисты делают из флэшек запросы на получение других флэшек методом POST.
0
почему в пресловутом абстрактном веб-проэкте вообще не отказаться от использования апача?
nginx прекрасно справляется и с отдачей статики, и с обработкой динамики на фастцги сервере. для чего нужен то апач?
nginx прекрасно справляется и с отдачей статики, и с обработкой динамики на фастцги сервере. для чего нужен то апач?
0
насчет. mod_rpaf и remote ADDR. есть и другой какой-то способ
0
Sign up to leave a comment.
apache+nginx+gzip_static+yuicompressor