Тестирование использования памяти фреймворками Python в Virtualenv

Это зависит от того, как вы собираетесь запускать приложение в своей среде. Существует множество различных способов запуска веб-приложений Python. В последнее время популярны методы Gunicorn и uWSGI. Таким образом, вам лучше запустить приложение, как в вашей среде, и вы можете просто использовать монитор процесса, чтобы увидеть, сколько памяти и ЦП используется процессом, выполняющим ваше приложение.

Я присоединюсь к замечанию Мэтта В. о том, что среда приложения является основным фактором (Gunicorn, uWSGI, nginx->paster/pserve, eventlet, apache+mod_wsgi и т. д. и т. д. и т. д.)

Я также добавлю, что это 2012 год. В 1999 году память и ЦП для таких вещей были огромной проблемой. Но на дворе 2012 год. Компьютеры значительно мощнее, расширять их гораздо проще и дешевле, а фреймворки кодируются лучше.

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

Узкими местами производительности веб-приложений Python обычно являются:

• узкое место связи с базой данных
• схема базы данных
• одновременных подключений/запросов в секунду

С точки зрения узкого места связи с базой данных, общие подходы к его решению следующие:

• общаться меньше
• • aggressive caching
• • optimize your sql queries and result sets , so there's less data
• обновить инфраструктуру БД
• • dedicated machine(s)
• • cluster master/slave or shard

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

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

вот ссылка на хороший, но старый тест — http://nichol.as/benchmark-of-python-web-servers

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

вы могли бы интерпретировать gevent как потрясающий из-за того, что у него 3 МБ по сравнению с 15 у uwsgi или 122 у cogen ... но все это небольшая часть памяти современной системы.

фреймворки имеют такие небольшие накладные расходы и вряд ли будут влиять на операционную производительность. даже части базы данных ничто. сошлитесь на это сообщение о SqlAlchemy ( Почему вставка SQLAlchemy с помощью sqlite в 25 раз медленнее, чем при непосредственном использовании sqlite3? ), где сопровождающий отмечает некоторые впечатляющие примечания по производительности: прямая генерация sql составляла ~ 0,5 с для 100 000 строк. когда задействован полный ORM с проверками целостности и т. Д., Он становится 16 с для того же количества строк. это ничего.

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

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

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

Выбор механизма хостинга не является причиной использования памяти, это то, как вы их настраиваете, а также какое толстое веб-приложение Python вы решите запустить.

Цитируется эталон:

http://nichol.as/benchmark-of-python-web-servers

является хорошим примером того, как тесты могут ошибаться.

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

Не обращая внимания на память, некоторые другие комментарии о том, где будут находиться настоящие узкие места, справедливы. Более подробно обо всем этом вопросе см. в моем выступлении на PyCon.

http://lanyrd.com/2012/pycon/spcdg/