построение системы для обработки большого числа запросов
Ищу решение для следующей ситуации:
Существует приложение с динамическим формированием объектов. т.е. например, у меня есть приложение, которое обслуживает 200 запросов "одновременно" (за 5 секунд "вычисляются" 1000 web-ответов).
При увеличении загрузки я планирую использовать отдельный сервер для "распределения" запросов (load balancer) между такими серверами. Но какую ожидать модель поведения ??? Ведь не отказ в обслуживании надо получить, а надежность за определенную избыточность (цена которой лишние сервера).
Какие последнии рекомендации о массштабировании систем и о том, как прогнозировать увеличение загрузки и скорости выполнения (скажем для 100000 запросов)? Как правильнее эмулировать "предельную" нагрузку - чтобы понять, когда пойдут отказы ?
Из чего сделать вывод, что лучше - увеличить мощность сервера (установить более быстрые процессора), улучшить память, увеличить ее объем или добавлять дополнительный сервер ?
*Origin: чем больше процессов, тем медленее между ними переключение ;-(
| |
Re: построение системы для обработки большого числа запросов
Какие последнии рекомендации о массштабировании систем и о том, как прогнозировать увеличение загрузки и скорости выполнения (скажем для 100000 запросов)?
Для балансировки такой экстремальной нагрузки можно рассмотреть использование аппаратного балансировщика. Центральному софтварному серверу будет сложно справить с такой нагрузкой, и опять же SPOF.
Если используется ASP.NET или Java EE, то там есть готовые решения для организации т.н. web farm (множество серверов). Так же для web систем существует т.н. DNS load-balancing (DNS сервера выдают разные IP, возможно в зависимости от географического расположения клиента, например Google такое использует).
А так, в целом, всё зависит от деталей - самые эффективные оптимизации всегда проблемно-зависимые. Например, если можно нагрузить клиентов балансировкой, то это будет очень разумно - т.е. клиенты сами выбирают из нескольких серверов и к нему коннектятся - нет центрального bottleneck'а, нет SPOF.
---------------------------------------------
All about lock-free algorithms, multicore, scalability, parallel computing and related topics:
www.1024cores.net | |
Re: построение системы для обработки большого числа запросов
Как правильнее эмулировать "предельную" нагрузку - чтобы понять, когда пойдут отказы ?
Выделить use-cas'ы целевой системы, исходя из этого опредлить соотношение запросов разных типов. Т.е. например, 20% запросов типа 1, 50% запросов типа 2, 30% запросов типа 3. В таком соотношении и подавать запросы во время теста.
Елси речь идёт о глобальной системе, то бич таких систем - "медленные клиенты". Т.е. например 10% соединений будут очень медленными, сервер будет готовить "объёмный" ответ для этих соединений, однако ответ будет отправляться долго, соотв. висеть в памяти сервера. Целесообразно это тоже включить в тест. Я думаю, что это можно сэмулировать программно в тестовом клиенте - установить очень маленький буфер для сокета и не вычитывать его.
---------------------------------------------
All about lock-free algorithms, multicore, scalability, parallel computing and related topics:
www.1024cores.net | |
Re: построение системы для обработки большого числа запросов
Из чего сделать вывод, что лучше - увеличить мощность сервера (установить более быстрые процессора), улучшить память, увеличить ее объем или добавлять дополнительный сервер ?
По поводу памяти и процессора - очень просто - достатчно поглядеть на объём занимаемой процессом памяти и загрузку процессора. Если что-то из этого "на пределе", то увеличение пойдёт на пользу. А если, например, процессор загружен только на 50%, то ставить более быстрый процессор бесполезно.
По поводу диска тоже надо оценить используемую пропускную способность и насколько она близка к теоретическому максимуму. Если близка, то можно увеличивать скорость диска (ставить RAID или SSD).
По поводу скорости памяти... хм... не знаю... наверное надо профилировать и смотреть аппаратные счётчики производительности и считать какой процент времени процессор простаивает из-за ожидания памяти...
Т.е. общий принцип: (1) смотреть какой ресурс является основным сдерживающим фактором, т.е. загружен на 100%, увеличивать его. goto (1).
---------------------------------------------
All about lock-free algorithms, multicore, scalability, parallel computing and related topics:
www.1024cores.net | |
Re: построение системы для обработки большого числа запросов
Из чего сделать вывод, что лучше - увеличить мощность сервера (установить более быстрые процессора), улучшить память, увеличить ее объем или добавлять дополнительный сервер ?
*Origin: чем больше процессов, тем медленее между ними переключение ;-(
В самом деле, почему вы не используете такое стандартное решение как веб-фермы? Заодно повысится надежность системы. При это не стоит ставить очень мощные сервера, лучше поставить 10 средних, вместо 2 мощных. (и подешевле выйдет) Именно так поступает Google: http://research.google.com/pubs/papers.html
А вот обощение на русском: http://www.webplanet.ru/news/reading-room/2005/12/5/archit.html
Думаю вам будет интересно как с такими проблемами справляется Гугл.
| | |
