Ваш пиковый трафик?

1. 40к в сутки

2. Самопис

3. Выделенный сервер с Xeon, 16Gb ОЗУ, nginx + php7 + mysql5.6 + Redis

Сам движок справлялся на ура, было хорошее кеширование посредством Redis. В какой-то момент пришлось увеличить лимиты открытых файлов для Nginx (вывались ошибки в пик трафика, т.к. по умолчанию лимит 1024 файла). PHP-сесии были также перенесены в Redis.

Главная проблема - нагрузка на диски. Были две нерейдовых диска, по которым размазан контент. Сайт - видеотуб, с постоянно практически забитым каналом 1Gbps, дискам было тяжеловато. При этом на одном из этих дисков размещалась и система. Часто таскал части контента с одного диска на другой, чтобы уровнять нагрузку, /var/lib/mysql в какое-то время тоже пришлось перенести на второй диск. В общем, напрашивалась конфигурация с отдельным диском для системы.

В общем, ситуацию в итоге решил приобритением второго идентичного сервера, ежедневным зеркалированием на него всех данных (заодно и решился вопрос бекапа, которого, к слову, не было). Движок юзерам отдавал контент то с первого, то со второго сервера, распределяя тем самым нагрузку на канал и диски.

ни говорит ни о чём. у вас может быть 2 посетителя в день и пару миллионов запросов от ботов.

1. В минуту: 17 тыс посетителей, 80 тыс хитов, 400 тыс записей в логе.

2.1. Perl (без фреймворков) + mySQL - N раз в период перегенерация статики (на основе логов и количества нового контента) + упаковка gzip каждого html. Почти не заметно, что это статика, проект - как любой динамический, но некоторые изменений на сайте - с небольшой задержкой.

2.2. Два сервера (8 ядер, 64 ГБ, ssd). Трафик распределяется RR DNS + сервера в разных ДЦ, проверяют доступность друг-друга и переключат трафик на себя в случае недоступности.

Вообще, мое мнение, большинству сайтов не требуется постоянно генерировать и отдавать страницу скриптом. Можно генерировать статику раз в день/час/минуту для всего или части сайта, всей или части страницы. Даже комментарии к статьям также можно отдавать статикой, просто добавлять новые (до генерации) с помощью js.

---

Проблемы решались по мере роста.

1. mysql - ничего не пишется онлайн, только в текстовые логи, и при перегенерации страниц логи читаются, анализируются и уже тогда пишутся нужные данные в таблицы. Например, если считается посещаемость каждой страницы - глупо при каждом выводе страницы инкрементировать счетчик в базе (на основе логов считаем посещаемость всех страниц за период и изменяем все за раз).

2. трафик - очень быстро и приблизительно анализируются логи (на Go), при превышении лимита трафика - все картинки переключаются на сильно переоптимизированные их версии (отдельный каталог). И уже потом анализируется - временный всплеск или постоянный: нужно ли расширять канал.

3. диск - почти все кешируется в памяти.

4. коннекты - проверятся кол-во и при превышении указанного мною лимита временно включается в sysctl: TCP_TW_RECYCLE и TCP_TW_REUSE. Но, сейчас не особо помогает в моем случае.

Последняя проблема:

conntrack (модуль iptables) не справляется с таким количеством IP: отключить его или NOTRACK

133 тыс. в сутки

1. ~40 rps в течение 2 часов

2. самопись

2.1 чистый PHP 7

2.2 memcached

3. 2*2ГГц 2ГБ 30SSD | nginx maria (выдерживал примерно такую же нагрузку и на шареде, в 100 минут процессора вписывался)

Dimka, вот это действительно HighLoad. Perl вообще не ожидал увидеть. По поводу генерации страницы скриптом, согласен. Актуальность нужна на всяких сайтах с Real-Time чартами, статистикой, etc. Даже новости можно (даже нужно) кешировать, а при добавлении сбрасывать кеш. Ещё классная фишка - обмен данными с сервером через Protobuf или JSON. Экономит трафик и время ответа сервера, т.к. шаблоны на клиенте отрисовываются. Даже быстрее чем статику с диска отдавать. Хотя ещё быстрее - хранить статику уже отрисованную в памяти RAM и сразу её отдавать. Тут даже с данными работать не нужно.

А как вы картинки быстро на статике переключали? Прилинковывали другой каталог?

1. zcat /var/www/access.log.2.gz | cut -d[ -f2 | cut -d] -f1 | awk -F: '{print $2":00"}' | sort -n | uniq -c

57796 00:00

56298 01:00

67880 02:00

85651 03:00

103907 04:00

128408 05:00

155606 06:00

157047 07:00

163586 08:00

161579 09:00

170041 10:00

161604 11:00

177619 12:00

161532 13:00

160274 14:00

149201 15:00

162923 16:00

138125 17:00

129069 18:00

102514 19:00

74928 20:00

56523 21:00

46348 22:00

43756 23:00

(статика не логируется, fyi)

2. самопис

2.1 самопис, т.е. собственный язык программирования, PostgreSQL, Redis

2.2 кэширование пока отключено за ненадобностью

3. VPS 4 ядра от E3-1271V3, 8 Gb RAM, SSD RAID10. load average: 0,25, 0,17, 0,15

nginx: перезагрузка конфигурации с новым root. Возможно есть более простое решение. Сейчас это очень редкое событие - т.к. канал с большим запасом.

---------- Добавлено 11.04.2017 в 17:49 ----------

Компилируемый? Почему свой? Чем отличается от существующих?

Непосредственно в машинный код он не компилируется, это больше на убер-шаблонизатор похоже, так что это не требуется. Ну что-то типа xslt или jstl. Само ядро написано на C++, все функции имплементированы в виде компилируемых модулей, а прочее - загружается в память один раз и исполняется там.

Потому, что могу :D На самом деле 18 лет назад особо вариантов не было. Perl и PHP были ужасны, поэтому захотелось сделать что-то более подходящее для веб-разработки.

Собственно, всем. Например, от основан на XML и не C-подобный :D

Оптимизайка, а чем сайт вообще занимается, хоть приблизетельно: SAAS, новостник, блог, etc.? Load Average в пике 0.25? Для 4 ядер это-же смех. А RAM как используется?