Такие инструменты, как ab , обычно используются для проверки того, какую нагрузку вы можете получить от множества запросов одновременно, наряду с cacti / munin / инструментом мониторинга вашей системы или выбором, который вы можете генерировать данные о загрузке системы и запросов / сек. Проблема в том, что многие люди, проводящие сравнительный анализ, не понимают, что им нужно запрашивать много разных запросов, так как выполнение различных частей вашего кода займет разное количество времени. Профилирование и тестирование кода, а не запросов также важно, для чего многие люди уже сделали для django , benchrun также не плохой инструмент.
Другая проблема заключается в том, сколько HTTP-запросов занимает каждый просмотр страницы. Меньшее количество запросов и более быстрая их обработка являются ключом к созданию веб-сайтов, которые могут поддерживать большой объем трафика: чем быстрее вы сможете завершить и закрыть подключения, тем быстрее вы выделите ресурсы для новых.
С точки зрения общей скорости веб-серверов, само собой разумеется, что прокси-сервер (работающий в обратном направлении на вашем конце) всегда будет работать быстрее, чем веб-сервер со статическим контентом. Что касается Apache против nginx в отношении вашего приложения django, кажется, что mod_python действительно быстрее, чем nginx / lighty + FastCGI, но это не удивительно, потому что CGI, независимо от каких-либо ускорений, все еще медленен. Выполнение и кэширование кода на веб-сервере и предоставление ему возможности управлять им всегда быстрее (mod_perl против использования CGI, mod_php против CGI и т. Д.), Если вы все сделаете правильно.