Кто менее требователен к памяти Django или Rails?

Question

[progenth]

Предположим 1 небольшой сайт со средней посещаемостью.

Выяснить на практике самому возможности нет.
Не холивара для.

Comments

[progenth]

В Rails как и в Django я новичок. Так уж сложилось, что знаком с обоими фреймворками. Недавно пробовал развернуть рельсовый проект на впс (256мб, vz) и возникло несколько ньюансов:
— попытка развернуться с apache и passsenger закончилась тем, что сначала passenger обвинил меня в жадности, а потом не собрался passenger-apashe2…
— nginx unicorn показали себя лучше, но на rake assets:precompile ruby'шные процессы съедали всю доступную память и не завершив начатое падали…

Проекты на Django разворачивать не приходилось, только писал.

Сразу появилась мысль — «Кто меньше ест?» и вот я здесь.

[progenth]

Ребят у кого есть опыт деплоя Django приложений на vps с памятью 256 и меньше — отпишитесь трудности возникали?

[kenny_opennix]

habrahabr.ru/post/142241/
Тут описали про оптимизацию.

Answer 1

[cthtuf]

у меня на VPS сейчас 8 django-проектов (самый крупный — treeio) и gitlab, который на rails. использование оперативки:
uwsgi — 81Mb
ruby1.9.1 — 264Mb

Comments

[sim3x]

хехе

Answer 2

[kenny_opennix]

Вопрос не конкретный. Допустим django с флет пейджами у меня живет на слабой впски. Тут подход к архитектуре сайта.
Фронт nginx, кеши, оптимизация ос. В принципе стандартный подход.
Оговорюсь сразу у меня сайт живет на sqlite. Вопрос не корректный, 1 небольшой сайт будет одинаков хорош и на Django и на рельсах и одинаково плох если будет криво написан.

Answer 3

[pman]

Дефолтное рельс-приложение с одной моделью, шаблонизатором haml и mysql базой данных созданное через генераторы проигрывает по ab дефолтному джанго приложению с одной моделью, стандартным шалонизатором на моём сервере, оба приложения запущены под unicorn и gunicorn соответсвенно, идут через nginx.
В чём причина? Вероятно, как было замечено выше, в кэшах, в оптимизации конкретного приложения.
Но, как показала практика, удобство разработки с привычным инструментом компенсирует начальную разницу в производительности — так как при должном знании можно заставить работать быстро любое приложение.

Comments

[vinograd19]

Покажите конфиг gunicorn, пожалуйста

[pman]

Настройки брал отсюда, у меня как раз один процессор на сервере

Answer 4

[jj_killer]

Зависит от многих факторов. Тот же Rails, смотря в каком окружении развернут, JRuby явно потребляет куда больше, чем MRI. Более того, на потребление влияет ряд очень неочевидных факторов, вроде используемого шаблонизатора, количества моделей, их атрибутов, валидаторов и т.д.

Экономия памяти не стоит того, чтоб пользоватся менее привычным и удобным инструментом.

Answer 5

[andyN]

Rails исторически намного более прожорлив т.к. подгружает кучу библиотек (хотя вроде как в последнее время ситуация постепенно меняется к лучшему). Django ест меньше.