Нагрузки
Запись опубликована MiksIr ·
277 просмотров
Одной из задач, поставленной мне как проектировщику, было образно "а чтоб все не легло". Нагрузки. При разработке портала сразу закладывалось, что запросов будет много. Мы не экономили на ООП - стандартная MVС схема, все данные обернуты в объекты и т.д. и т.п., ибо экономия тут потом выльется в огромные потери по поддержке продукта. Мы не прикрывали кешем все подряд, но делали зарубки где это может понадобится.
Нарисовалась такая схема... DB кешу отказать. Ибо его очень сложно поддерживать в актуальном состоянии. Заложена возможность кеширования на уровне датамапера с хранением в мемкеше. Сейчас готовится некая прослойка перед датамапером, которая будет кешировать объекты запоминая от каких моделей они зависят, что позволит чистить кеш при изменении данных модели. Эту же прослойку будем учить делать "префетч" - прознозирование поведения посетителя и выборка данных заранее. Очень актуально в различных видах поиска с постраничным выводом - выгребать весь результат смысла нет, но и постранично выгребать накладно. Эта же прослойка позволит регистрировать в себе и другие готовые структуры данных непосредственно уже из контроллера.
Но первый удар на себя принимает конечно же статический кеш. Все сгенерированные страницы попадают в кеш, откуда их сервер берет уже не трогая PHP вообще. При генерации кеша состовляется реестр - какие модели использовались. Этот реестр позволяет делать выборочную очистку статики при изменении какой-то модели. Т.е. изменив одну новость не нужно удалять весь кеш - мы знаем где эта новость выводилась. Страницы, подврженные сильным нагрузкам, или, к примеру, очень часто запрашиваемые 404 страницы мы можем класть в мемкешь, и веб-сервер будет их отдавать еще резвее не загружая файловую систему (хотя учитывая умности файловой системы... следует еще подумать, насколько это актуально).
Что хорошо для разработанного с нуля продукта, то плохо для инфижена 
Да, конечно, он умеет кое-что кешировать. В базе. Даже прикрутили промежуточное хранение этих данных в мемкеше. Замечательно... но на этом разработчики IPB и остановились. Когда я только знакомился с инфишенном, меня озадачила функция по снижению нагрузки за счет переодического обновления счетчика просмотра. Посмотрев как это сделано - задумался. Оно понятно, что апдейтить нагруженную таблицу топиков накладно постоянно, и разработчики ipb решили делать инсерты во временную таблицу и по планировщику считать кол-во записей и апдейтить запись таблицы топиков. Хотя это понятно для MyISAM-а, для транзакционных же мешать работе такие апдейты не должны... но все же соглашусь с идеей, что апдейтить на каждый клик - плохо. Не соглашусь с тем, что N минут пользователь видит 0 в просмотрах своей новой темы. Очень неприятный момент.
Это был первый мой патч для IPB. Еще для 2.2.2 версии. Идея проста - операция с мемкешем дешевая. Можно писать, можно читать. Мы можем писать туда просмотры, и читать их на каждый просмотр темы, суммируя с тем, что в базе. По планировщику сбрасываем инфу из мемкеша в базу. Да, мемкеш не гарантирует хранения данных, но просмотры - это не деньги на счету, можно и потерять немного.
Дифф достаточно старый, в продакшн его не клали, вроде, и, думается, что к лучшему - неоптимально сделано
2 комментария
Рекомендуемые комментарии