Оптимизация производительности для интерактивных веб-сайтов - PullRequest
2 голосов
/ 22 ноября 2008

Я недавно завершил разработку веб-сайта со средним трафиком (?) (Максимум 60 тыс. Посещений в час), однако сайт нужно обновлять только раз в минуту, а достижение требуемой производительности можно суммировать одним словом. : "кеширование".

Для сайта, подобного SO, где данные, поступающие на сайт, постоянно меняются , я бы предположил, что требуется другой подход.

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

Полагаю, вам понадобится распределенный кеш для управления обслуживанием данных и страниц, который обновляется порядка нескольких секунд, и, возможно, распределенный кеш над базой данных для посредничества при записи?

Могут ли те, у кого более опытный опыт, описать некоторые ключевые архитектурные / дизайнерские принципы, которые они используют для обеспечения высокой производительности интерактивных веб-сайтов, таких как SO?

Ответы [ 2 ]

3 голосов
/ 22 ноября 2008

Подавляющее большинство сайтов имеют гораздо больше операций чтения, чем записи. Нередко тысячи или даже миллионы обращений к каждой записи.

Следовательно, любое решение по масштабированию зависит от отделения масштабирования операций чтения от масштабирования операций записи. Как правило, масштабирование операций чтения действительно дешево и просто, а масштабирование операций записи является сложным и дорогостоящим.

Самый простой способ масштабирования операций чтения - это кэширование целых страниц за раз и истечение срока их действия через определенное количество секунд. Если вы посмотрите на популярный сайт, Slashdot. Вы можете видеть, что именно так они масштабируют свой сайт. К сожалению, эта стратегия кэширования может привести к не интуитивному поведению для конечного пользователя.

Из вашего вопроса я предполагаю, что вам не нужен этот примитивный вид кеширования. Как вы упомянули, вам нужно обновить кэш на месте.

Это не так страшно, как кажется. Главное, что нужно понять, это то, что сервер . Stackoverflow не обновляется все время. Обновляется довольно редко. Может быть, один или два раза в секунду. Для компьютера секунда - это почти вечность.

Кроме того, обновления, как правило, происходят с элементами в кэше, которые не зависят друг от друга. Рассмотрим переполнение стека в качестве примера. Я представляю, что каждая страница с вопросом кэшируется отдельно. Большинство вопросов, вероятно, имеют обновление в минуту в среднем в течение первых пятнадцати минут, а затем, вероятно, один раз в час после этого.

Таким образом, в большинстве приложений вам едва нужно масштабировать записи. Их так мало и далеко друг от друга, что вы можете иметь один сервер, который делает записи; Обновление кеша на месте - это вполне жизнеспособное решение. Если у вас не очень высокий трафик, вы будете получать очень мало одновременных обновлений одного и того же кэшированного элемента одновременно.

Так как вы это настроите? Мое предпочтительное решение состоит в том, чтобы кэшировать каждую страницу индивидуально на диске, а затем иметь множество веб-голов, доставляющих эти статические страницы из некоторого взаимно доступного пространства.

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

Я обнаружил, что этот дизайн соответствует всем требованиям к масштабированию, которые мы до сих пор требовали. Но это будет зависеть от характера сайта и характера нагрузки в отношении того, правильно ли это делать для вашего проекта.

3 голосов
/ 22 ноября 2008

Вас может заинтересовать эта статья , в которой описывается структура серверов Викимедиа Очень поучительно!

Статья ссылается на этот pdf - не пропустите.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...