Схемы ускорения веб-сайта / Mysql + Шаблонизаторы и кеширвоание
Схемы ускорения веб-сайта / Mysql + Шаблонизаторы и кеширвоание
Теория...Представим ситуацию — клиент хочет, чтобы его сайт (который 3 года назад написал студент-самоучка) работал быстрее. Вариант написания сайта с нуля заказчика не устраивает по каким-то причинам: нет денег, времени, понимания, что корявое навсегда останется корявым. Задача — поставить сайт на подпорки в кратчайшие сроки. Предлагаю несколько вариантов решения проблемы. Конкретных технических решений не будет, тут все зависит от того, в каком состоянии получили сайт и его бизнес-логики. [h1]Вариант 1 — «Быстро и дешево»[/h1] 1. Анализируем сайт в целом, если PHP обрабатывает довольно большие объемы данных — то немного ровняем код: используем короткие имена переменных, оптимальные проходы по циклам, обходы многомерных массивов. В случае когда все циклы и массивы не содержат больше 20-30 элементов этот этап можно пропустить. 2. Оптимизируем запросы к MySQL. Минимизируем их количество, проверяем индексацию с помощью EXPLAIN, ищем относительно медленные запросы и делаем их быстрее. Если нужно — можно добавить некоторые столбцы с вычисляемыми данными в таблицы БД, это может сократить количество лишних запросов. Ну а стопроцентная нормализация не так уж и нужна. 3. Внедряем AJAX там где это действительно нужно — всевозможные голосовалки, отправка комментов, подгрузка небольших блоков с данными, отправка данных от пользователя. Это уменьшит количество запросов на генерацию страницы и к БД. Да и пользователю сэкономит время и трафик. 4. Настраиваем кеширование Smarty(или его аналога) на статических страницах. Конечно если Smarty вообще есть. В результате за 2-3 дня можно снизить нагрузку в 3-4 раза. Клиент на год-два останется счастлив — сайт держится на костылях, вы с деньгами в кармане можете заслуженно идти отдыхать. [h1]Вариант 2 — «Качественно»[/h1] Если в планах имеется быстрый рост количества клиентов, то следует уже раскошелиться и на серверные мощности с на наличием SSH и возможностью установки на сервер нужного ПО. Конечно и программист будет работать не 2-3 дня. Для начала стоит повторить этапы из предыдущего варианта «Быстро и дешево». 1. Уговорить заказчика перейти на VPS за 50-100$ в месяц. Само по себе это даст запас прочности, но не стоит расслабляться — мы ведь рассчитываем на большие нагрузки! 2. Настройка кеширования — Memcached. Кешировать нужно все и вся — особенно результаты частых и тяжелых запросов к MySQL. Главное тут не напортачить с подогревом ключей и временем жизни кеша. В результате получим ускорение в десятки раз (зависит количества запросов к кешу до его обновления). 3. Замена Smarty на более быстрый шаблонизатор Blitz. Он написан как PHP-модуль на Си. Работать с ним поначалу непривычно и долго, но скорость генерации страницы у Blitz выше почти в 2 раза. 4. Можно также настроить кеширование страниц и их частей страниц с помощью кеширующего сервера Varnish и языка ESI. Более подробно описано тут После недель упорных трудов — наш сайт уже крепко стоит на своих подпорках и действительно не боится highload. [h1]Вариант 3 — «Долго и дорого»[/h1] Нестоит забывать и об масштабируемости. Если база данных начнет расти за пределы сервера, то масштабирование MySQL даже по 2м серверам станет неприятной неожиданностью. Тут лучше подумать об внедрении хранилища данных по типу key-value(ключ-значение, NoSQL). Такое хранилище легко масштабируется по 2 и более серверам и является гораздо более быстрым, чем «тяжелый» MySQL. Для начала выполняем все этапы описанные выше, за исключением оптимизации MySQL — ведь СУБД мы будем менять. На данный момент существует уже довольно большой парк key-value хранилищ и он с каждым годом растет. Одним из быстрейших является Redis, похожий по структуре на Memcached с дополнительным функционалом для хранения и выборок данных. Redis хранит все данные в оперативной памяти серверов, периодически делая снимки памяти на файлы на диск. По ключу можно записать любой набор данных — как обычные числа, строки, массивы, так и списки, множества и упорядоченные множества. По тестам скорости операций выборки или записи данных — Redis оказывается в 10-15 раз быстрее MySQL. Перенос данных из MySQL в хранилища задача нетривиальная, тут главное внимательность и усидчивость, чтобы сохранить 100%ную целостность данных. А вот PHP-код придется переписать практически с нуля. Поэтому я и назвал этап «Долго и дорого». [h1]Заключение[/h1] Как видим, почти любой сайт можно основательно ускорить за считанные дни. Тут все зависит от ресурсов заказчика — как материальных, так и временных. Для наглядности я набросал блок-схему(почти по ГОСТам) этапов оптимизации. На ней можно проследить все 3 вариант решения проблемы.
[h1]+Как использовать команду EXPLAIN[/h1] Самая мощная команда в MySQL – это EXPLAIN. EXPLAIN может в точности рассказать вам, что происходит, когда вы выполняете запрос. Эта информация позволит вам обнаружить медленные запросы и сократить время, затрачиваемое на обработку запроса, что впоследствии может значительно ускорить работу вашего приложения.
| Code: |
EXPLAIN SELECT … |