Используем память разумно, или mod_wsgi на 256 мегабайтах

[@ExxY]

>Если вы ещё используете django с mod_python — выкидывайте последний.
Вопрос:
Почему на оффсайте написано «Apache with mod_python currently is the preferred setup for using Django on a production server.»?
Без сарказма — интересны ваши мысли по этому поводу…

[@liq]

вот бородатый бенчмарк на эту тему. superjared.com/entry/quick-django-benching/

В общем они когда писали django ориентировались на mod_python

[@crash]

mod_wsgi еще не добрался до «стабильной» 1.0, думаю, когда зарелизится — джангодок порекомендует его :)

[@crash]

а, эт я напутал с версиями, все там стабильно уже

[@ExxY]

нет, на самом деле это просто гениально ставить в карму минус за такой коммент.

[@marazm]

Прежде всего это PEP, т.е. спешиал фо питон. Соответственно всё что будет нового — только во благо питонистам. Ну и производительность выше. Хотя не могу сказать что apache в этой связке идеальное звено, лучше использовать nginx, но заморачиваться со сборкой кастомного пакета в arch как-то не захотелось :)

[@mkevac]

На production серверах память не так важна — её много. А вот скорость критична.

[@crash]

>maximum-requests=200
а чего так мало?

[@crash]

Кстати попробовал на своем 256 слайсе, хотя проблем со свопом вроде нет, но запросы/сек упали с 915 до 412 на закешированном memcached проекте.

[@MazaFakagro]

Потихоньку да. Написал ниже но повторюсь. nginx+wsgi для VPS самое то. И память экономят и скорость в разы быстрее.

[@darkk]

А можете прокомментировать разницу между nginx+fastcgi и nginx+wsgi?

[@MazaFakagro]

wsgi как я понял(а я пака-что полный новичёк) создавался специально для python, а fastcgi уже для CGI, PHP и питона.

[@MazaFakagro]

Если не трудно разъясните пожалуйста. Сам в этом толком так и не смог разобраться.

[@MazaFakagro]

Спасибо, теперь всё понял.

[@mocksoul]

исходник mod_wsgi — 1 файл и примерно 8тыс строк. Не смертельно же? Такие вещи вообще полезно разглядывать — умнее станете уж точно ибо Грэхэм — очень достойный и умный мужик. Ну и плюс почитайте pep о wsgi.

www.ohloh.net/accounts/5497

[@marazm]

Вы видели ПЗУ быстрее чем ОЗУ? Или ПЗУ с безграничным ресурсом? Мне было бы интересно узнать :)

[@marazm]

Зачем вам цифры? Тем более что всё зависит от типа того и другого

[@marazm]

Может вы слишком умный? :)

[@marazm]

Ответ: менять каждый час (утрирую) HDD (вас этот термин устроит? мне «жёсткий диск» ухо режет) не самое удачное и выгодное занятие :)

[@marazm]

Vertu имеет пожизненную гарантию. Продолжим?

[@marazm]

Боюсь огорчить, но vertu даёт пожизненную гарантию в самом прямом смысле слова.

[@crash]

ассемблер забыли

[@daevaorn]

И таком же приложении?

Можете поподробней рассказать?

[@daevaorn]

Да. Спасибо.

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

И возможно именно специфика вашей задачи сыграла роль.

[@daevaorn]

Да, вы правы.

Но зачастую наличие готовой среды пусть и достаточно жесткой (хотя то что джанга монолитная — миф) предпочтительней чем набор компонентов и которых ещё надо эту среду построить и к ней адаптироваться. Но тут опять всё упирается в конкретные задачи и цели.

[@MazaFakagro]

Вах. Красиво и точно сказано.

[@marazm]

Ну лейку зря приплели, разный класс =)

[@mocksoul]

однажды я выкинул django templates в пользу jinja2. В другой раз получилось оторвать django.conf в пользу своего менеджера настроек. В другой раз получилось сделать многоуровневые приложения. И вот совсем недавно сделали возможносьт подключать приложения оп нескольку раз.

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

[@ingspree]

Поподробнее про свой менеджер настроек можно?

[@alekam]

Поддерживаю. Тоже интересно услышать про менеджер настроек.

[@z_z]

Ололо, джанга настолько слабо связанная насколько это можно. Потратьте неделю на исследование исходников и сможете сделать все что хотите :)

[@marazm]

То о чём статья, как раз и есть
> 'мне нужно сделать вэб-сайт'
+ стоимостью до 20 тыс. руб (вкл. дизайн). Так что…

[@troorl1985]

Расход памяти очень сильно зависит от того, каким боком использовался Django. Можно конечно наподключать кучу контрибов и удивляться большому расходу памяти. Но если не делать глупостей, то память расходуется вполне себе экономно и уж точно не в 6 раз больше, чем в любом другом фреймворке. Хотя, если у тебя есть какие-то конкретные данные, может из профайлера или ещё что-то, то я бы на это с интересом посмотрел, а то может действительно джанга начала толстеть в каком-то месте.

[@mocksoul]

true

джанго без контрибов = простейший маппинг re -> view.

я бы всем новым проектам советовал бы изначально отказываться от django templates в пользу jinja2/mako. На крупных приложениях с 3-уровневым наследованием темплейтов время их выполнения растёт экспотенциально =(.

[@egorinsk]

Apache не разрабатывался с прицлом на производительноть. а на соответствие стандартам, так что товарищ vpol прав.

[@mocksoul]

апач — комбайн. Но если из него вырезать все левое, статически собрать с worker_mpm — он будет в некоторых задачах быстрее lighttpd, в некоторых медленнее. Разница в обе стороны не превышает 1-2%.

У меня бинарник апача со статически собранными модулями внутри весит 1.6мб. В дефолтной поставке было 9мб.

Внутри же — apache — пожалуй я не знаю ни одного opensource приложения с более логичной внутренней структурой. Lighttpd же зашёл в тупик.

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

[@egorinsk]

Фраза, если что, была прочитана где-то в документации Апача) НО согласен, вручную настроенный апач явно будет быстрее.

[@l2k]

Замените слово ПЗУ на НЖМД или HDD, пожалуйста. Слух очень сильно режет, если честно.
Это тоже самое, что Метро называть Электричкой.

[@ingspree]

Да ну? Какие новости, однако.

[@ingspree]

Классная наука, информатика. Это Вас в школе такому учили?

В Википедии, конечно, написано то же самое, но писали статью, видимо, стандартные российсковикипедные авторы.

Есть ОЗУ — оперативное ЗУ. Есть ПЗУ — постоянное ЗУ. Их два вида, ничего посредине нет. Отличаются тем, что ОЗУ при отключении энергии теряет всю информацию, а ПЗУ — нет.

[@ingspree]

Чем это противоречит?

[@l2k]

это показывает отсутствие вашего образования :)

[@l2k]

Вы абсолютно правы.

Как ROM переводится? Read Only Memory!

А автор пишет об Жеских дисках…

[@ingspree]

Учу читать, 50$ в час.

P.S. Hint: в статье нет слова ROM. И не было.

[@l2k]

Статья была исправленна. Как видишь «HDD» даже выделенно — потому что именно оно и исправлялось.
Вы не правы.

[@ingspree]

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

А HDD — это именно ПЗУ. Или Вы хотите сказать, что это ОЗУ?

[@l2k]

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

На пальцах:
Постоянно запоминающие устройства (ПЗУ, ROM по английски) — называются постоянными потому, что когда отключаешь электроэнергию, память остаётся.
Правильно, на HDD тоже остаётся память, но ты будешь сильно удивлён — она там останется на несколько лет, после чего начнёт размагничиваться. (пока снова не подать питание)
ПЗУ обычно называют микросхемы, которые прошили один раз и забыли о них. Техника на месте не стоит, и уже давно используются микросхемы, которые можно много раз перезаписывать (например, микросхема BIOS).
CD-ROM — это тоже относится к ПЗУ (пробил в нужных местах дырки лазером на CD-диске и используй его, пока читается).
Перфокарты — это тоже ПЗУ.
Даже Flash Memory можно назвать ПЗУ, потому что она делается какраз на микросхемах EEPROM. (заметь, слово оканчивается на ROM не случайно)

Но винчестер (HDD) — это уже не ПЗУ.

Кстати, в en.wikipedia.org/wiki/Read-only_memory есть ссылка на русский… Посмотри — оно тебя перенесет именно на ПЗУ.

[@l2k]

Добавлю лишь, что Flash Memory — это не просто ПЗУ, а Электрически Стираемое Перепрограммируемое ПЗУ (ЭСППЗУ или EPPROM, как уже говорил)

[@marazm]

Сами бы определились :)

[@ingspree]

ПЗУ — это не ROM.

[@ingspree]

proof-link?

[@MazaFakagro]

ну тогда уж лучше заодно и nginx+wsgi(fapws3)

william-os4y.livejournal.com/

[@evilkost]

в продакшен сырую ~бету?

[@MazaFakagro]

Про бету это вы где прочитали? А так если нет доверия то есть и другие WSGI www.wsgi.org/wsgi/Servers

Тут важнее заменить апач!

[@mocksoul]

fapws внутри просто ЧУДОВИЩЕН. Человек который его пишет лишь экспериментирует с асинхронным прграммированием на си, без должного опыта.

а вот apache… давайте поспорим на пиво что я смогу сделать сборку апача которая будет быстрее nginx, lighttpd и fapws при выплевывании традтиционного hello world посредством питона?

apache очень большой внутри, но и исключительно логичен. Одна только apr чего стоит.

[@daevaorn]

Кстати, да, fapws3 нестабилен, Причем даже более чем тот же flup.

И вообще недавняя некая истерия прокатившаяся по сообществу питонистов/джангистов по поводу асинхронных WSGI серверов явно связана с тотальным непониманием их принципов, недостатков и достоинств.

[@MazaFakagro]

Мдя, прошу прощения. Эти Истерия отразилась и на мне как новичке особенно :-(

[@Xobb]

Интересно было почитать. У самого на слайсхосте VPS с 512 ОЗУ на ubuntu8.04. Там довольно большой магазин на мадженто, так памяти обычно 300 метров занято, остальное добавилось когда там поднял еще несколько проэктов и svn. Да, поддержую, слайсхост достоин рекомендации.

[@alex_blank]

>> Это помогает при наличии утечек памяти: при перезагрузке память процесса приходит в изначальное состояние.

крутой GC, что сказать

[@daevaorn]

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

[@odessky]

У Вашего VPS неудачная система виртуализации, которая не умеет лимитировать дисковую нагрузку
В OVZ например можно выставить медленный IO, и никаких проблем с свопом небудет.

Хотя 256Mb не много, комфорт идет от 380.

[@marazm]

Это значит искуственно затормозить сервер. Всёже БД хранится на HDD.

[@mocksoul]

Дабы не запутывать народ в размышлениях между mod_python и mod_wsgi достаточно напомнить что они созданы одним человеком и после полного прекращения работы наd mod_python он занялся mod_wsgi.

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

gentoo + mod_wsgi + python + custom kernel + apache-static = у меня вертится mocksoul.ru на ноуте с 64мб памяти. А так как там лежит музыка — эта связка делает почти 1тб трафика в месяц на 40мбитах и без ощутимых тормозов.

на freebsd можно и в 32мб уложится. Есетственно при этом речь не идёт о сколько бы то ни было мощных приложениях.

[@mocksoul]

очень показательно посмотреть на историю коммитов в mod_python и mod_wsgi от Грэхэма)) www.ohloh.net/accounts/5497

[@ingspree]

Эта фамилия читается как Грэм. :-)

[@rukeba]

использую сам и советую всем: django + nginx. очень экономно к ресурсам.

[@wiz]

А между ними что? вот этот "+", можно про него поподробнее?

[@rukeba]

fastcgi

[@ingspree]

flup?

[@kpblca]

а что регулирует опция WSGIPythonOptimize?