«It is an HTTP/1.0 proxy without the ability for keep-alive requests yet. (As a result, backend connections are created and destroyed on every request.) Nginx talks HTTP/1.1 to the browser and HTTP/1.0 to the backend server. As such it handles keep-alive to the browser.»
Т.е., насколько я понимаю, со стороны пользователя он HTTP/1.1. А вот со стороны сервера — 1.0. Т.е. в пределах одного соединения клиент может сделать несколько запросов (HTTP/1.1). Но они они будут обработаны, как несколько независимых HTTP 1.0 запросов.
Ах, да, при этом заголовки он естественно серверу отдаёт в формате 1.1, но с пометкой HTTP/1.0 :)
Т.е тупо берёт от клиента заголовок и на каждый новый запрос повторяет его изменив 1.1 на 1.0. В целом работает не плохо :)
Зато с ним, возникает вопрос про утилизацию соеденений. Т.е. либо надо иметь pool соеденений, который будет использоваться, либо открывать на каждого пользователя новое keep-alive соеденение и закрывать как уйдет пользователь, либо придумывать асинхронный HTTP.
Т.е. с ходу, я не уверен что keep-alive до backend будет сильным плюсом. Особенно в контексте сложности реализации этого в nginx
Если не секрет, чем nginx лучше lighttpd и почему именно nginx — прорыв?
Я сейчас хочу как-раз на lighttpd перейти с nginx'а ибо конфиг вкуснее, fcgi умеет сам пускать и прочие пряники. Где в нем плохо и почему все на nginx сидят — пока не вижу.
Потому что когда-то, когда было мало памяти, апач был 1.3 и имел некультурных размеров footprint, nginx на самом деле многих спас. Равно как и sphinx — кривые базы mysql, и так далее.
В целом я не против nginx, но сам его не использую, руководствуясь одним принципом — apache пока что мейнстрим, а в лайте конфиги читабельнее.
C какой стати невозможность нормального полнотекстового поиска стала считаться «кривизной», интересно? Кривизна — это когда багов полно и работает не так, как должно.
Ну и где у полнотекстового поиска MySQL сакральное знание? По-момему все достаточно неплохо документировано. Встроенный поиск Oracle и MySQL тоже не панацея. Потому народ пользует sphinx и solr.
в lighttpd конфиги становятся адскими при боле-менее сложной конфигурации
достаточно посмотреть как там SSL запускается чтобы понять что курят разработчики.
Ну по крайней мере новую версию с нуля писать навряд ли будут. И там и там свои проблемы. Но у лайти проблемы серьёзнее. Там даже что-бы патч сконтрибьютить надо угрохать туеву хучу времени. Ну и скажу как человек работающий в группе, которая делает исключительно высоконагруженные сервисы — мы пока остановились на nginx. и его возможностей хватает.
То, что это кому-то нужно еще не повод принимать патчи.
Повод принять патч — очевидная полезность для большинства и удовлетворительное качество патча.
Видимо, чего-то в них не хватает, раз не принимают.
А неважно. Важно, что патч (какой бы он хороший ни был) в апстрим не принимается.
У владельца апстрима может быть море причин не принимать патч. Например, он не хочет его поддерживать в будущем. Может, просто вредный владелец.
Но факт есть факт: патч далеко не так просто внести в апстрим, особенно нетривиальный.
> Важно, что патч (какой бы он хороший ни был) в апстрим не принимается.
Да ладно? В последнее время почти половина записей в changes — это сторонние патчи.
И если какой-то патч не принимается, очевидно, на это есть причина.
Макса? Так всему что сейчас попадает в upstream уже более полугода-года.
Причина почему не принимаются патчи вполне понятна. Нет тестов. И пока не будет внятной системы тестирования (она есть, но Игорь ее не включает), не понятно, что делает патч реально. Т.е. мелочь, да, он охотно принимает. А что-то крупное, увы, нет.
Про этот патч я не говорил с Игорем. Он не большой, но он кривой. Вся реализация rewrite в том виде, как она есть, кривая. Лучшее ее переписать. Есть мысли как, но нет ресурсов. Я думаю это причина, почему патч не был взят в upstream
А вы посмотрите на обилие сторонних патчей, так, к слову. Просто кричать что вы пишете не так, это хорошо, но как мне найти вас в changes? Я там есть, а вы?
ибо скоро год что?
Я его гонял, оно достаточно стабильно и большинство модулей уже реализовано.
Разработчики в ирц подтвердили, что его уже можно пробовать. Просто у них весьма странное отношение к подготовке релизов. 1.5 ветка, тоже, фактически, не была выпущена, но является стабильной.
Скоро год как нет хотя бы бета релиза
ветка 1.5 далеко не стабильная — любые бэкэнды отличные от writev глючат по чёрному при нагрузке.
Даже tarball-ы уже для 1.5 не собирают.
redmine.lighttpd.net/issues/show/758 открыт
кроме того дата 2009
кроме того читаем по линками
кроме того отвечаем по делу
— есть патч, который устраняет данную проблему?
— есть бенчмарки?
— есть практический опыт?
# Status changed from New to Invalid
в каком месте он открыт?
Это как бабки на лавочке перед подъездом: «А я слышала, что он течёт...» Где вообще подтверждение, что на сегодняшний день течёт какая-то из веток, будь то 1.4, 1.5 или 2.0?
Summary: lighttpd of course had some memory leaks (and perhaps even has today), but this bug is not about these problems.
The main problem here is that the memory gets fragmented, and that is why malloc()/free() doesn't return the memory to the system; the memory is not lost to lighttpd, and lighttpd/malloc() will reuse the memory.
закрыт он собственно не потому, что он исправлен, а потому что там оффтоп пошел.
собственно если вы спец в нем, то рассказывайте свой опыт использования, а то вопросы я вроде бы задал, а ответы так и не сказаны.
дык, понятно почему doesn't return the memory to the system, память небось malloc выделяет через sbr и процесс имеет дикую фрагментацию памяти. Как следствие нам часто надо двигать стек данных вновнь. А он, штука такая, не сдвигается.
у меня на одной из 10 Quad-Core AMD Opteron так живёт месяцами между релизами
ps:
lighttpd 23767 1 5 Jun11? 06:00:22 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
top:
23767 lighttpd 20 0 171m 167m 804 R 12 2.1 360:19.90 lighttpd
nginx еще пол года назад находился на уровне лайти. Всплеск сейчас по причине того, что многие ру-хостеры ставят его мордой вперед ибо ру-зоне нгинкс очень популярен.
Я сильно подозреваю, что причина — патриотизм, а не реальные факты.
К патриотизму популярность, увы, вряд ли имеет отношение, учитывая, что часть рунета, покрытая nginx-ом явно меньше 6.5% от общего кол-ва сайтов в мире.
nginx приятен своей системой разработки. 95% кода написано Игорем. Остальные 5% это мелкие-мелкие патчи. Сам nginx простой и тупой. Он сам проще, чем его реализация SSI (sic!). У него хороший, код, написанный в одном стиле. Про лайти я такое, увы, сказать не могу.
lighttpd даже не полностью поддерживает HTTP 1.1 протокол.
Например Continue, от чего некоторые сервисы не работают.
Он медленно развивается, предоставляет меньший функционал.
То что вы в этом вопросе трололо и так понятно.
nginx полностью поддерживает протокол HTTP 1.1, в отличие от lighttpd, в котором полную поддержку уже 3 года обещают.
как будет что-то готовое и рабочее я перенесу все проекты как в свое время слетел с апача, когда более 400 сайтов было апач стал некоторым образом не работать )
Сколько хитов в месяц? 1000 посетителей в день это вообще не нагрузка. У меня в десять раз больше и все нормально. Я даже поверх этого количества еще атаку с помощью ab запускал. И все стоит, не падает. centos.org вообще фиг знает, сколько в день испытывает. А там тоже апач стоит.
1. У меня еще доры там были я их не считал вообше.
2. с 10 раз больше сателитов? или что за сайты.
3. у меня еще джанго
4. в скупе всего я перелез на нгикс
5. скорость работы стала выше — это стало видно даже без тестов.
Что это? Беглая мысль субботним вечером или наброс на вентилятор?
Широкий кругозор? Так расскажите людям, зачем люди используют инджайн икс и почему два предложенных решения являются конкурентами.
Итак типичное применение прокси-сервера для сайте — это поиск подходящего обработчика, и проброс соединения до него. Далее отдача результата клиенту.
Бонус: прокси-сервер берёт на себя взаимодействие с медленными клиентами, снижая затраты на незавершенный ответ.
Бонус: Часто прокси-сервер используется для балансирования нагрузки и т.д.
Некоторые прокси-сервера также удобны для отдачи статики (nginx, lighttpd).
В высоконагруженных системах популярны схемы из цепочек прокси-серверов (от двух).
HA Proxy отличается тем, что его время отклика в среднем ниже, и он не умеет отдавать статику. При этом он нормально отдаёт бэкэнду запросы HTTP/1.1, не портя их. В последних версиях поддерживается драфт WebSockets.
Зачем? Зачем нужно лишнее звено в этом контексте? Может стоит построить ферму web-sockets, взять loadbalancer а не proxy и быть счастливым? У меня ощущение что вы не понимаете что такое nginx.
Не, как loadbalancer он очень уныл. У него плохая статистика. haproxy красив. Цитрикс вообще сказка.
А что мешает сделать разные фермы? Т.е. отдельно статику, отдельно класический web, отдельно порнушку, отдельно спам от клиентов? Собирать все вместе, красиво, не спорю, но дюже странно. Т.е. я не понимаю зачем совмещать все в кучу, если оно, хорошо, параллелится.
Хм, а зачем нужен эксперт исполнитель, если заказчик знает что делать и как? Обычно привлекают эксперта-исполнителя, что бы ему делегировать вопросы как и что.
Я это читал, ты выше написал.
Где она нужна? Примеры? Больших нужных проектов которым это нужно?
Полбраузера поддерживает эту технологию, и всё! Не учитывая приблуд флешевых
Это вариант будущего. Человек хочет его форсировать, ну что с человека взять? Что будет с этой технологией завтра, не понятно. Человек просто сетует, что привычная ему модель жизни в настоящем не подошла для будущего, бывает.
Это, сильно, усложняет логику. У вас появляется параметр количество открытых соеденений. И либо, их не хватает, либо их больше. http синхронный протокол, и не очень удобно использовать keep-alive для backend.
Собственно у меня в загашнике есть свой proxy который умеет keep-alive и асинхроность в HTTP (указывается заголовок для синхронизации). Пока нет повода сделать merge с тем, что есть в upstream.
Эта заметка, явный, не прикрытый, наброс на nginx. Основной дух заметки, nginx гавно, напишите для меня что я хочу. Если вам это действительно надо, мои контакты в профиле. Ты можешь мне позвонить: +1.949.2.666.273 и вскоре появится реализация web sockets в nginx, если она тебе действительно нужна.
e.g. джанго-сайтов на сервере крутиться штук 20 и периодически добавляются. Гемороя с настройкой гораздо больше, нежели если-бы нгинкс умел стартовать сам.
Создайте папочку, /etc/django-sites.d куда складывайте symlinks до корней этих сайтов, и дальше, просто, скриптом их запускайте. Тут не много нужно сил (час) что бы написать этот скрипт.
Почему nginx не должен запускать сайты, тоже понятно. Это очень узкий функционал, который, фактически, используется тем, кому уже нужен nginx но еще нагрузка (пока) позволяет жить на одном сервере. Этот функционал позволяет допустить ошибку в дизайне системе, связанную со стартом приложения. Лучше, все-же, подумать про это, чем потом, в горячке и панике, когда клиентов у ваших сайтов будет сотни тысяч, понимать, как его разнести.
> В настоящее время, к сожалению, этот продукт тормозит развитие Web, так как является динозавром эпохи HTTP/1.0.
Фигню говорите. WebSocket — до сих пор в черновиках W3C и там часто вносятся координальные изменения.
Нет проблемы написать модуль к nginx'у.
А вообще, у меня просто phpDaemon с websocket-сервером висит отдельно от nginx всё отлично. А ваш пост УГ, батенька.
Вроде бы, всегда было деление: nginx — легкий вебсервер. кеширователь, и прочее, а не балансер. И основная цель — снизить нагрузку на бекенд. И зачем ему тогда проксировать вебсокеты?
Замены для nginx (Web Sockets)