Django должен использоваться для больших, сложных сайтов?
Скалы Haml. Я не видел недавних показателей производительности, но это достаточно близко к erb в эти дни. Я думаю, что это могло бы быть быстрее, чем erb при включении ужасного режима (который предотвращает симпатичное добавление отступа), Мы делаем 2,8 миллиона просмотров страниц в день с Haml.
существует benchmarker, зарегистрировался в исходном дереве Haml: http://github.com/nex3/haml/tree/master/test
ноябрь 2009 Обновления
Nathan (основной разработчик Haml) опубликовал некоторые сравнительные тесты Haml 2.2 на его блоге. Вы видите точные числа там, но короче говоря:
- Нормальный (симпатичная печать) режим = в 2.8 раза медленнее, чем режим ERB
- Ugly (никакие симпатичные добавленные вкладки) = равняется ERB
, который можно включить ужасному режиму путем размещения Haml::Template::options[:ugly] = true в файле среды или инициализаторе. Обратите внимание, что ужасный режим не действительно настолько ужасен - получающийся HTML на самом деле намного более симпатичен, чем ERB - это просто не располагается с отступом приятно.
3 ответа
I found this quite interesting to read: http://softwaremaniacs.org/blog/2008/02/24/why-offline-crashed-en/
There are a lot of interesting articles in this blog, but, unfortunately, they're all in Russian.
Added: And since that post Ivan did write MySQL backend supporting master-slave replication: http://softwaremaniacs.org/soft/mysql_replicated/en/
Это будет во многом зависеть от того, что именно вы подразумеваете под "большими" и "сложными" ".
Что касается «сложного», взгляните на Pinax. Тонны функций созданы из простых приложений Django, соединенных вместе, и он по-прежнему считается фреймворком, который вы могли бы использовать в качестве начала для создания сайта социального программного обеспечения. Но я уверен, что вы все равно можете придумать какую-нибудь версию «комплекса», которая не будет хорошо вписываться в архитектуру Django.
Другое дело - обработка больших объемов трафика и больших наборов данных. В конце концов, если вы станете достаточно большим, Django не справится с этим. Но на самом деле, ни , ни фреймворк тоже не будет. Джейкоб-Каплан Мосс (один из разработчиков django) написал отличную статью , в которой излагается история веб-разработки, которая привела к тому, где находится Django. Он приводит довольно веские аргументы в пользу того, почему Django или любой другой фреймворк не может преуспеть как в быстрой разработке, так и в массовой масштабируемости, но почему? все же стоит начать с одного. По сути, нет двух сайтов с высоким трафиком, которые будут иметь одинаковые проблемы с масштабируемостью: всем им потребуется индивидуальный подход, специфичный для конкретного типа данных и трафика, с которыми им приходится иметь дело. Но поскольку трудно точно предсказать, где будут эти узкие места, рекомендуется начать с среды быстрой разработки и начать замену компонентов, когда возникнет необходимость.
Хорошая идея начать с среды быстрой разработки и начинать заменять компоненты, когда возникает необходимость. Хорошая идея начать с среды быстрой разработки и начинать заменять компоненты, когда возникает необходимость.Как уже упоминалось, это действительно зависит от того, что на самом деле означает «большой» и «сложный». Если вы планируете построить еще один eBay, ответ - «вероятно, нет».
Этот вопрос задают лот . Откровенно говоря, ответов предостаточно. Эта ветка довольно хороша. В этом году на DjangoCon была также очень популярна презентация Масштабирование Django . Вы должны спроектировать свой сайт так, чтобы он масштабировался, независимо от того, какую технологию вы используете.
Мой ответ был бы следующим: если ваш сайт собирается перерасти Django (или любую другую структуру, если на то пошло), это огромный успех, и у вас, вероятно, будет достаточно капитала, чтобы нанять гигантскую команду, чтобы полностью переписать все.