[Django] Скорость работы

http://www.nestor.minsk.by/sr/2007/02/sr70214.html

Вот какая-то статья есть. Но она:
1) Размещена на невнятном ресурсе
2) Довольно старая
3) Я не настолько силен, чтоб судить, насколько она адекватна

на статью 2007 года лучше не смотреть вовсе

Сравнивать сайты на разных хостингах при разных нагрузках - это нечестно.

вот нагуглил статью годичной давности - http://blog.curiasolutions.com/2010/11/the-great-web-technology-shootout-–-ro...

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

Ничего не думаю. Используй RoR, если нравится.

> Интересует скорость работы сайтов на Django

В основном упирается в скорость работы memcached ;)

«все решают мозги программиста, который разрабатывает архитектуру приложения» Я приводил в пример сайты на Django, там думаю архитектура самая правильная. Если Django и делался для этих сайтов... Но скорость...

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

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

И да, откуда выводы о скорости работы вышеуказанных сайтов? На глаз?

Купи кластир, забабахай на нем облако с 10 ПТ памяти и 100500 процессорами и PCI-E SSD и будет у тебя Django летать ;) Масштабирование бывает разное, хотя не мне рассказывать про масштабирование ;)

правильный кэш убирает ботлнек в виде запросов к БД, а не кэширует весь контент.

Оно всю по определению очень тормозное. Ориентируйся на 10 запросов в секунду на ядро проца. Кэшами итп можно вытянуть в несколько раз больше.

10 сферических запросов в вакууме

Это примерно то на что можно расчитывать на сайте средней сложности. Конечно реальная скорость может отличаться на порядок в обе стороны.

У Django есть одно слабое место. После каждого ответа происходит отсоединение от базы данных. Если не делать disconnect, то скорость увеличивается буквально в разы.

> правильный кэш убирает ботлнек в виде запросов к БД, а не кэширует весь контент

4.2

>У Django есть одно слабое место. После каждого ответа происходит отсоединение от базы данных. Если не делать disconnect, то скорость увеличивается буквально в разы.

а это просто 4.2 в квадрате

извини, гуру высоконагруженных проектов, но ты не мог бы объяснить зачем кэшировать всю страницу? Или это тебя беспокоят последствия использования PHP?

django 1.3.0, db/__init__.py, строка 35:

signals.request_finished.connect(close_connection)

> приводил в пример сайты на Django, там думаю архитектура самая правильная

мы не знаем какая там нагрузка, каналы, вычислительные мощности. Так что, это все гадание на кофейной гуще.

Может затем, что на рендеринг темплейтов тоже тратится время?

Может затем, что на рендеринг темплейтов тоже тратится время?

34.634 msec да, это действительно гигантские цифры.

> 34.634 msec да, это действительно гигантские цифры.

А если запросов тыща в секунду? А если 10 тысяч? А если ддос?

А если запросов тыща в секунду?

а питцот тыщ? а мильон? Купи уж нормальную железку. Для ддоса есть сетевое оборудование.

> Купи уж нормальную железку.

Поверь, мой юный друг, если приложение криво написано, то никакая железка его не спасет.

Поверь, мой юный друг, если приложение криво написано, то никакая железка его не спасет.

не, не поверю. Спасает, да еще как.

> не, не поверю

На 100500 процессоров вычисления надо еще распараллелить. А это не всегда делается мановением волшебной палочки. Разработчики всего мира ломают головы над созданием масштабируемого софта, столько новых технологий появляется. Жаль они не знают икс-пахоса с ЛОРа, он ведь один понимает что все просто - лишь докупить новых железок.

На 100500 процессоров вычисления надо еще распараллелить. А это не всегда делается мановением волшебной палочки. Разработчики всего мира ломают головы над созданием масштабируемого софта, столько новых технологий появляется. Жаль они не знают икс-пахоса с ЛОРа, он ведь один понимает что все просто - лишь докупить новых железок.

Веб это другое. Здесь не обязательно выполнять параллельно вычисления, можно все поделить на ноды и уже с них брать отрендеренные страницы. Что-нибудь еще можешь сказать, разработчик hiload проектов? :)

> Веб это другое. можно все поделить на ноды и уже с них брать отрендеренные страницы.

Ты что-то в середине 90-х завис. Веб - это уже давно не набор отрендеренных страниц.

Ты что-то в середине 90-х завис. Веб - это уже давно не набор отрендеренных страниц.

ну расскажи мне тогда, что веб сейчас.

> 34.634 msec да, это действительно гигантские цифры.

это просто невероятно огромные цифры.

вон как выяснилось джанга таки закрывает соединение с БД, и на новый конект тратит 5мс. многие просто запрещают джанге закрывать соединение чтобы поднять производительность

34мс... да это целая вечность.

И да, у джанги слабое место это шаблонизатор. Он самый медленный из популярных шаблонизаторов.

jinja2 с джангой живет отлично.

И да, у джанги слабое место это шаблонизатор. Он самый медленный из популярных шаблонизаторов.

возьми mako.

«И да, у джанги слабое место это шаблонизатор. Он самый медленный из популярных шаблонизаторов.»

Проводились тесты?


«jinja2 с джангой живет отлично.»
«возьми mako.»

Значительно ли они быстрее встроенного в Django шаблонизатора? Может тоже есть какие-нибудь сранительные тесты?