Appengine, снижение производительности с python27 - PullRequest
26 голосов
/ 01 декабря 2011

Я хотел протестировать python27 на appengine, поэтому я перенес свое приложение с python25.Производительность снижается более чем в 2 раза за каждый запрос!Затем я вернулся к python25 и производительность снова, как и прежде.Вот изображение:

enter image description here (миллисекунды / запрос) (обработчик cgi python 27, затем python25)

Мое приложение использует Werkzeug , Jinja2 , а memcache используется довольно много.Какие причины могут вызвать такое резкое снижение производительности?Или это только потому, что python2.7 на appengine все еще находится в бета-версии?

Некоторые подробности о приложении:

Это довольно простой интернет-магазин.Есть несколько отложенных задач с генерацией PDF, однако они не сильно влияют на общий график, потому что главная страница получает наибольшее количество просмотров.Почти все memcached.Загрузка страницы с Python 2.5 занимает до ~ 0,8 сек с пустым кешем.Некэшированные страницы загружаются долго, в основном из-за большого количества запросов в БД.Загрузка кэшированных страниц за 60 ~ 100 мс.Среднее время загрузки ~ 150 мс.С питоном 2.7 производительность ужасна.Некэшированные страницы загружаются за 2+ секунды.Кэшированные страницы загружаются за 200+ мс.

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

Мои числа для загрузки страницывремя, получаемое со страницы в реальном времени, которая обслуживает ~ 10 запросов / сек, и 1 резидентный экземпляр python25 легко справляется с этой нагрузкой.

Я также тестировал python 2.7 с wsgi и threadsafe:yes, но производительность немного улучшилась по сравнениюв Python 2.7 и CGI.

Ответы [ 6 ]

17 голосов
/ 06 декабря 2011

Где-то в Usenet Я прочитал подобное утверждение из Google: «Время выполнения Python 2.7 медленнее, чем время выполнения Python 2.5, в некоторых случаях и быстрее в других. Мы не публикуем причины, почему на этом точка. ". Похоже, никто еще не нашел сценарий, где 2.7 быстрее, чем 2.5, таким образом ...

Я прочитал в этом

  1. Google знает о проблеме с предварительной формой.
  2. Они не уверены, как с этим справиться.

Мое профилирование показывает, что многопоточные приложения Python 2.7 тратят ок. 35% их времени в {method 'acquire' of 'thread.lock' objects} - и, похоже, это происходит в коде RPC Google. Также есть признаки того, что импорт имеет серьезные проблемы с блокировкой.

По сути, вы ничего не можете с этим поделать, кроме как ждать, пока AppEngine исправит это. См. Также эту всеобъемлющую документацию о замедлении.

Факторы, которые почти наверняка не играют существенной роли в этом:

  • загрузка файлов pyc (инфраструктура GAE сделает это за вас)
  • подготовка сервера (GAE такой масштабный и даже в закрытой бета-версии 2.7. Был медленным)
  • WSGI против CGI (не объяснил бы такой огромный удар по производительности)

Ужасно то, что Google сделал огромный скачок цен в два шага, но сказал нам, что "используя многопоточный Python 2.7, вы можете работать намного эффективнее, чтобы новые цены не выглядели так плохо". К сожалению Python 2.7. среда выполнения по-прежнему помечена как «экспериментальная» и не обеспечивает качественную производительность.

5 голосов
/ 04 декабря 2011

Поддержка Python 2.7 все еще экспериментальная.Один из аспектов того, чтобы быть новым и экспериментальным, заключается в том, что у него не было такой производительности, как в Python 2.5.

3 голосов
/ 06 декабря 2011

Мигрировали ли вы свое приложение для использования WSGI вместо CGI при запуске на python 2.7?

Возможно, что интерфейс CGI - это просто оболочка для WSGI, которая теперь включена для 2.7.

1 голос
/ 30 декабря 2011

При переходе на python2.7 производительность моего приложения под нагрузкой в ​​3 раза хуже.

С 2,5:

Время соединения (мс) мин означает [+/- сд] медиана макс Connect: 36 48 15,4 41 109 Обработка: 685 3010 1893,3 2657 9255 Ожидание: 685 3009 1893,3 2656 9255 Итого: 725 3058 1900,5 2711 9333

Процент запросов, обработанных в течение определенного времени (мс) 50% 2711 66% 3287 75% 3896 80% 4521 90% 6146 95% 7078 98% 7934 99% 8413 100% 9333 (самый длинный запрос)

С 2,7:

Время соединения (мс) мин означает [+/- сд] медиана макс Connect: 35 46 11,4 41 96 Обработка: 1076 7614 4190,5 6711 32284 Ожидание: 1075 7614 4190,5 6711 32283 Итого: 1124 7660 4195,5 6764 32353

Процент запросов, обработанных в течение определенного времени (мс) 50% 6764 66% 7790 75% 8751 80% 9392 90% 10844 95% 13139 98% 25219 99% 27259 100% 32353 (самый длинный запрос)

0 голосов
/ 04 декабря 2011

Цитата из самого Google

Экспериментальная!

Python 2.7 - это экспериментальная, инновационная и быстро меняющаяся новая функция для App Engine.К сожалению, находясь на переднем крае, мы можем вносить несовместимые назад изменения.Мы сообщим сообществу, как только среда выполнения Python 2.7 перестанет быть экспериментальной.

Они еще не сделали это для промышленного использования, это похоже на бета-тестирование.применение в python2.7 до окончания экспериментального этапа.

Вы также можете попробовать загрузить только скомпилированные .pyc файлы, поскольку среда выполнения python27 поддерживает загрузку байт-кода

0 голосов
/ 04 декабря 2011

Насколько я знаю, Python 2.7 должен быть быстрее, чем 2.5.Однако есть несколько факторов, которые могут влиять на скорость:

  • Способ компиляции двоичного файла;
  • Скомпилированы ли ваши библиотеки (такие как Memcache) как C (++) илиPython.Модуль C ++, конечно, быстрее, чем эквивалент Python;
  • Сервер, на котором он находится - я никогда не использовал App Engine, но я бы предположил, что сервер работает только на Python 2.5 или Python 2.7,поскольку их смешивание было бы пустой тратой ресурсов.Если серверы 2.7 используются намного больше, чем серверы 2.5, и App Engine не компенсировал это, вы также заметите снижение производительности.

Это первые 3 вещи, которыеЯ придумал, но есть много факторов.Даже погода может в теории повлиять на производительность.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...