Python-сообщество

Daevaorn
Я уверен, что апач вполне себе легко раздает статику в нужных для ТС количествах.

Хорошо, уточню.
Когда апачу приходит запрос он делает форк. Сам форк – операция сравнительно затратная. Я помню про pre-fork, но оно не сильно решает проблему отжирания кучи памяти для каждого процесса.
Nginx. Есть мастер-процесс и несколько вокеров. Всё это фактически event-based система.

Из практики. Я сейчас поддерживаю старый проект. Он ещё на CGI. И там ооочень много статики (своя карта Москвы, например – почти пол миллиона файлов, которые просто так не закешируешь). Работает это так…
Есть nginx, который принимает все запросы. Запросы к страничкам он пердаёт апачу, а статику отдаёт сам. В общем-то всё работает удовлетворительно. Так, ради интереса, я пускал всё через апач: средняя нагрузка процессора с десяти процентов поднялась до пятидесяти, а память… цифр не дам, но где-то на порядок.

P.S. Я могу делать такие эксперименты, так как оно работает на виртуальной машине – все запросы идут через nginx гипервизора и достаточно только перенаправить порт вывода, т.е. сравнительно безопасно в плане падений. Если есть желание, предложите методику и я потестирую ещё, но для меня лично вопрос об апаче решён – апач, это штурмовой вертолёт, а не web-сервер.

ZZZ
Когда апачу приходит запрос он делает форк. Сам форк – операция сравнительно затратная. Я помню про pre-fork, но оно не сильно решает проблему отжирания кучи памяти для каждого процесса.

А если треды? Надо уметь готовить апач.

В общем суть в том, что не надо всем рекомендовать nginx и подобные ему решения. Тем более когда очевидно, что ТС не сталкивается с подобными задачами и имеет совсем другие проблемы на данном этапе.

Daevaorn
А если треды? Надо уметь готовить апач.

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

Daevaorn
В общем суть в том, что не надо всем рекомендовать nginx и подобные ему решения.

ИМХО, пусть сразу делают нормально. А то, блин, потом разводится толпа апачеров, которые не умеют пользоваться больше ничем – а нам, админам, потом поддерживать это! Так что когда я слышу “апач”, у меня автоматически формируется соответствующий ответ.
Нефиг, блин.

Daevaorn
Я уверен, что апач вполне себе легко раздает статику в нужных для ТС количествах.

Я думаю, что в данном случае и django.views.static.serve справится. :-)

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

Опять-таки мы говорили не об этом.

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

PS: Компьютеры сделаны для того чтобы считать. Это их работа. Поэтому экономия на тактах и переключениях контекста в большинстве случаев глупость и пустая трата времени. Тем более в случае ТС.

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

Daevaorn
Apache инструмент, который хорошо справляется со своими задачами. И достойно статику отдавать статику он тоже может.

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

Daevaorn
Поэтому экономия на тактах и переключениях контекста в большинстве случаев глупость и пустая трата времени.

Ох как ты ошибаешься… Вот у меня есть железо. Если бы я отдавал статику апачем, то пришлось бы покупать новый сервер. В данном случае, эта экономия выливается в реальную денежную экономию. Ныне процессорное время всё ещё дорого… А про память так вообще лучше не заикаться… Добавить к этому, что конфиг апача (как и sendmail) был придуман в подвалах СС, чтобы пытать бедных системщиков… Не, не стоит пользоваться такими вещами.

Касательно ТС, то я уже сказал, что не надо советовать апач, так как это старый тяжёлый и неповоротливый монстр изучать который нет смысла. Для чистой джанги апач вообще не нужен. Опять же, как я и говорил, fcgi+nginx – лучшее на сегодняшний день решение. ИМХО.

Ладно, давай не будем спорить, так как это превращается в холивар… А то я скажу, что CS – говно, а UT – рулез на веки веков аминь! Мать их всех!.. :-)

ZZZ
Ныне процессорное время всё ещё дорого… А про память так вообще лучше не заикаться…

Мы живем в разных вселенных. В моей – и то, и то дешево.

ZZZ
что не надо советовать апач, так как это старый тяжёлый и неповоротливый монстр изучать который нет смысла.

Это не правда. Это хороший инструмент для своих задач. Тем более для новичка.

ZZZ
Для чистой джанги апач вообще не нужен.

Это тоже не правда.

Apache очень хорошо подходит для многих django проектов. И не надо его демонизировать, а просто научиться его готовить и избавиться от религиозной ненависти.

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

Я не демонизирую его (это дебиан сам делает). А ненависть хоть и религиозная, но очень обоснованная опытом использования.
Что касается “научиться готовить”, то можно научиться из дерьма конфетку делать, только зачем? Она ведь от этого меньше дерьмом не станет.
Про новичков… Блин, nginx проще в освоении. Единственная проблема, с которой я столкнулся, это странный резолв имён, но если всё указывать явно и не надеятся, что он сам поймёт, что от него хотят, то никаких проблем не бывает.

Всё, больше не отвечу, так как никаких фактов мы друг другу не предоставляем, а только своё болото хвалим. :-)
Уж лучше за кружечкой хорошего стаута поспорить… Закусывая крылышками.

ZZZ
Уж лучше за кружечкой хорошего стаута поспорить… Закусывая крылышками.

Или за Бердычевским ;)