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

Как дважды обрабатывать запросы в Apache

Чтобы выполнить реалистичные тесты для нового внутреннего сервера, я хотел бы дважды обработать все запросы Apache.

Поэтому просто обрабатывайте все живые запросы на старом сервере, как это делается сейчас, но затем также «дублируйте» запросы на другой виртуальный хост, где развернут новый бэкэнд, который будет обрабатывать запрос и регистрировать ответ.

Какой лучший / самый простой способ добиться этого в Apache? (бэкэнд - это процесс FastCGI)

Я не знаю, можно ли заставить Apache делать это «вживую» - в общем, все в Apache настроено на обработку любого заданного URL только один раз. Вы могли бы сделать что-то на уровне балансировщика нагрузки или сетевого устройства, если вы убедитесь, что ответ также не поступает на клиент ...

Другой способ сделать это - сохранить действительно полный журнал Apache, а затем воспроизвести его на своем тестовом сервере с помощью JMeter (http://jakarta.apache.org/jmeter/usermanual/component_reference.html#Access_Log_Sampler) Я не думаю, что вы можете выполнять полезные нагрузки POST, но в остальном это достойный подход.

Единственный способ, который я могу придумать, чтобы сделать то, о чем вы просите, - это настроить прокси, чтобы обмануть запрос и отправить его на второй сервер (а затем зарегистрировать / выбросить второй ответ сервера, поскольку я предполагаю, что вы не хочу отправлять его конечным пользователям).

Это большая работа, если все, что вы делаете, это тест производительности, и предложение Эрнеста JMeter или что-то подобное (Apache ab утилита, LoadRunner($) или какой-нибудь простой сценарий Perl, вероятно, лучше: вас волнует, как он обрабатывает пиковую нагрузку и где находится этот пик (т.е. «быстрее / медленнее / одинаково по сравнению с текущей системой, и может ли она обрабатывать больше / меньше / такая же работа).

Если вы пытаетесь провести дымовое тестирование системы, чтобы выявить ошибки / проблемы, вы действительно хотите создать и использовать набор тестов, предназначенный для выявления проблем, а не полагаться на производственные данные для выявления всех угловых ситуаций.