а апач тогда был везде. Да и щас, небось, это говно мамонта пол инета обслуживает.

А что вообще не так с апачем?

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

Неужели аллокатор из libc настолько умный

выложили исходники соляриса? давно. вот и стал умным.

А что вообще не так с апачем?

Он не нужен. Он монструозен, но большинство его функций давно неактуальны. Сейчас веб-приложения это именно приложения, а не набор разрозненных php-скриптов. Для бэкенда оно избыточно, для фронтенда nginx, имхо, гораздо лучше ((относительно) безопаснее, быстрее, больше нужных фич для фронтенда из коробки). Лично я использую nginx + fastcgi-приложения. С апачём ты вынужден свой код встраивать в вебсервер по средствам mod_php/mod_python/etc со всеми вытекающими проблемами которые ещё и зависят от того какая модель соединий используется (prefork, worker, ...). Но зачем так страдать?

Это был вопрос с подковыркой. Никакой алгоритм не может смотреть в будущее.

Это был вопрос с подковыркой

Я не уверен :). Достаточно посмотреть бенчмарки и решить для себя на сколько у lighttpd большие проблемы с производительностью.

насколько у lighttpd большие проблемы с производительностью

У меня только косвенные данные — lighttpd я запускал один раз, когда его instaweb от git'а попросил — так что не могу ничего утверждать. Зато я видел в интернете жалобы на якобы утечки памяти, которых формально нет, но они есть. И сильно удивился, не увидев в коде lighttpd какой-то особой работы с памятью, вроде пулов в nginx и apache.

Это был вопрос с подковыркой

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

это был вопрос с демонстрацией незнания того как устроены современные аллокаторы

Если этого знания хватает только на бравирование на форумах, то я без него как-нибудь обойдусь. Сходи лучше объясни страдающим от псевдо-утечек в lighttpd, что современным аллокаторам пофиг на фрагментацию, и что их проблемы не существует. Если они, конечно, ещё пользуются lighttpd.

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

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

которые могли бы открыть свой код чтобы в опенсорсе появились более прогрессивные аллокаторы

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

проблема существует. но заключается она в том,

что точно зная время жизни блока памяти, его аллокацию доверяют аллокатору из libc, который этого знания лишён. Я уже почти научился не изобретать велосипеды, когда они уже существуют. Но в случае веб-сервера от ещё одного слоя поверх библиотечного аллокатора больше пользы, чем вреда.

я с пеной у рта ринусь доказывать, какой опенсорс хороший

как хочешь. по этому вопросу я с тобой дискутировать не буду.

что точно зная время жизни блока памяти, его аллокацию доверяют аллокатору из libc

что за шизофазия? современные аллокаторы побороли фрагментацию за счёт того, что жрут память как не в себя; плюс арены для многопоточности.

в крестах этот вопрос решён уже давно и радикально. пишешь шаблон fixed-size-аллокатора и распределяешь память через него. дополнительно можно прикрутить заточенную под своё приложение политику выделения/освобождения страниц.

что за шизофазия?

В этой ветви обсуждаются lighttpd и nginx. Ты бы хоть в исходники того и другого глянул, что ли. А то вот так влезаешь в середину, ничего не понимаешь и начинаешь изрыгать потоки ярости.

я не изрыгаю, а констатирую факт: отквоченное является шизофазией.

В этой ветви обсуждаются lighttpd и nginx

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

а констатирую факт: отквоченное является шизофазией.

Пусть будет так, если тебе от этого легче. Ещё раз предлагаю ознакомиться с кодом lighttpd и nginx. После этого текст станет понятнее.

во-первых, только nginx; первое как бы оффтопик

Это в теме — nginx. А в той ветке обсуждения, в которую ты ответил, речь шла и про lighttpd. Или тебе надо объяснить, как lighttpd связан с аллокатором памяти?

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

А ты не путаешь «использовать» и «создавать»?

А ты не путаешь «использовать» и «создавать»?

нет, не путаю. нормальные аллокаторы имеют как профайлеры, так и возможности настройки пользователем

Если ты точно знаешь, что в часто вызываемой функции тебе понадобится временное место под 15 элементов известных размеров, сколько раз ты вызовешь «нормальный» аллокатор? 15 раз или один?

Пожалуйста, скажи, что 15.

Лично я использую nginx + fastcgi-приложения.

И на чём ты fastcgi-приложения делаешь? Если не секрет, конечно.

Я практически всё делаю на bottle.py . Но я не занимаюсь вебом профессионально.

С другой стороны, я таки делал один небольшой внутренний сайт по работе и там было решительно пофиг что на бэкенде потому что 2/3 сайта было на js + кое-что из базы тягалось. Т.е. всякие батарейки были не нужны, поэтому bottle.py встал как влитой. Но у него нет своих форм, ORM итп. Возможно, даже сессии в стороннем модуле. В остальном отличная штука :)

Ещё мне кажется что всё идёт к переносу логики с сервера на плечи клиента (в тот самый js). И это даже хорошо для меня, это позволяет делать серверную часть компактнее и быстрее.

Тогда надо будет nginx-фронтенд-балансировщик, и nginx с cgi вместо апача с cgi.

Можно вероятно обойтись и только nginx с cgi, если 1 хост справляется с нагрузкой.

от 0 до 15. вопрос в такой постановке не имеет смысла.

не имеет смысла

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

нужный ответ

это ненужный ответ

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

не может. их надо использовать там где они нужны, и не использовать где не нужны

их надо использовать там где они нужны, и не использовать где не нужны

Тебе всё ещё не понятно, о чём говорится в фразе «точно зная время жизни блока памяти, его аллокацию доверяют аллокатору из libc, который этого знания лишён»?

всё ещё нет.

для начала что-нибудь элементарное... есть функция foo() и дерево, которое нужно только ей и вызываемым функциям (т.е. время жизни — известнее некуда). построй его на стеке.

построй его на стеке

Выделяешь один большой кусок памяти, а потом из него нарезаешь кусочки нужного размера. Если большой кусок кончился, выделяешь ещё один. По окончании работы освобождаешь все большие куски. В Nginx и APR это называют memory pools.

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

ты не поверишь... те же самые memory pools (часто более продвинутые) сидят под капотом современных аллокаторов. если не выходит настроить (см мой комментарий за настройку), то можно навелосипедить тонко заточив под свою программу (см мой комментарий за кресты). это два.

стека 10мб на поток всего

Требование выделения на стеке придумал ты, я буду выделять в куче. За счёт того, что системному аллокатору не придётся возиться с множеством мелких блоков, даже first fit будет отлично работать.

куча == malloc. т.е. «нужный ответ 0» неверен.

системному аллокатору не придётся возиться с множеством мелких блоков

если твоей ос меньше 5-10 лет — ему это совсем несложно. и обогнать его «в лоб» (т.е. тот же first fit) у тебя врядли выйдет.

куча == malloc. т.е. «нужный ответ 0» неверен.

Нужный ответ был «от 0». Там главное — что не «ровно 15».

anonymous и i-rinat - спонсоры занимательного досуга уже третий день :)

А ведь и правда.