LINUX.ORG.RU

Проект nginx открыл исходные коды для балансировщика нагрузки

 


1

1

Стал доступен выпуск веб-сервера NGINX Plus R6, в котором кроме некоторого количества улучшений стали доступны исходные коды модуля для управления нагрузкой (load balancing). Всего в выпуске представлено следующее:

  • Балансировщик нагрузки
  • Новая панель управления для статистики
  • Поддержка ssl-аутентификации для email-трафика (IMAP, POP3, SMTP)

Более подробное описание улучшений и новых возможностей можно почитать здесь

>>> Подробности



Проверено: JB ()
Ответ на: комментарий от true_admin

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

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

hobbit ★★★★★ ()
Ответ на: комментарий от hobbit

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

dk- ()
Ответ на: комментарий от i-rinat

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

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

anonymous ()
Ответ на: комментарий от hobbit

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от i-rinat

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

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

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

anonymous ()
Ответ на: Это был вопрос с подковыркой от anonymous

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

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

i-rinat ★★★★★ ()
Последнее исправление: i-rinat (всего исправлений: 2)
Ответ на: комментарий от i-rinat

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

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от true_admin

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

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

hobbit ★★★★★ ()
Ответ на: комментарий от hobbit

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

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от makoven

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

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

cvs-255 ★★★★ ()
Последнее исправление: cvs-255 (всего исправлений: 4)
Ответ на: комментарий от i-rinat

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

нужный ответ

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

всё ещё нет.

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

i-rinat ★★★★★ ()
Последнее исправление: i-rinat (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.