LINUX.ORG.RU

Архитектура высоких нагрузок


1

3

На странице http://ruhighload.com/post/%D0%90%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0+%D0%B2%D1%8B%D1%81%D0%BE%D0%BA%D0%B8%D1%85+%D0%BD%D0%B0%D0%B3%D1%80%D1%83%D0%B7%D0%BE%D0%BA в пункте «4. Кеширование» изображена архитектура(1) где сервера с php выступают по сути в виде прокси к единому memcache и базе. База и кеш едины потому что клиент первым своим запросом может попасть на один php сервер, а вторым на другой - поэтому данные и хранятся в едином месте.

Вопрос: какое количество клиентов потянет подобная система?

Скажем нужно обеспечить работу для одного миллиона периодически приходящих в течении дня клиентов. Насколько такая схема будет работоспособна?

Не упремся ли мы тупо в производительность базы данных и забитый канал до выделенного memcache?

Сколько и каких серверов можно поставить при такой архитектуре?

Плюсы тут в том что при отказе любого php сервера никаких проблем не будет. Минусы возможная просадка производительности.

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

Заранее благодарен за любые аргументированные комментарии!

★★★★

Последнее исправление: quest (всего исправлений: 1)

Ответ на: комментарий от xtraeft

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

quest ★★★★
() автор топика
Ответ на: комментарий от quest

Что ты к этому миллиону прицепился, это разве много? Если размазать поровну на сутки (чего конечно в реальных условиях не бывает) - это всего то 11 запросов в секунду.

Мой опыт тебе ничего не даст, потому что у меня таких объемов (миллион в сутки) бывают только узкоспециализированные веб приложения (tds на php-redis или сях) или статика.

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

xtraeft ★★☆☆
()
Последнее исправление: xtraeft (всего исправлений: 1)

Ссылку не читал, просто спрошу кто запрещает комбинировать подходы?

anonymous
()

у меня ни php, ни mamcache нет (и то, и другое тормозит), но и нагрузка побольше. использую m фронтендов + n бекендов. брат жив.

оба варианта в оп-посте — ткпиковый путь.

anonymous
()

Кстати, надо сходить проверить, как там моя системка живёт. Миллиона запросов, конечно же, нет. На запись может быть около полумиллиона. И навряд ли в сутки. Хотя хз.

Deleted
()
Ответ на: комментарий от anonymous

кто запрещает комбинировать подходы?

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

quest ★★★★
() автор топика
Последнее исправление: quest (всего исправлений: 1)
Ответ на: комментарий от quest

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

anonymous
()
Ответ на: комментарий от quest

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

Хорошая мысль спасибо.

quest ★★★★
() автор топика
Ответ на: комментарий от anonymous

Спасибо. Думаю использовать первую архитектуру но с разделением memcache на несколько серверов (как предложили выше) и mongodb в качестве базы. вроде как хорошо ложится на задачу и скорость должна быть хорошая - по сути все операции это чтение/запись по четким идентификаторам

quest ★★★★
() автор топика
Последнее исправление: quest (всего исправлений: 1)

Вопрос: какое количество клиентов потянет подобная система?

у среднего php приложения получается от 30 до 150 запросов в секунду на каком-нидь i7.

с mysql снимают от 300 до 30000 тыс запросов в секунду, в среднем по больнице - 5-10тыс с двухголового ксеона и базой в памяти, до 150GB горячих innodb данных на сервер.

итого - десяток php серверов, пара баз, пара серваков статики и пара мемкешей тянет 2-10 миллионов суточных посетителей с глубиной 10-14.

Не упремся ли мы тупо в производительность базы данных и забитый канал до выделенного memcache?

если сразу начинать с нагрузки (хотя бы с постоянных нагрузочных тестирований), не хранить в мемкеше блобы в несколько мегабайт, то проблем нет.

Сколько и каких серверов можно поставить при такой архитектуре?

статикой можно с одного сервера отдавать несколько тысяч файлов со скоростью 20-30 тыс запросов в секунду.

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

Кеширование даёт что-то по середине, в зависимости от количества обновлений и схемы кеширования.

Плюсы тут в том что при отказе любого php сервера никаких проблем не будет. Минусы возможная просадка производительности.

если нужно, все слова меняются на любые аналоги (php => java | python | ruby).

В этой схеме самое ограничивающее место - mysql. Без шардинга горизонтального или вертикального можно упереться где-то на 10 мульёнах посетителей даже с хорошими запросами.

Со слонами те же яйца только в профиль.

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

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

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

Можно держать и единые данные: mysql ndb (mysqlcluster) или в mysql fabric.

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

Википедия это один паттерн нагрузки, а твиттер - совершенно другой. соцсети - третий.

Поэтому так много фанатов разных узких технологий вроде twisted или nodejs с пеной у рта доказывают, что если бы взять вместо php язык XXX и фреймворк YYY, то тогда точно всё полетит, даже без кеширования. В реальности узкие места могут быть в совершенно разных местах (например, если есть коннект к базе, то lattency у запросов в 1 ms - обычное дело). Или если взять nginx + lua + прегенерация, то сайты типа лора можно на RPi запускать.

anonymous
()
Ответ на: комментарий от anonymous

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

quest ★★★★
() автор топика
Ответ на: комментарий от anonymous

у среднего php приложения получается от 30 до 150 запросов в секунду на каком-нидь i7.

это с кешированием опкода?

xtraeft ★★☆☆
()
Ответ на: комментарий от xtraeft

apc или xcache, классы, инклуды, 3-4 запроса в базу, сессии в мемкеше

Без кеширования что-нидь жёсткое типо друпала может и до 5 запросов в секунду провалиться.

anonymous
()
Ответ на: комментарий от quest

с базой та же история https://blogs.oracle.com/mysqlinnodb/entry/mysql_5_7_3_deep

http://voltdb.com/tags/benchmarking

http://vibhorkumar.wordpress.com/2014/05/15/write-operation-mongodb-vs-postgr...

если данные влезают в половину памяти и запросы с однородным временем ответа, то скорость +- корова у баз будет одинаковая.

Данные, которые нельзя терять или нужна транзакционность лучше хранить в чём-то надёжном.

Если надёжность не так важна, то есть альтернативы типа redis или voltdb с низким временем ответа для in memory нагрузки, из схемы можно смело убирать memcached.

Если у mongodb индексы не влезают в память, то он просядет сильнее чем мускуль или постгря. Если нужен гео поиск то постгрес опять же может быть бодрее mongodb.

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

anonymous
()
Ответ на: комментарий от xtraeft

В замерах разницы нет.

Часто бывает, что на одном и том же php коде не работает один из кешеров (крашится php в разных точках), а другой работает.

Упавший процесс php-fpm или apache может перед смертью повредить сегмент с shared memory (меньше всего проблем с mmap реализациями). В этом случае приходится ограничивать время жизни процесса до 100-500 запросов перед перезапуском в этом случае количество сегфолтов у php в сутки снижается. При повреждении сегмента для популярного файла крашиться начинают уже все процессы для данного сокета / порта. Такие случаи бывают не так часто (раз в один-два месяца под нагрузкой) и их проще лечить автоматическим перезапуском демона или мониторингом и разбором полётов. Клиент само-собой всех этих проблем не наблюдает, т.к. nginx на 500е запрашивает другой бекенд.

anonymous
()
Ответ на: комментарий от anonymous

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

Лично я всю дорогу всегда использовал postgres, mongodb меня тут привлекает только шардингом на несколько машин - распределением нагрузки.

quest ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.