Быстрый магазин и общие настройки как сварить? (чеклист)

warim

Быстрый магазин и общие настройки как сварить? (чеклист)

Возьмем среднестатистический проект на 5-10к товаров, который вроде как-то работает, и может даже в котором «специалисты уже что-то делали», или сервер оптимизировали согласно рекомендации хостинга.
Я еще не видел магазина, в котором мне нечего было бы покрутить.
Всегда народ что-либо упускает.
Давайте разебермся по пунктам что вам надо крутить, чтобы не болела голова за потерянные заказы и уходы клиентов.
Зачастую ведь кажется что у вас все хорошо, но даже повышение конверсии на 5-10% за год превращается в приличные деньги, поэтому любой оптимайз — это чистая прибыль.

Магазин у нас состоит из трех основных собственных компонентов (сервер, база данных и php-скрипт) и сторонних сервисов (аналитика, онлайн-чаты, различные api перевозчиков, доноры данных и так далее…)

Если на сторонние сервисы мы можем влиять достаточно опосредовано. То внутренние находятся у нас под полным контролем и мы можем делать с ними все что угодно.

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

Давайте начнем с сервера и того, что можно с ним сделать:

1 — У нас есть наш айпи. Его нужно проверить по спам базам, настроить ему PTR и проверить доступность магазина из мира через host-tracker.

2 — Сразу настраиваем бекапы. Неважно какая у вас панель, операционная система — настраиваем бекапы и проверяем, как они работают. Люди деляться на три категории: тех, кто не делает бекапы никогда, тех, кто делает бекапы, и тех, кто проверяет поднимаются ли из этих бекапов данные.

3 — Настраиваем почту. Как это сделать  я уже не раз писал.

4 — Закрываем на хрен, все что можем закрыть порты ssh, убиваем ftp, убиваем phpmyadmin, отключаем лог ошибок php.

5 — Проверяем включен ли Opcache для PHP и если не включен — включаем.

6 — Версия PHP. Не гонитесь за седьмыми восьмыми айфонами. 5.6 — стабильная работает, в ней в коробоке есть opcache и по скорости для Opencart она не отличается от 7.x, но вы избегаете массы конфликтов.

7 — Ставим библиотеки для оптимизации картинок imagick, optipng, jpegoptim.

8 — Ставим memcache или redis.

9 — Включаем Nginx, настраиваем кеширование-сжатие статики, проверяем в гуглпейджспиде.

10 — Включаем http2, если у вас старый nginx, обновляем, проверяем наличие openssl 1.0.2 (из консоли nginx -V)  и проверяем работу http2 этим сервисом.

11 — Если совсем извратиться ставим Mariadb 10 (она поддерживает full-text индексы для inno-db таблиц, нужны для некоторых модулей поиска и для megafilter pro plus). И вносим в конфиг сервера mysql, минимальные тюнинг-правки (поддержку больших пакетов, увеличиваем размер буфферов для ключей  ну и по мелочи таймауты уменьшаем типа, чтобы вдруг чего база не ушла в глубокие думы). Очень полезная статья на хабре.

12 — Если совсем шибко хочется извратиться, вкручиваем php-fpm и вырубаем apache и оставляем связку nginx+php-fpm. Мероприятие само по себе без навыков стремное. Но если вы хотите быстрее быстрого и стабильно — не помешает. В итоге экономия на спичках в 50-60 миллисекунд на ответе сервера. Но кому то бывает надо. Вот тут, нормальный рабочий конфиг, правда ему там надо еще дописать www на без www и исключение дублирующихся слешей. И еще. Проверьте, чтобы виртуалхост работал через сокет а не чере tcp-порт. Через сокет получается быстрее.

13 — Смотрим  в логи ошибок вируталхоста, видим кучу ворнингов про upstream, которому маленький размер буфера. Идем в конфиг NGINX и добавляем ему размер буферов. Также не забываем про количество workerов, которые делаем равными количеству ядер.

14 — Ставим сфинкс. Сфинкс желательно ставить, не тот который  в ваших репах. А последний с официального сайта. Я на свой страх и риск в последнее время пользуюсь 2.3 Beta. Пока полет нормальный, но мне нужны кое-какие фичи именно из этого релиза.

15 — Если еще раз, ооооочень сильно хочется извратиться, подвешиваем сесии в memcache. Польза будет на большом трафике от 2-3к посетителей в день, и польза незначительная. фанаты рухайлоад ,могут почитать подробнее на рухайлоаде.

Теперь перейдем к базе.

1 — Индексы. В последнее время, все стали умные, начитались про индексы, а еще более умные наделалил недоделанных калек с бесплатных модулей, которые типа сейчас оптимизируют переоптимизируют все и вся. Должен вас расстроить — не соптимизируют. Есть несколько сложных запросов, которым крайне мало индекса на все id, а для их быстрой работы необходимы составные покрывающие индексы на десяток таблиц, о которых ни один модулепейсатель и оптимизатор даже не подозревает, и это только для голого движка. А там где дело касается фильтров, большого количества отзывов в модуле Маркимарка к примеру (он в курсе), и большого количества заказов, там могут быть любые сюрпризы и для оптимизации работы этих задач, необходим первичный мониторинг этих запросов — а потом эксперименты, эксперименты и еще раз эксперименты, как с индексами так и с самими запросами.
Вобщем индексы надо расставить, но расставить с умом, а не как тупая обезьяна с гранатой.

2 — Innodb. Недавно я столкнулся с магазином, в котором после переноса покрашились таблицы, и я очень долго восстанавливал его работоспособность. При использовании innodb, такого не происходит. Поэтому если вы параноик — стоит перебить все таблицы в этот тип. Но. Будет потеря производительности на 5-15%, именно в результатах запросов, и проблема с full-text индексами. Но она решается — я уже писал выше как. А чтобы не сильно тупило сделайте параметр innodb_flush_log_at_trx_commit = 1 что это и зачем — читайте в мануале. Так что для использовании innodb — есть только один аргумент — это сохранность данных. Тут — хозяин барин.

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

4 — По возможности проверьте весь хлам и удалите ненужные данные о товарах, атрибутах и всякую подобную лабудень. Часто бывает, когда у людей висит 2-3-4 набора таблиц в одной базе. Типа test new и так далее. Не стоит так делать. Проект в продакшне — это проект в продакшне в нем не должно быть ничего лишнего.

Теперь перейдем к скрипту магазина.

0 — проверяем права на папки. Были у меня пару раз истории, когда все тупило, ошибки выключены, магазин тупит, а просто надо было на папку кеша дать доступ.

1 — Даже если у вас нет медленных запросов, у вас может быть из общее количество в пару тысяч, и даже если каждый запрос выполняется 1 миллисекунду, то их обработка — это уже 2 секунды на выходе. Поэтому стараемся уменьшить общее количество запросов. Кешируем все что можно. Меню, модули категорий, модули хитов продаж и так далее. Первая задача оптимизации скриптов — это уменьшить общее количества запросов по максимум. Понятное дело что есть кодированные модули — но все куда дотянуться руки — кешируем, либо переписываем запросы.  Либо переписываем запросы и кешируем.

2 — Парсинг запускаем только по крону и только при помощи cli-php, никаких wget http://наш-магазин. Гоните таких писателей в шею. А еще желательно все кроны запускать ночью, если есть такая возможность.

3 — Все сторонние API, типа инстаграма — должны работать через AJAX, чтобы если инста лежит вместе с ним не лег у вас магазин, так как если вы из php стучитесь на сторонний ресурс и он лежит, то пхп ложиться вместе с ним.

4 — при желании забираем оптимизированные скрипты из гугл пейджспида, сливаем с CDN к себе локально шрифты, jqeury библиотеки, меняем все на .min, и все скрипты и стили, принудительно вписанные в  header.tpl объединяем в один файл (в два файла, один со скриптами, второй со стилями).

5 — Включаем кеши, там где можно включить, в модуле Марка. В мегафильтре, везде…

6 — Включаем поддержку Imagick и оптимизацию на лету картинок через jpegoptim и optipng. Как это сделать, я уже писал. Не забываем удалить кеш картинок и системный кеш, а потом их заново пересоздать, Xenus вам в помощь.

7 — Если хочется совсем быстро, подключаем redis или memcache, redis — предпочтительней, так как он без проблем работает с большими объемами данных и не сбрасывает их при перезагрузке, за счет использования дискового буфера.

8 — Если вы переезжали на https и использовали http-фикс, и уже переехали, желательно его выключить. Лишние str_replace  — это не хорошо.

9 — Фильтры все меняем на megaFilter  — он таки самый быстрый.

10 — Забываем про сео-фильтры, которые генерируют мусорные страницы без контента. По ним только боты шаряться и запредельно нагружают систему. В индекс такие страницы не смогут попасть, а тем более в топ выдачи. А вот санкции получить можно — как пить дать.

11 — Проверяем роботс и смотрим, чтобы у нас не было лишних открытых роутов. Идеальный роботс — это роботс в котором закрыты все get-параметры, через который роботы не смогут достучаться на любые сопли. Проверяем закрыт ли поиск, тэги, и комментарии. Я видел магазин в котором было 20 000 страниц исключенных яндексом — все это были комментарии. Поисковики очень не любят дурной контент.

12 — Проверяем доступность фидов  (сайтмап, yml) и по возможности используем только генерируемые по крону.

13 — Смотрим на размеры файлов кеша. Бывает модули генерят файлы по 20-30мб. Избавляемся от такого, так как парсинг туда-сюда.

14 — Ставим Сфинкс для поиска.

15 (отдельно по версии 1.5) Обновляем vqmod, хотя бы до версии 1.5  — дает +100-200 мс. Для магазинов на версии <1.5.6 обновляем класс работы с базой данных и драйверы mysql, mysqli, таки чуть быстрее и на 5.6 php не заведется без mysqli. Есть какая то мудацкая практика с драйвером mysqliz — но он тормознутый. Также в 1.5 — глобальная проблема с очисткой мусора в кеше. Он забивается и его надо чистить. Сделать это можно либо допиской garbage — коллектора в сам класс. Либо bash-скриптом по крону.

Наверное, я что-то упустил и местами не до конца раскрыл темы. Но вот такая вот «волшебная таблетка» выходит, которую надо съесть для качественной работы системы.  И просто «поставить модуль» отделаться не получается. Поэтому специалисты тут и так разберутся, а для неспециалистов теперь есть что предъявить оптимизаторам.

Хуйнаныр(27)Очко(0)

Запостить высер

20 Высеров на "Быстрый магазин и общие настройки как сварить? (чеклист)"

Стучать мне на мыло
avatar

Сортировать:   Свежие | Тухлые | Хуйнанырные
Bigbroo
робот-вертер
Bigbroo
18 дней 11 часов назад

Что, никто даже спасибо не скажет? )

Nameless
робот-вертер
Nameless
16 дней 23 часов назад

Для многих это просто довольно сложные для понимания вещи, поэтому ставим скромно палец вверх

stalker780
робот-вертер
stalker780
18 дней 6 часов назад

Только innodb_flush_log_at_trx_commit = 2.
1 это запись на диск, что будет тормозить.

stalker780
робот-вертер
stalker780
16 дней 18 часов назад

Еще за InnoDB не упомянуто, что он не блочит таблицу при инсерте. Только строку. Например у одного клиента было 49 импортов от разных поставщиков, в общей сложности 600тыс. товаров. Импорты, конечно старались запускать ночью, но при таком их кол-ве их запускали когда попало. И в моменты заливки и обновления 100тыс. товаров фронтенд магазина умирал. Поскольку ни каталог ни фильтры не могли получить доступ к таблице товаров, а импорт мог длиться час или два.
Переход на InnoDB решил эту проблему раз и навсегда.
У меня с тех пор все шопы крутятся только на InnoDB. MyISAM для меня умер.

Сами знаете кто
робот-вертер
Сами знаете кто
16 дней 22 часов назад

xcache еще можно включить
Он кеширует байткод php
Конечно влияние не велико но тот кто гонится за каждые 5 мс станет легче на душе :)

Женя
робот-вертер
Женя
16 дней 1 час назад

Йоху! есть что поделать на выходных :) Thanks!

Женя
робот-вертер
Женя
16 дней 1 час назад

По поводу сокетов, там есть спорные момент. Например если база и сервер на разных серверах то возможно стоит оставаться на tcp. Ну если мы не берем супер нагруженные сервера конечно, где с этим уже будет иметь смысл заморачиваться (например как и с редиской). Если ставить сокеты то надо увеличивать net.core.somaxconn что бы не было 500 ошибки. Ну это лично мое имхо, ну и из того что читал и тестировал.

Женя
робот-вертер
Женя
16 дней 31 минут назад

Yoda, А что за заверь Xenus? погуглил, не нашел… только какой то orm для mongodb, но это явно не то.

SooR
робот-вертер
SooR
12 дней 15 часов назад
Могу добавить, сегодня как раз наткнулся. Обязательно следим за тем, что и в каком объеме падает в лог ошибок php! Особенно у кого несколько шаблонов и все они не лучшего качества. В category.tpl в цикле товаров было 4 undefined переменных каких-то «всеводном» модулей шаблона. Умножаем на 40 товаров на страницу (у него так было) умножаем на количество страниц, получаем увесистый объем логов, + постоянные апдейты страниц и высокая активность… в итоге — 7 Гб (!!!) файл error.log. Думаю, комментарии о быстродействии такого магазина излишни. На продакшине отключайте логирование ошибок либо устраняйте их. Лучше второе, т.к. помимо лога движка есть еще… ЧЕТАТЬ ЕСТЧО
SooR
робот-вертер
SooR
12 дней 15 часов назад

Вижу, Yoda это указал, ну вот вам еще одно подтверждение.

kabantejay
робот-вертер
kabantejay
5 часов 32 минут назад

я еще обычно убиваю функцию обновления счетчика посещений которая пишет в базу +1 каждый раз когда к примеру зашли на товар

wpDiscuz