Назад | Перейти на главную страницу

Создание высокопроизводительного статического веб-сайта

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

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

Есть ли способ вместо того, чтобы NGinx + Varnish попал на диск для HTML-страниц, вместо этого он попадает в ОЗУ. Каким-то образом используя Memcached.

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

Спасибо!

[Отправлено с StackExchange: https://stackoverflow.com/questions/6439484/building-a-high-performance-static-website]

Хотя varnish абсолютно фантастичен с его гибким VCL, он действительно больше подходит для кеширования динамических веб-сайтов. Похоже, есть общее мнение о том, что nginx превосходит лак (по крайней мере, на небольших статических объектах).

Вы можете использовать proxy_cache, fastcgi_cache или просто работать с диска напрямую, используя nginx. Я знаю, что он поддерживает memcached, но единственное преимущество memcached будет заключаться в том, что у вас есть несколько серверов, использующих один и тот же кеш - кроме этого я вижу только дополнительные накладные расходы.

Вы можете либо позволить своей файловой системе (и, надеюсь, контроллеру рейда) кэшировать (наиболее часто используемые) данные, либо просто вставить их на RAM-диск!

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

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

Также базовые файловые системы действительно хороши для кэширования файлов при повторном чтении. Таким образом, я думаю, вы вполне справитесь с простым сервером без особой мощности процессора, но с достаточным объемом памяти для кеширования файловой системы и хорошей подсистемой ввода-вывода. Оптимальная система могла бы кэшировать все необходимые объекты в ОЗУ, поэтому вам должно быть хорошо с системой размером примерно (размер рабочего набора + 1 ГБ). В зависимости от размера ваших объектов, я также настоятельно рекомендую использовать SSD, по крайней мере, в качестве промежуточного уровня кэширования для вращающейся ржавчины, чтобы можно было быстро получить объекты, которых еще нет в ОЗУ. Шаблон ввода-вывода, который вы заметите, вероятно, будет довольно случайным, что SSD может выполнять легко, но при этом вращающиеся диски довольно плохо справляются.

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

(поступает некачественный ответ, другие знают это лучше меня):

Я почти уверен, что nginx в сочетании с быстрым вводом-выводом (RAM + SSD) легко обслужит 1000 клиентов с чисто статическим html-контентом.

Более стандартный способ сделать это - генерировать результаты на лету, а затем обслуживать последующие запросы из какого-то кеша.

Вы можете сделать это в коде с чем-то вроде redis или memcached (см. Базовый пример python memcached на https://stackoverflow.com/questions/868690/good-examples-of-python-memcache-memcached-being-used-in-python). Вы также можете просто использовать кеширующий прокси, например nginx, чтобы попытаться сделать это автоматически.