Интернет журнал InterneR IT-ЖУРНАЛ: ИНТЕРНЕТ, ГАДЖЕТЫ, ТЕХНОЛОГИИ

Как уменьшить нагрузку сайта на сервер?

Прежде всего программист должен внимательнейшим образом изучить RFC, а администратор особенности серверной ОС и программное обеспечение. Не просто так, мануалы почитать, а еще и внимательно просмотреть исходный код. За живое тема просто задевает, т.к. всегда на шаг впереди, а то и на десять. Это не просто так, sql запросы оптимизировать, оно порой бывает и так оптимально все, но из-за самой задачи оптимизация заходит в тупик.

Вот стата в нашем seo модуле под vbulletin, она собирается insert-ами в несколько табличек... по четным периодам в одну, по нечетным в другую. Следовательно когда одна таблица отдыхает, то её обрабатывает, агрегирует и чистит - лучше не придумаешь. А что будет, если mysql не будет справляться с потоком записи? Ну и... ну и... ну и будем писать в fifo, на fifo сборщик/агрегатор и репорты в таблички, неспешно причем - лучше не придумаешь.

Пример - боремся с медленными клиентами. Алгоритм тупой - если у нас все на GET запросах, то на freebsd врубаем accf_http и рестартуем апач, смотрим зацепил ли он его и идем спать. Если кому-то интересно, почему под все остальные методы кроме GET я рекомендую ставить nginx, то идем в сорцы accf_http модуля и смотрим принцип его работы. Как только он видит что-то отличное от GET или HEAD, то он пропускает это сразу, т.е. идет выделение ресурсов для обработки запроса, а запроса, по сути, еще нет.

В данном случае мне приятно на низком уровне это все пояснять, т.к. по этой теме мы давим на всю ивановскую... следовательно accf_http для ресурсов с POST запросами, т.е. к примеру фотогалереи посещаемые и т.д., не является 100% решением. Что у нас происходит на самых низах - приходит куча клиентов с мобильников, с диалапов, да и просто с меговыми фотками и дальше все они занимает один "слот" на нашем веб сервере. Лимит на нашем сервере, к примеру, 200 одновременных подключений. 200 медленных закачек и все, приехали, остальные запросы в очередь, если пик продолжается, то все успешно накапливается пока не сдохнет.

Ставим акселератор, ну пускай это будет squid или еще какая ферма. На что мы натыкаемся... решение универсальное, но опять же пробивается до задника. Народ тыкает рефреши, куки и все остальное - все в rfc описано. Акселераторы, кэширующие особенно, они по большей массе rfc соответствующие или совместимые. Конечно же возможность гибких настроек есть, но надо смотреть по проекту конкретному. Если грамотно присобачить фронт, то можно раскачать производительность в сотни раз.

Программист все хорошо продумал, все замечательно, в локальных кэш-ах браузера все хорошо кэшируется, нагрузка спадает на 70%, реальная цифра. Причем нагрузка по количеству приходящих запросов.

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

И вот, что бы этим всем профессионально заниматься, надо читать доки, изучать исходники серверного ПО и выбирать оптимальное решение. То, что порой бывает описываю, грозит только проектам с 2-3 тыс конектов одновременно и наплывом в 300-400 новых запросов в секунду. WAP один чего стоит...
(Спасибо, kostich)