Проблема масштабируемости (Торнадо). Не могу понять, задерживая запуск

Спасибо, ребята, любые идеи / понимание приветствуются, потому что это сводит меня с ума.

Проблема: только около 3 или 4 пользователей могут использовать сервер одновременно, пока приложение не остановится.

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

Наша архитектура выглядит следующим образом:

• Сервер приложений (Tornado) - однопоточный, с асинхронным циклом ввода-вывода. Мы используем Tornado для обработки постоянных соединений, связанных с длительным опросом, и отправляем все основные веб-запросы в Django через WSGI.
• Django ORM используется для взаимодействия с базой данных, хотя большинство SQL написано вручную
• База данных MySQL
• Nginx обслуживает статические носители и передает другие запросы Tornado
• В настоящее время все настроено для запуска на одном "малом" экземпляре EC2. Разделение серверов между машинами не оказывает заметного влияния на производительность

См. Спецификацию сервера EC2: http://aws.amazon.com/ec2/instance-types/ для получения дополнительной информации о конфигурации сервера. Примечание. В целом, это не идеальная и наиболее масштабируемая установка, но она должна быть в состоянии обрабатывать более 3 пользователей!

Запуск топ и просмотр журналов показывает следующее:

• Пики ЦП в основном связаны с Tornado, около 25% дополнительного использования ЦП на активного пользователя
• Низкое "время кражи", поэтому EC2 больше не ограничивает мощность нашего процессора (больше)
• Все запросы к БД находятся в диапазоне 0-200 мс, когда процессор не пикирует, но часто 3 или более секунд во время пиков
• Использование памяти низкое и никогда не всплески

Некоторые вещи, которые были опробованы безрезультатно:

• Настройка размеров буфера MySQL, индексов и т. Д. Я на 99% уверен, что это не проблема оптимизации SQL/DB для сада
• Улучшение времени запросов и уменьшение количества запросов всеми видами способов.
• Поместите серверы в отдельные экземпляры ec2
• Прокси между несколькими серверами приложений (это, очевидно, будет гораздо более масштабируемым, но это не решает проблему 3 пользователей на экземпляр)
• Обновите экземпляр EC2. Обновление с "Micro" помогло (из-за проблем с процессором), но только немного увеличило нашу емкость
• Развертывание на сервере не-EC2 (Slicehost) - те же проблемы
• Все серверы прошли индивидуальную нагрузочную проверку с помощью простых тестовых случаев, и все они могут обрабатывать тысячи одновременных подключений.