У нас есть новостной портал. У нас есть 5 одинаковых выделенных ящиков. 2xE5620, 16 ГБ оперативной памяти, 4x146 ГБ, 15 КБ sas raid10. в настоящее время узким местом является mysql.
Один ящик - это балансировщик нагрузки (nginx), два поля (C, D) - это nginx и phpfpm, один - резервная копия mysql и один ящик - mysql.
На данный момент кеширование происходит в блоках C и D. Мы используем memcached, где хранятся результаты mysql. Иногда на странице есть белые поля (контент не загружен). Я уже делал атомарные вставки в memcached и производил полную отладку операций memcached.
Итак, я думаю, что, возможно, нужно создавать статические файлы. Когда новая статья публикуется, создайте для нее статический html-файл и используйте серверные включения для отображения количества комментариев и отображения того же содержимого комментариев. Затем nginx может кэшировать наиболее часто используемые файлы и обслуживать их из памяти. С помощью статических страниц мы также можем ускорить время загрузки страницы.
Я думаю о домене без файлов cookie, но не уверен, поможет ли это, потому что сетевой канал не является узким местом.
Вопрос: какую систему / модель кеширования использовать?
nginx имеет встроенное кеширование для обоих прокси и FastCGI. При вашей настройке вы можете выбрать либо использование кеша прокси в блоке балансировки нагрузки, либо кеш FastCGI на внутренних веб-серверах.
Один подводный камень: вам нужно убедиться, что вы не кэшируете обращения, которые содержат личную или пользовательскую информацию, а затем передаете их другим людям, поэтому используйте proxy_no_cache или fastcgi_no_cache и используйте блоки местоположения, чтобы исключить вашу административную и динамические области .
В зависимости от ваших пользователей они могут расстроиться или попробовать еще раз, если страницы комментариев кэшированы и они не видят свой комментарий сразу, поэтому, если вы кешируете страницы комментариев, вы должны добавить уведомление о том, что они могут появиться через несколько минут (или долго вы говорите nginx кешировать его).
Все это предполагает, что вы генерируете один и тот же HTML-код для многих посетителей (что обычно бывает для новостного портала, если только вы не выполняете индивидуальную настройку или ротацию рекламы на сервере). Если значительная часть ваших обращений генерирует уникальные страницы, тогда вам может быть лучше в краткосрочной перспективе изменить свою архитектуру, чтобы поменять балансировщик нагрузки на циклический DNS и дополнительный ведомый сервер чтения MySQL, предполагая, что ваша нагрузка тяжелая для чтения .