У нас есть новый клиент, для которого мы рассматриваем нашу серверную инфраструктуру.
Я довольно хорошо знаю веб-API, потому что помогал в его создании, и теперь я сам поддерживаю и продвигаю его вперед, что очень сложно и интересно.
Он основан на экземпляре Amazon m1.large, nginx (+ ssl), django, amazon RDS (с MySQL) и на собственном сервере memcached.
Дело в том, что у нас были некоторые данные от нашего клиента, говорящие о том, что они ожидают, что максимум 2500 пользователей будут подключаться к API в течение четырех часов, по крайней мере, два раза в день.
Мы не знаем, когда именно возникнут эти соединения, и мы не должны делать никаких предположений, поэтому я пришел к выводу, что наш сервер лучше должен поддерживать 2500 соединений в определенный момент времени.
Я играл с тестом apache, отправляя 2500 одновременных подключений при подключении / отключении кэша памяти или некоторых настроек nginx, просто чтобы увидеть изменения производительности.
Лучшее, что у меня было, было около 100 запросов в секунду, но самые длинные запросы занимают более 20 секунд (для 2500 одновременных подключений, только 100 запросов занимают максимум 1 с). С точки зрения пользователя, я бы не хотел ждать больше 1-2 секунд, чтобы получить результат ...
Я хотел бы больше поиграть со всеми настройками, которые я могу настроить на nginx, django, mysql или memcache, но на данный момент я думаю, что мне нужна методология и больше, чем методология, мне нужна цель, которую нужно достичь.
Выполняя поиск в Интернете, я вижу сообщения в блогах, в которых говорится об услугах, которые обрабатывают несколько сотен запросов в секунду. Я далек от этого.
Наблюдая за всеми этими цифрами, полученными из apachebench, у меня создается впечатление, что я запускаю тесты, вижу результаты, но я не совсем понимаю их и не знаю, что с ними делать, чтобы улучшить наш API.
Итак, что было бы хорошей методологией, хорошим подходом к достижению цели - иметь веб-API, способный как можно быстрее справляться с таким количеством подключений?
Если вам нужна дополнительная информация, просто спросите!
Я никогда не работал с установкой Django, поэтому, возможно, не смогу вникнуть в особенности Django. Было бы здорово, если бы вы могли предоставить подробную информацию о статистике ЦП, ввода-вывода, памяти при выполнении 100 запросов в секунду. Вы можете получить эти 20-секундные задержки по разным причинам, в зависимости от характера вашего дефицита ресурсов. Возможно, вы не сможете понять статистику производительности, не зная о состоянии вашей системы в условиях стресса. Хорошим местом для начала могут быть показатели Amazon CloudWatch и / или включение мониторинга с помощью Munin, Nagios или аналогичных инструментов с помощью соответствующего графического инструмента, такого как Graphite или Ganglia. Даже отслеживание vmstat вывод может многое раскрыть.
Ключ к выявлению проблемы - собрать достаточно данных о состоянии вашей системы и следить за ними. Вы можете просто отобразить тенденцию трафика на Graphite вместе с другой статистикой, такой как использование ЦП, ожидания ввода-вывода, переключение контекста, количество прерываний, доступная память и попытаться связать эти данные. Вы даже можете разделить цикл запросов на фазы базы данных, промежуточного программного обеспечения и рендеринга и отслеживать время, затраченное на каждую фазу.
vmstat. Это может произойти, если вы решите запустить большее количество рабочих процессов, чем количество доступных ядер. Сервер также может ожидать блока ввода-вывода. Некоторые испытывали задержку блока ввода-вывода при использовании EBS, хотя меня это устраивает.Надеюсь это поможет.
Сначала вам нужно установить, что является узким местом для этой веб-службы. Вероятно, это медленные запросы к БД и / или низкая производительность django. Обратите внимание, что большинство фреймворков для быстрой разработки веб-приложений (Производительность Django) на самом деле не оптимизированы по скорости. Если вы не можете позволить себе использование большого количества серверов и балансировку нагрузки, вы не можете рассчитывать на высокую производительность.
В любом случае ... для начала я бы попробовал: