Один из наших клиентов недавно мигрировал с платформы LiveCity на Magento.
Сайт довольно большой, с тысячами товаров, сотнями категорий и множеством страниц контента.
При этом, сайт довольно популярный и хорошо проиндексирован Гуглом. Совсем не хочется клиенту терять позиции в результатах выдачи Гугла.
В Magento существует довольно продвинутый и удобный механизм URL Rewrite Management, позволяющий быстро создавать кастомные редиректы.
Все бы ничего, но проблема в том, что на старой платформе не было возможности создавать редиректы, когда пользователь заходил на сайт без www, чтобы система могла автоматически перенаправлять на адрес с www.
В результате со временем образовалось какое-то дикое количество дублирующихся ссылок.
Но даже это не было бы такой уж страшной проблемой, если бы Magento была настолько "тупой" системой и позволяла бы все также заходить на те или иные страницы с www и без него.
Так как Magento все же несколько продвинутее, у нас образовалась новая проблема, когда пользователь заходил на сайт по ссылке без www, его просто перебрасывало на главную страницу. А вот это уже совсем грустно.
Пришлось помучать немного .htaccess
Показаны сообщения с ярлыком apache. Показать все сообщения
Показаны сообщения с ярлыком apache. Показать все сообщения
четверг, 5 сентября 2013 г.
воскресенье, 17 марта 2013 г.
Результаты первых тестов на производительность сервера
Сразу же хочу сказать, что тесты не претендуют на идеальность.
Мне важно было понять, использование каких технологий даст существенный прирост производительности.
Например, я не делал никаких оптимизаций в настройках Apache и Nginx. Потому что это было бессмысленно. Так как тесты, которые я проводил, были на быстродействие сервера, а не на "стрессоустойчивость" в условиях массивного трафика.
Мне важно было понять, использование каких технологий даст существенный прирост производительности.
Например, я не делал никаких оптимизаций в настройках Apache и Nginx. Потому что это было бессмысленно. Так как тесты, которые я проводил, были на быстродействие сервера, а не на "стрессоустойчивость" в условиях массивного трафика.
понедельник, 19 сентября 2011 г.
Оптимизация PHP для работы с Magento
На наших серверах мы всегда настраиваем PHP как FastCGI. При этом используется стандартный для Apache 2.2 модуль mod_fcgid.
Для маленьких сайтов в принципе можно ничего не оптимизировать, все и так будет работать на ура.
А вот для сайтов чуть посерьезнее имеет смысл поиграться с настройками.
Оптимизировать будем в двух местах - в файле php.ini и параметры модуля mod_fcgid в файле конфигурации Apache.
Для маленьких сайтов в принципе можно ничего не оптимизировать, все и так будет работать на ура.
А вот для сайтов чуть посерьезнее имеет смысл поиграться с настройками.
Оптимизировать будем в двух местах - в файле php.ini и параметры модуля mod_fcgid в файле конфигурации Apache.
суббота, 17 сентября 2011 г.
Настройка APC кеширования на VPS
Несмотря на то, что Magento от версии к версии становится все менее требовательной к ресурсам сервера, для оптимизации ее работы очень желательно использовать "быстрый" серверный кеш.
Magento создана на базе Zend Framework и поддерживает 2-х уровневое кеширование, быстрый кеш (fast backend cache) и медленный кеш (slow backend cache). При этом, быстрый кеш может использовать практически любое из ныне популярных решений, таких как APC, Xcache, Memcache. Медленный же кеш может использовать файловую систему, либо базу данных.
Magento создана на базе Zend Framework и поддерживает 2-х уровневое кеширование, быстрый кеш (fast backend cache) и медленный кеш (slow backend cache). При этом, быстрый кеш может использовать практически любое из ныне популярных решений, таких как APC, Xcache, Memcache. Медленный же кеш может использовать файловую систему, либо базу данных.
среда, 30 марта 2011 г.
Оптимизация сервера и сайта
В последнее время пришлось довольно серьезно подучить матчасть в области оптимизации вебсервера.
Появился новый клиент, с довольно таки большим сайтом на Joomla.
Основных проблем было две:
1. При нагрузке в 300 одновременных заходах сервер не справлялся с нагрузкой и просто падал.
2. Даже когда сервер не падал, среднее время загрузки страницы составляло не менее 40 секунд.
Появился новый клиент, с довольно таки большим сайтом на Joomla.
Основных проблем было две:
1. При нагрузке в 300 одновременных заходах сервер не справлялся с нагрузкой и просто падал.
2. Даже когда сервер не падал, среднее время загрузки страницы составляло не менее 40 секунд.
понедельник, 27 сентября 2010 г.
Восстановление большой базы данных MySQL из дампа
На днях нужно было локально, в Windows, запустить рабочую копию сайта клиента. После всех чисток, объем базы данных составлял "всего" 1.5 гига.
Так как локально стоит Wamp, из доступных средств для заливки sql дампа такого размера был только phpmyadmin. Тот же EMS MySQL Manager даже слышать не хотел ничего о том чтобы открыть 1.5 гиговый скрипт.
Так как локально стоит Wamp, из доступных средств для заливки sql дампа такого размера был только phpmyadmin. Тот же EMS MySQL Manager даже слышать не хотел ничего о том чтобы открыть 1.5 гиговый скрипт.
вторник, 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.
Т.е. проблема то не столько в сервере, сколько в скриптах которые эти клиенты гоняют у себя.
Но ведь главное то было волну нагнать, заставить меня перелопачивать гугль и кропотливо изучать логи сервера.