Какая веб-платформа требует наименьших затрат? - PullRequest
0 голосов
/ 04 марта 2009

Я играю с Джанго на хостинге моего сайта.

Я обнаружил, что простая страница Django, которая имеет только некоторый статический текст и визуализируется из очень простого шаблона, который я создал, требует значительного времени для рендеринга. По сравнению со статической HTML-страницей, я получаю разницу в ~ 2 секунды во время загрузки. Имейте в виду, что это мой простой тест, в котором нет ничего сложного. Также обратите внимание, что мой веб-хостинг находится на общем сервере (не выделенном), поэтому я могу столкнуться с некоторыми ограничениями процессора.

Мне кажется, что либо:

  1. У меня неправильная базовая конфигурация CGI / Apache / Django
  2. Джанго требует значительных накладных расходов, по крайней мере, в этом конкретном сценарии.

Я считаю, что № 1 маловероятен, так как я следил за моей вики-страницей о том, как настроить Django Итак, у нас осталась проблема с накладными расходами.

Мой вопрос: какой веб-фреймворк вы считаете лучшим для использования в сценариях, когда веб-сайт размещен на общем сервере, а нагрузка на ЦП / память должна быть минимальной?


Редактировать: кажется, что моя конфигурация - это то, на что я, возможно, захочу взглянуть, и, возможно, позже я открою вопрос о том, как лучше всего настроить Django.

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

Ответы [ 6 ]

4 голосов
/ 04 марта 2009

«У меня неправильная базовая конфигурация CGI / Apache / Django»

Правильно.

Во-первых. Самый первый раз, когда Django возвращает страницу, это занимает вечность. Большая инициализация происходит для первого запроса.

Во-вторых. Какую конкретную конфигурацию вы используете . Мы только что перешли с mod_python на mod_wsgi в режиме демона и очень довольны изменениями производительности.

В-третьих. Какую базу данных вы используете?

В-четвертых. Какую тестовую конфигурацию вы используете?

Пятый. Какие параметры кэширования и обратный прокси вы используете?

Скорее всего, у вас много степеней свободы в вашей конфигурации.


Редактировать

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

См. http://wiki.python.org/moin/WebFrameworks

Есть десятки фреймворков. Мало кто может осмотреть больше, чем немногие, чтобы сравнить друг с другом.

Наилучшая возможная производительность достигается за счет статического контента. Приложение Python, создающее статические страницы (например, набор шаблонов Jinja), работает быстрее всего.

После этого почти невозможно сказать. Даже http://werkzeug.pocoo.org/ включает некоторые накладные расходы на обработку, которые могут быть неприемлемыми в приведенном выше сценарии. Python может быть медленным.

Джанго, с небольшим усилием, часто достаточно быстр. Например, обслуживание статического контента отдельно от динамического контента может значительно ускорить работу.

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

1 голос
/ 06 марта 2009

Я думаю, что хост может быть проблемой. Я занимаюсь разработкой Django на своем локальном компьютере (Mac), и это намного лучше. Мне нравится WebFaction для дешевого хостинга и Amazon ec2 для премиум-хостинга.

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

Кроме того, следите за вашими изменениями - лично я не думаю, что производительность является серьезной проблемой в программировании. Вот вопросы с точки зрения озабоченности:

  1. UI / UX эффективность
  2. Скорость интерфейса / UX (кеширование приложения)
  3. Хорошо спроектированные модели / виды
  4. Оптимизация системы (n-уровневая архитектура и т. Д.)
  5. Оптимизация процесса (хороший контроль качества для уменьшения сбоев / узких мест при развертывании)
  6. Оптимизация подсистем (базы данных и т.д ...)
  7. Оборудование
  8. Каркас внутренней оптимизации

Не тратьте время на сравнение скоростей фреймворка. Их преимущество заключается в расширяемом коде, умных архитектурах и т. Д ...

На заметке не используйте рамку для нового веб-приложения. Извините, я не могу сказать это достаточно громко, но сейчас это абсолютное требование. Это даже не спор о неиспользовании, а о том, какой именно использовать.

Я лично выбрал Джанго, и это здорово. Но я не могу окончательно выбить других там.

1 голос
/ 05 марта 2009

Фреймворки, такие как Django или Ruby on Rails, выросли из потребностей реального мира. Как бы ни отличались эти потребности, какими бы разными они ни были.

Вот мой Опыт : Как бывший программист PHP, я предпочел CakePHP для простых вещей и Symfony для более сложных приложений. Я заглянул в Ruby, но документация была отстойной. Сейчас я использую Django. Джанго работает очень хорошо для меня. В отличие от Symfony, я чувствую, что Django приносит меньше гибкости из коробки, но его легче расширять.

Другой подход заключается в использовании «без фреймворка» CherryPy

1 голос
/ 04 марта 2009

Я бы сказал, что с вашей настройкой должно быть что-то необычное, чтобы получить такую ​​большую разницу в производительности. Попробуйте mod_wsgi (если вы этого еще не сделали) и следуйте отличным советам, представленным выше. Если бы Django действительно был таким медленным во всех случаях, у компаний просто не было бы возможности использовать его для производственных приложений. Скорее всего, не будет Django, который удерживает запрос. После того, как все файлы .pyc отсортированы (автоматически генерируется байт-код), выполнение должно быть быстрым.

Однако, если вам на самом деле не нужно все, что может предложить Django, тогда зачем его использовать? Я использую его в довольно большом производственном приложении, и мы не используем все его функции ... если вы делаете что-то довольно простое, вы можете рассмотреть возможность использования чего-то вроде web.py Werkzeug (или что-то не основанное на Python, если хотите).

0 голосов
/ 05 марта 2009

Определенно совместно используемый хостинг - не лучший выбор для запуска таких мощных сред, как Django или CakePHP. Если вы можете себе это позволить, купите VPS.

Что касается производительности, возможно, ваш хост использует Python с mod-python, что сейчас не рекомендуется. WSGI является предпочтительным стандартом для веб-приложений на платформе Python.

0 голосов
/ 04 марта 2009

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

...