В предыдущей статье я рассказывал об установке сервера Nginx из линейки Stable.
В этот раз речь пойдет об установке Nginx 1.9.x из линейки Mainline, где уже реализована поддержка нового протокола HTTP/2.
AddThis Smart Layers
Показаны сообщения с ярлыком nginx. Показать все сообщения
Показаны сообщения с ярлыком nginx. Показать все сообщения
среда, 9 марта 2016 г.
понедельник, 21 сентября 2015 г.
Как установить Nginx на CentOS 7
Вебсервер Nginx является замечательной альтернативой Apache для сайтов на платформе Magento, а на данный момент мы работаем именно с этой платформой.
Чем так замечателен этот сервер? Хотя бы тем, что он прост в настройке (хотя отвыкание от .htaccess проходит долго и болезненно), он потребляет крайне мало ресурсов сервера, умеет кешировать статичные файлы (нестатичные тоже умеет, но в нашем случае это нерелевантно), дружит с PHP и FastCGI. Вполне достаточно чтобы слезть сиглы Apache.
Здесь речь пойдет о процессе установки и апгрейда этого сервера на базе операционной системы CentOS 7.
Чем так замечателен этот сервер? Хотя бы тем, что он прост в настройке (хотя отвыкание от .htaccess проходит долго и болезненно), он потребляет крайне мало ресурсов сервера, умеет кешировать статичные файлы (нестатичные тоже умеет, но в нашем случае это нерелевантно), дружит с PHP и FastCGI. Вполне достаточно чтобы слезть с
Здесь речь пойдет о процессе установки и апгрейда этого сервера на базе операционной системы CentOS 7.
вторник, 22 апреля 2014 г.
Varnish Cache и Magento 1.8.x
В своем старом блоге на Livejournal я много писал об использовании Varnish Cache на серверах с Magento.
Не могу сказать, что все было идеально, кроме того, что нужно было довольно кропотливо настраивать конфигурационный файл самого Varnish, проблемы возникали буквально на каждом шагу. То какие-то сторонние расширения кешировались неправильно (или не кешировались), то неправильно определялся user-agent и сайты с отдельными мобильными шаблонами начинали отображать мобильные версии в обычных десктопных броузерах.
Когда же наконец вышла Magento 1.8.x проблема с Varnish Cache решилась сама собой. Он просто оказался несовместим с этой версией Magento.
И, насколько мне известно, решения совместимости до сих пор нет.
Да и не нужно. Потому что с задачей кеширования и быстрой выдачи статичных файлов прекрасно справляются Redis и Nginx.
Если же нужно еще больше разгрузить сервер и уменьшить количество статичных файлов (изображений, файлов шаблонов и других), то CDN в помощь.
Для автоматизации работы с динамически создаваемыми статичными файлами изображений товаров прекрасно справляется расширение OnePica ImageCDN. Но это тема уже для другого поста.
Не могу сказать, что все было идеально, кроме того, что нужно было довольно кропотливо настраивать конфигурационный файл самого Varnish, проблемы возникали буквально на каждом шагу. То какие-то сторонние расширения кешировались неправильно (или не кешировались), то неправильно определялся user-agent и сайты с отдельными мобильными шаблонами начинали отображать мобильные версии в обычных десктопных броузерах.
Когда же наконец вышла Magento 1.8.x проблема с Varnish Cache решилась сама собой. Он просто оказался несовместим с этой версией Magento.
И, насколько мне известно, решения совместимости до сих пор нет.
Да и не нужно. Потому что с задачей кеширования и быстрой выдачи статичных файлов прекрасно справляются Redis и Nginx.
Если же нужно еще больше разгрузить сервер и уменьшить количество статичных файлов (изображений, файлов шаблонов и других), то CDN в помощь.
Для автоматизации работы с динамически создаваемыми статичными файлами изображений товаров прекрасно справляется расширение OnePica ImageCDN. Но это тема уже для другого поста.
воскресенье, 17 марта 2013 г.
Результаты первых тестов на производительность сервера
Сразу же хочу сказать, что тесты не претендуют на идеальность.
Мне важно было понять, использование каких технологий даст существенный прирост производительности.
Например, я не делал никаких оптимизаций в настройках Apache и Nginx. Потому что это было бессмысленно. Так как тесты, которые я проводил, были на быстродействие сервера, а не на "стрессоустойчивость" в условиях массивного трафика.
Мне важно было понять, использование каких технологий даст существенный прирост производительности.
Например, я не делал никаких оптимизаций в настройках Apache и Nginx. Потому что это было бессмысленно. Так как тесты, которые я проводил, были на быстродействие сервера, а не на "стрессоустойчивость" в условиях массивного трафика.
пятница, 15 марта 2013 г.
Снова об оптимизации серверов
Давненько не брал я в руки шашек, надо бы восполнить пробел, тем более что появились новые технологии.
В одном из предыдущих постов я писал об установке Nginx на виртуальный сервер с предустановленным cPanel. Все работало и работает до сих пор очень даже хорошо.
Но, недавно я нашел еще лучшее решение, а именно связку Nginx+Varnish Cache для серверов под управлением cPanel. Называется Apachebooster. Сделал какой-то индус, но на удивление сделал добротно. Поставил уже на пару серверов и тьфу-тьфу, проблем не замечено. Зато существенный прирост в скорости очень даже хорошо ощущается.
Теперь, имея установленный Varnish Cache можно установить расширение для Magento, позволяющее создавать полностраничное кеширование.
В одном из предыдущих постов я писал об установке Nginx на виртуальный сервер с предустановленным cPanel. Все работало и работает до сих пор очень даже хорошо.
Но, недавно я нашел еще лучшее решение, а именно связку Nginx+Varnish Cache для серверов под управлением cPanel. Называется Apachebooster. Сделал какой-то индус, но на удивление сделал добротно. Поставил уже на пару серверов и тьфу-тьфу, проблем не замечено. Зато существенный прирост в скорости очень даже хорошо ощущается.
Теперь, имея установленный Varnish Cache можно установить расширение для Magento, позволяющее создавать полностраничное кеширование.
Метки:
оптимизация сайта
,
apc
,
cloud computing
,
cpanel
,
magento
,
memcached
,
mysql
,
nginx
,
varnish
воскресенье, 18 сентября 2011 г.
Установка Nginx на VPS (cPanel)
среда, 30 марта 2011 г.
Оптимизация сервера и сайта
В последнее время пришлось довольно серьезно подучить матчасть в области оптимизации вебсервера.
Появился новый клиент, с довольно таки большим сайтом на Joomla.
Основных проблем было две:
1. При нагрузке в 300 одновременных заходах сервер не справлялся с нагрузкой и просто падал.
2. Даже когда сервер не падал, среднее время загрузки страницы составляло не менее 40 секунд.
Появился новый клиент, с довольно таки большим сайтом на Joomla.
Основных проблем было две:
1. При нагрузке в 300 одновременных заходах сервер не справлялся с нагрузкой и просто падал.
2. Даже когда сервер не падал, среднее время загрузки страницы составляло не менее 40 секунд.
Метки:
оптимизация сайта
,
apache
,
joomla
,
mysql
,
nginx
вторник, 13 апреля 2010 г.
В поисках 503 ошибки
Пара клиентов часто жалуются на 503 ошибку (service unavailable) при заходе на свои сайты.
Поверхностное изучение показало что ошибка может быть из-за того что с одного IP было слишком много соединений.
В принципе, так как на сервере стоит Nginx, то в теории может такое быть, так как все запросы Apache поступают от него с одним и тем же IP.
Копнув глубже понял, что nginx тут не причем.
В конце концов дождался момента когда в очередной раз стала появляться ошибка 503 и полез смотреть error_log апача. И вот что там было:
Request exceeded the limit of 10 internal redirects due to probable configuration
error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
Т.е. проблема то не столько в сервере, сколько в скриптах которые эти клиенты гоняют у себя.
Но ведь главное то было волну нагнать, заставить меня перелопачивать гугль и кропотливо изучать логи сервера.
Поверхностное изучение показало что ошибка может быть из-за того что с одного IP было слишком много соединений.
В принципе, так как на сервере стоит Nginx, то в теории может такое быть, так как все запросы Apache поступают от него с одним и тем же IP.
Копнув глубже понял, что nginx тут не причем.
В конце концов дождался момента когда в очередной раз стала появляться ошибка 503 и полез смотреть error_log апача. И вот что там было:
Request exceeded the limit of 10 internal redirects due to probable configuration
error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
Т.е. проблема то не столько в сервере, сколько в скриптах которые эти клиенты гоняют у себя.
Но ведь главное то было волну нагнать, заставить меня перелопачивать гугль и кропотливо изучать логи сервера.