10.000 обращений в секунду :)

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

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

Кстати, игнор на форуме - та самая вещь, которая мешает кешировать страницы. В перспективе его все равно отключат.

pupseg, Спасибо за информацию, принял её к размышлению. Тема в первую очередь для того, что бы одному знакомому дать понять что конкретно надо для того, что он хочет, а то многие тут сразу решили что это надо лично мне или пришедшему ко мне клиенту или еще какая-то муть, я понимаю что одним сервером не решается такая задача, а аналогичные (пусть и не много) я уже решал, но объективность достигается тогда , когда кроме меня аналогично думает кто-то другой. :))) Интересно только бы узнать , описанная вами система из 60+ серверов какой производительностью обладала? Я имею ввиду количество обработанных запросов в секунду.. !?

Так же спасибо за ссылку на PDF, интересная схема.

да всегда пожалуйста. я не считал запросы\с, но это банеро-генерилка-кликалка для адвертов. в топовое время нагрузки было более 3млн одновременных кликов на один банер. думаю можно это считать за запрос, даже серия запросов. это составляло 40-50% всей мощности. Хозяин считал так: если несколько раз повторяется долговременный рост нагрузки выше 70%, то ставим еще воркеров. Нагрузка определялась самописной опрашивалкой по snmp показаний воркеров: время отклика nginx, время реакции fpm, время отдачи, показания htop, top -d 1. По этим циферкам делали примерную общую нагрузку.

Если вникнуть очень приближенно, то в принципе моя схема - проста. ничего сверх-гениального нет в ней.

В вашем случае - мне кажется - есть узкое место: база данных. MySQL до сих пор не умеет вменяемо чтото параллелить и балансить. Репликация мастер-мастер - это не совсем то, даже совсем не то. Значит нужно переходить на percona, но - я не программист, детально не скажу, но насколько мне известно у перкона есть свои нюансы в SQL-запросах, работе с движками и т д. Percona xtra db cluster рекомендуют собирать из 3+ серверов, а не из двух, так как один из трех в минимальной сборке - это севрер-контроллер, который контроллит целостность работы двух нод, ну или сколько их там у вас будет.

Далее у вас есть контент, в данном случае php-скрипты их можно синхронизировать без проблем через какой-нибудь lsyncd, не использовать для этого блочные девайсы, drbd - не подходит. Да и вообще опасная штука, rm -rf /dev/drbd0 и все, можно сказать - данные потеряны на всем диске. Так вот - синхронизировать на другие воркеры, настроить на них fpm + nginx.

Картинки - можно отдельный сервер или группу серверов поставить под них, varnish -отдельный сервер, класть в него css, js какой-нибудь. Счетчики, статистику и прочий изврат - вынести из MySQL\percona в Redis - это сильно разгрузит мускуль ваш, если используете счетчики, статистику и т д.

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

Настроить то можно все что угодно, но 90% сайто-владельцев думают, что "построим кластер и все будет быстро", и потом приходится очень долго рассказывать, что нужны программисты))))

ну все вышеописанное - это чисто субъективно ...

Ну, почему не решается одним сервером? Я же приводил графики, где видно больше 5к реквестов в секунду. Сервер полностью обслуживает сайт на livestreet CMS, база mysql, пхп, статика, все на одном сервере, + отдельно еще стата через node.js собирается по конкретным топикам,помимо сайта, есть еще и форум, конечно не масштабов серча. Так каждый топик можно комментировать, и там в некоторых топиках бывает по нескольку комментариев в секунду.

В индексе гугла:

Возможно с годами ТС откроет для себя амазон... или 10 амазонов.

Это чтобы своё не городить и с ДЦ о посуточной аренде не договариваться.

Из ваших графиков я увидел только Connections и Sockets, какой из них является графиком количества запросов в секунду? Ведь соединения это совсем не то.... и netstat который приведен вами , это тоже не то... у меня по нетстат established около 2х тысяч на более менее слабо нагруженном сервере, но причем тут 10.000 запросов в секунду не могу понять хоть убейте.... растолкуйте, может я что-то не понимаю....

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

С одной стороны логично, если вы про GEO сервисы, но больше интересует не их распределение на разные узлы, а обработка в одном месте, стало быть все 10к\сек приходят со всего мира на один узел. Что в этом случае посоветуете? 🍿

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

А по поводу нюансов? Там только deadlock'и могут чаще возникать в кластере, а так перкона - это типа "drop-in replacement"