Назад | Перейти на главную страницу

Минимизация времени отклика, максимальное количество запросов в секунду

Я тестирую различные хостинговые решения Ruby on Rails, включая nginx, apache, несколько различных интернет-провайдеров и системы облачных вычислений и т. Д.

Я замечаю, что когда обрабатывается только один или два одновременных запроса, среднее время ответа на эти запросы часто невелико (<10 мс). Однако я могу справиться с таким большим объемом трафика. Но если я пытаюсь максимизировать количество запросов в секунду, среднее время ответа растет довольно быстро. Например, для одного сервера я обнаружил, что наибольшее количество запросов в секунду было достигнуто примерно при 16 одновременных запросах, выполняемых в любой момент. Однако на тот момент среднее время ответа превышало 200 мс.

Интересно, какие уловки и советы у вас, гуру веб-серверов, есть, чтобы сбалансировать время отклика и количество запросов в секунду?

Первое, что нужно определить, ваше приложение или сервер?

Какова производительность статических файлов для каждого решения? Можете ли вы получить изображение размером 50 КБ с приемлемыми результатами? Вы уверены, что проблемы возникают из-за рубинового стека?

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

вы должны прочитать о Проблема C10K. Обычно речь идет об архитектуре приложения, масштабируемости и способах достижения массового параллелизма. Мое дополнение к этому было бы следующим: начните с малого (иш), не переусердствуйте с предметом, большинству веб-сервисов сразу не понадобится такая масштабируемость. Попытка начать работу с поддержкой C10k может занять слишком много времени, чтобы добиться «правильного» решения, и вы никогда не должны пренебрегать основным содержанием вашей службы. наличие сайта с поддержкой C10k без контента означает мертвый сайт.