Скорость фреймворка

Меня периодически спрашивают, насколько быстр Django. Или как он быстр в сравнении с PHP, Java или Rails. И я не менее периодически затрудняюсь на такой вопрос сразу ответить.

Ответ прямо

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

Теоретически его скорость обусловлена, например, такими вещами:

• Работая под управлением mod_python или FastCGI, Django'вский код и код самого приложения находится в памяти в скомпилированном виде и готов к работе практически сразу. Насколько я знаю, тот же PHP без дополнительных кешей кода на каждом запросе парсит непосредственно исходный код.

• Django очень маленький. Одно время в рассылке пробегала очень впечатляющая ссылка со сравнением глубины стека вызовов в Django и Java (больше 100 (!) вызовов в Java против 19 у Django, из которых только 13 — собственно Django'вские).

• По сравнению с Ruby, у Питона более быстрый интерпретатор.

• Разработчики говорят, что Django изначально проектировался именно с учетом обеспечения хорошей производительности на каждом уровне.

Да и на практике, в общем-то, тоже все хорошо. Есть список маленьких и больших сайтов, которые счастливо работают на Django, а разработчики Django часто повторяют, что их сайты World Online легко переживали даже слэшдоттинг. Да и совместные синтетические тесты Django, RoR и Symphony тоже показывают такую картину.

Ответ по сути

Но все это интересно именно только с одной стороны. На самом деле, по тому, как задается этот самый вопрос — "быстрый ли Django" — часто видно, что человека интересует вопрос другой: "будет ли быстрым мой сайт на Django". А вот это уже — совершенно другое дело.

Я не беру во внимание то, что любое приложение можно просто написать плохо. Я говорю о том, что если вы делаете сайт, который не просто форум, просто wiki или просто блог, то есть не то, что уже было написано тысячей программистов по тысяче раз, то программирование внутри фреймворка рано или поздно заканчивается. Рано или поздно вы начинаете делать специфику приложения, для чего начинаете использовать собственные магические силы, а также призывать сторонние заклинания (библиотеки). И чем дальше, тем меньше в приложении фреймворка, и больше самого приложения. И тормозить оно будет по самым специфичным поводам, и фреймворк тут будет уже ни при чем.

В качестве примера у меня под рукой два моих последних больших проекта, которые делаются с использованием Django: Некий Музыкальный Сервис (про который я уже писал) и Некий Фото-Сайт (про который еще нет).

Пример 1

В музыкальном сервисе основная проблема с производительностью возникла не собственно с сайтом, а с процессом скачивания, который убивал сервер насмерть не потому, что Питон медленный или, там, базу данных я часто пинаю, а потому что каждый процесс скачивания занимал в памяти по 25 МБ неопределенно долгое время, и 4 пользователя с download-менеджерами легко съедали всю память.

Будет еще отдельная статья с подробностями и проблемы, и решения.

Пример 2

Проблема с фото-сайтом была еще экзотичней. Это система заказа печати фотографий, которая предполагается для работы не только в интернете, но и в виде отдельного киоска, в который пользователь загружает файлы не через <input type="file">, а со своей флэшки из цифровика. И в том и в другом случае, для того, чтобы показать человеку превьюшки его собственных фотографий, эти фотографии должны были попасть на сервер. И только когда люди стали приходить с реальными отснятыми сериями, оказалось, что от момента, когда человек воткнул флэшку в дисковод до момента, когда он может хотя бы начать выбирать, что ему напечатать, проходит минут эдак 10, пока все эти мегабайт 300-400 перельются на сервер и там обработаются. И ему трудно понять, почему его компьютер дома показывает все "сразу", а этот — так долго.

Оба эти примера показывают, насколько далеко реальные проблемы реального приложения могут стоять от тех задач, на которые расчитан любой веб-фреймворк: обслуживать короткие запросы на отображение данных из БД в виде HTML. Конечно хорошо, если он делает это быстро. Но это еще далеко не вся песня.