Пример увеличения производительности магазина

Введение

Данное сообщение - не вопрос.
Это, скорее, статья об одном из способов выжать из своего интернет-магазина больше производительности. Целевая аудитория статьи - пользователи с навыками администрирования и владельцы магазинов, у которых в штате есть системный администратор.

Скорость работы - очень важный фактор для владельца любого сайта: клиент может покинуть страницу, не дождавшись ее загрузки, поисковый робот отдаст предпочтение конкуренту, если его магазин работает быстрее.

Здесь я приведу способ, который мы использовали, чтобы увеличить производительность одной из немаленьких площадок на базе Shop-Script 5. По понятным причинам, я не буду называть данные магазинов, хостингов и так далее. Статья носит чисто ознакомительный характер. Поехали!

С чего все началось

Недавно к нам обратился владелец интернет-магазина на базе Shop-Script 5. Жалобы были следующие: по мере роста его проекта сильно упала скорость загрузки страниц (главная могла грузиться до 10 секунд), так еще и робот Яндекс-метрики стал присылать тревожные сообщения о том, что в часы пик его сайт просто недоступен.

Казалось бы, ответ прост: "Смени хостинг". Однако, более мощный хостинг - еще и более дорогой. Так почему бы не попробовать выжать все соки из того, что уже есть? Это создаст некий запас производительности, который и на новом хостинге был бы очень к месту. Что-ж, давайте разберемся.

Строим фундамент

Сразу хочу отметить, что в данной статье Вы не увидите "копания в коде": SS5 и так не плох. Речь пойдет прежде всего о тонкой настройке сервера. Задача ставится так: дано - интернет-магазин, доступная вычислительная мощность, надо: получить с этой мощности максимум отдачи.

Первое и самое важное: нужно выбрать web-сервер.

Webasyst в своих статьях намекает нам на Apache, однако, в плане производительности это не самое лучшее решение - он медленный, создает форки на каждое соединение и вообще большой любитель "насиловать железо".

NGinx? Да, эта штука очень неплоха в задачах на проксирование и отдачу статического контента, но не особо хороша, когда речь идет о динамических скриптах, а их в нашем магазине много.

Поэтому для наших задач было решено использовать Lighttpd - сервер быстрый, прекрасно справляющийся со всем, что нужно. По совокупности характеристик он подошел больше всего.

Замешиваем раствор

В предыдущем пункте я не зря сказал про "намеки на Apache". Собственно, отчетливо видно, что SS5 заточен под него - тут и .htaccess, и mod_rewrite.. Понятно, что под Lighttpd всю эту котовасию придется настраивать руками.

Здесь я опишу основные моменты, формат статьи не позволит подобно расписать все-все-все. То есть, мы остановимся на том, что наш магазин работает на Lighttpd как часы и, что важно, на всю катушку использует ЧПУ (куда ж без него, SEO, как-никак).

Итак, в нашем распоряжении VDS-сервер с SSH-доступом на базе CentOS 6, и, соответствено, пакетный менеджер YUM. Приступим.

1. Ставим mySQL. В принципе, ничего сложного:

SSH: yum install mysql-server

Подробнее о процессе установки можно прочитать тут: http://dev.mysql.com/doc/mysql-repo-excerpt/5.6/en/linux-installation-yum-repo.html

2. Ставим Lighttpd

SSH: yum install lighttpd

3. Ставим PHP

SSH: yum install lighttpd-fastcgi php-cli

Подробнее о процессе установки по пунктам 2 и 3 можно прочитать тут: http://www.howtoforge.com/installing-lighttpd-with-php5-and-mysql-support-on-centos-6.0

Теперь, для корректной работы интернет-магазина, нужно поставить еще несколько расширений для PHP, а именно, url.rewrite(для ЧПУ), gd(для картинок) и mod_access(для блокировки доступа к файлам). Ставятся они аналогично основному ПО, например, gd можно установить так:

SSH: yum install php-gd

Что-ж, все готово. Выключаем у нашего магазина ЧПУ (пока не настроили ЧПУ на Lighttpd, или привет бесконечным "404 Not Found"). ЧПУ выключается так: открываем файл /wa-config/config.php

'rewrite'=>'0'

Теперь включаем наш магазин, но уже на Lighttpd (БД либо реплицируем, либо, если mysql уже был на сервере, и Вы его не ставили, то все и так должно работать). Не забываем в php.ini поправить upload_max_filesize на 8M, чтобы грузить большие фото товаров.

Крутим гайки

Что-ж, осталось только настроить ЧПУ и доступ. Известно, что .htaccess lighttpd воспринимать отказывается, придется руками. Для нормальной работы Shop-Script 5 нужно всего два правила:

1. Сделать так, чтобы запросы на внутренние страницы могли обходиться без опорного файла index.php, то есть, ссылки были не myshop.ru/index.php/novosti/, а просто myshop.ru/novosti/. Для этого нужно к началу каждого относительного запроса при помощи url.rewrite приписать этот самый index. Пишем правило:

"^(.*)$" => "/index.php$1"

Это чудо-правило как раз и превратит запрос myshop.ru/novosti/, пришедший от пользователя, в myshop.ru/index.php/novosti/, понятный серверу.

2. Отлично, почти все запросы ведут куда надо. Но, вот незадача, не генерируются миниатюры изображений. Связано это с хитрым механизмом работы с картинками самого SS5. А работает он вот как:

/wa-data/public/shop/products/thumb.php - этот файл генерирует миниатюры

Стандартно, .htaccess, лежащий в папке с этим файлом, настроен следующим образом - если пользователь запрашивает картинку, которая уже есть, то Apache определяет это с помощью директивы RewriteCond %{REQUEST_FILENAME} !-f, и просто отдает картинку. Иначе, он переписывает ссылку, вставляя в середину файл thumb.php, который и сгенерирует новую миниатюру, таким образом, часть относительного пути до файла становится параметрами для этого файла.

/wa-data/public/shop/products/00/01/100/images/155/155.200x0.png
становится
/wa-data/public/shop/products/thumb.php/00/01/100/images/155/155.200x0.png

"Легким движением руки брюки превращаются в элегантные шорты" - по другому не скажешь. Пишем аналогичное по поведению правило для Lighttpd:

"^/wa\-data/public/shop/products(.*)$" => "/wa-data/public/shop/products/thumb.php$1"

ЧПУ почти есть. Осталось залить все это в lighttpd.conf. Помня про проверки на существования файла RewriteCond %{REQUEST_FILENAME} !-f из .htaccess, используем url.rewrite-if-not-file, плюс, расставляем правила в нужной последовательности. Итого:

url.rewrite-if-not-file = (
"^/wa\-data/public/shop/products(.*)$" => "/wa-data/public/shop/products/thumb.php$1",
"^(.*)$" => "/index.php$1"
)

Врубаем ЧПУ у SS5:

'rewrite'=>'1'

Барабанная дробь.. Есть, все работает! ЧПУ в нашем магазине настроен.

Остался доступ. Рамки этой статьи не позволяют мне остановиться на нем достаточно подробно, поэтому напишу общий алгоритм:

1. Ищем файлы .htaccess
2. Ищем в них директивы вида deny from all
3. Заносим их эквиваленты на mod_access в наш lighttpd.conf

$PHYSICAL["path"] == "<путь, где был .htaccess с deny внутри>" {
access.deny-all = "enable"
}

Все, наш магазин переехал на lighttpd.

Результат

Теперь посмотрим, как нам удалось то, ради чего все и затевалось - увеличить скорость загрузки страниц.
Данные приведены в час пик.

Главная - 5,5 секунды максимум против 10, которые были.

Выдача товаров - в среднем время ответа сервера уменьшилось на 30%.

Статьи и прочая статика - в среднем время ответа сервера уменьшилось на 35%.

Конечно, не идеально, но прибавка неплохая, по моему скромному мнению.

Заключение

Надеюсь, эта статья сможет пригодиться кому-то из читателей. Да, в ней много технических терминов, но, если у Вас в штате есть системный администратор, не знающий тонкостей Webasyst, она поможет сконфигурировать Ваш сервер оптимальнее и сделать Ваш магазин еще более привлекательным для клиентов.

Спасибо за внимание.