Разработка сайтов, дизайн и мультимедиа
+38 044‎ 494 35 20
Главная / Лаборатория / Оптимизация под нагрузку в SunSite CMS
Лаборатория
Заполнить бриф on-line

Оптимизация под нагрузку в SunSite CMS

Оптимизация под нагрузки осуществляется за счет доводки следующих составляющих:
1. Веб-сервера
2. Сервера баз данных
3. Оптимизации скриптов 

Оптимизация веб систем построена на одном основополагающем базисе: не выполнять одну и ту же операцию для разных пользователей более одного раза. 

Большинство современных сайтов работают по сути в режиме отображения текущего состояния базы данных. Т.е. сайт является интернет-отображением сформированной проектировщиком базы данных и документов. Например, при отображении пользователю товара X, происходит обращение к базе данных товаров, скрипт принимает все паарметры товара: название, цена, описание, оценку пользователей, характеристики отражающие отличие от других товаров этой же категории и т.д., потом скрипт формирует на основании характеристик запрос к базе данных на сопутствующие товары, на похожие товары и т.д. Получив все необходимые данные, скрипт формирует HTML-документ, в котором используются эти данные и отображаются в браузере посетителя. Причем, если этот же пользователь нажмет в браузере F5, то ему скрипт выдаст одну этот же HTML 1 в 1, произведя все те же обращения к базе данных. И пока не изменится название, цена и/или другие данные, которые используются при выводе этой страницы, результат будет всегда идентичным. Так почему бы нам не сохранить где-то его, и использовать при повторном обращении пользователя, минуя запросы к базе данных, вычисления правил соответствия связанных товаров и другие вычисления, которые производились в этом скрипте.
Зачастую так и поступают - сохраняют на диске в определенном папке эту html-страницу, а при поступлении запроса от пользователя - происходит проверка существования такого файла на диске, и если он существует - отдается полностью готовая страница, без обращения к скриптам и базам данных. В случае нашей CMS, кеш складывается в /cache/data/$http_host и для nginx конструкция проверки на наличие сохраненной копии в кеш-папке происходит следующей конструкцией:
if (-f $document_root/cache/data/$http_host$uri) {
rewrite ^(.*)$ /cache/data/$http_host$uri last;
break;
}
В нашем распоряжении есть еще вариант сохранять в memcached - http://nginx.org/ru/docs/http/ngx_http_memcached_module.html
Но при организации кеша на диске, имеется дополнительная возможность использовать предварительно сжатый html http://nginx.org/en/docs/http/ngx_http_gzip_static_module.html, что существенно снижает нагрузку на процессор при отправке современным браузерам сжатые версии файлов стилей, javascript, html и др.

Кроме того, у разработчика имеется дополнительный вид кеша - "сессионный". Суть оптимизации заключается в сохранении вычислений для конкретного пользователя, для конкретной сессии. Сброс этого кеша происходит по событиям login/logoff - т.е. когда пользователь поменял свой идентификатор пользователя.

# Инициализируем переменные для проверки сессий
if ($http_cookie ~* "xs=(.)([^;]+)") {
set $s_part_1 $1;
set $s_part_2 $2;
}

# Проверяем лежит ли запрос в сессионном кеше. Если файл есть - отдаем nginx-ом
if (-f $document_root/cache/sessions/$s_part_1/$s_part_1$s_part_2$uri) {
rewrite ^(.*)$ /cache/sessions/$s_part_1/$s_part_1$s_part_2$uri last;
break;
}

×
  • Facebook
  • Google
  • Twitter