Минимизация времени отклика, максимизация запросов / сек
Я тестирую различные решения для хостинга Ruby on Rails, в том числе nginx, apache, несколько различных провайдеров, системы облачных вычислений и т. Д.
Я заметил, что, когда обрабатывается только один или два одновременных запроса, среднее время ответа на эти запросы часто крошечно (<10 мс). Однако я могу справиться только с таким большим трафиком. Но если я пытаюсь максимизировать количество запросов в секунду, среднее время ответа растет довольно быстро. Например, на одном сервере я обнаружил, что наибольшее количество запросов в секунду было достигнуто при 16 одновременных запросах, выполняемых в любой момент. Однако в этот момент среднее время ответа составляло более 200 мс.
Интересно, какие уловки и советы у вас, гуру веб-сервера, нужно балансировать между временем ответа и запросами в секунду?
2 ответа
Вы должны прочитать о проблеме C10K. Обычно речь идет об архитектуре приложений, масштабируемости и способах достижения массового параллелизма. Моим дополнением к этому было бы: начните с малого (иш), не переоценивайте тему, большинству веб-сервисов эта масштабируемость не понадобится сразу. Попытка запустить C10k-совместимая может занять слишком много времени, чтобы стать "правильной", и вы никогда не должны пренебрегать основным содержанием вашего сервиса. наличие сайта с поддержкой C10k без содержимого равно мертвому сайту.
Первое, что нужно определить, это ваше приложение или сервер?
Как статическая производительность файлов из каждого решения? Вы в состоянии получить изображение с разрешением 50 тыс. С приемлемыми результатами? Вы уверены, что именно рубиновый стек вызывает проблемы?
Существует целый ряд компонентов, которые могут вызывать проблемы, включая приложение, базу данных бэкэнда, хранилище файлов и т. Д. В зависимости от вашего кода существует немало аспектов, которые могут вызвать проблемы с параллелизмом. Попробуйте написать очень простое тестовое приложение, чтобы увидеть, какие тесты вы можете получить, а затем добавьте по частям, чтобы увидеть, что вызывает проблему. Посмотрите на некоторые профилирующие жемчужины, чтобы увидеть, можете ли вы использовать их, чтобы определить, где ваше приложение тратит больше всего времени.