Comments 40
В тегах:
Пятница же о_О
всем обновляться
Пятница же о_О
Посмотрел я на плюсатую версию, и так и не понял, чем оно лучше, чем haproxy.
Вспоминается старый анекдот:
Совсем разные продукты же.
— Nginx Plus лучше чем haproxy.
— Чем лучше то?
— Чем haproxy.
Совсем разные продукты же.
Я не про nginx, а про его плюсовую часть. Что дает nginx+ по сравнению с комбинацией nginx и haproxy?
Как минимум, вместо двух разных компонентов вы получаете один с отличной поддержкой. Плюс — это не только расширенные возможности балансировки, это ещё видео-стриминг, мониторинг, очень гибко настраиваемые асинхронные хэлсчеки и много других вкусностей, количество которых возрастает каждые 3 месяца.
Но и одно из самых важных приемуществ — это конечно поддержка. Никто не скрывает, что можно взять бесплатную версию nginx, собрать его с кучей сторонних модулей и полученный комбайн возможно даже будет в какой-то спепени сопоставим по функциональности с коммерческой версией. Но если вы не хотите головной боли на вечер пятницы, проще взять плюс.
Но и одно из самых важных приемуществ — это конечно поддержка. Никто не скрывает, что можно взять бесплатную версию nginx, собрать его с кучей сторонних модулей и полученный комбайн возможно даже будет в какой-то спепени сопоставим по функциональности с коммерческой версией. Но если вы не хотите головной боли на вечер пятницы, проще взять плюс.
Вы говорите как энтерпрайз-продавец. Уже? Так быстро слили nginx? Мдя.
Вы так говорите «поддержка», как будто это кому-то когда-то помогло в критической ситуации.
Итак, представим себе, маленький сайтик, ферма фронтэндов штук 30, выдают свои 15G в режиме proxy_pass и в ус не дуют. Вечер пятницы. Мониторинг присылает warning — latency начинает расти. К моменту, когда админ дошёл до рабочего места, critical, половина фронтэндов не отвечают.
Сценарий
а) Админ покряхтев идёт на сервера, сношается ночь с пятницы на субботу и обнаруживает, что это баг nginx'а, который возникает при определённой комбинации libssl и liblzma, причём при условии, что сертификат истекает менее чем через 2 месяца, а нагрузка на сервер превышает 30 запросов в секунду, и проявляется через 2 часа после начала работы.
Альтернативно:
б) Админ открывает тикет вида «у нас nginx'ы перестают работать самопроизвольно» и ночь с пятницы на вторник переписывается с саппортом, отвечая на идиотские, но очень важные вопросы.
И?
Вы так говорите «поддержка», как будто это кому-то когда-то помогло в критической ситуации.
Итак, представим себе, маленький сайтик, ферма фронтэндов штук 30, выдают свои 15G в режиме proxy_pass и в ус не дуют. Вечер пятницы. Мониторинг присылает warning — latency начинает расти. К моменту, когда админ дошёл до рабочего места, critical, половина фронтэндов не отвечают.
Сценарий
а) Админ покряхтев идёт на сервера, сношается ночь с пятницы на субботу и обнаруживает, что это баг nginx'а, который возникает при определённой комбинации libssl и liblzma, причём при условии, что сертификат истекает менее чем через 2 месяца, а нагрузка на сервер превышает 30 запросов в секунду, и проявляется через 2 часа после начала работы.
Альтернативно:
б) Админ открывает тикет вида «у нас nginx'ы перестают работать самопроизвольно» и ночь с пятницы на вторник переписывается с саппортом, отвечая на идиотские, но очень важные вопросы.
И?
И проблема решается в течение времени, прописанном в SLA (зависит от конкретного контракта), но обычно гораздо быстрее. =)
Встречный вопрос, а что если в случае «а» админ не может устранить проблему (опыта не хватает или проблема нетривиальна и требует хорошего знания, как внутренностей nginx, так и ядра операционной системы, а кроме того развернутый тестовый стенд для выявления и отработки различных ситуаций), а тут праздники на носу, пик продаж, нельзя терять клиентов?
Встречный вопрос, а что если в случае «а» админ не может устранить проблему (опыта не хватает или проблема нетривиальна и требует хорошего знания, как внутренностей nginx, так и ядра операционной системы, а кроме того развернутый тестовый стенд для выявления и отработки различных ситуаций), а тут праздники на носу, пик продаж, нельзя терять клиентов?
О, боже, мне сейчас рассказывают про решение проблем в течение SLA. Вы реально выпустите патч в течение 4 часов с момента заведения кейса? Можно я вам не поверю?
Можете не верить конечно, это ваше право. Но хочу заметить, что мы ежедневно решаем различные проблемы наших клиентов, иной раз и не связанные напрямую с nginx, в то время, как для штатного админа — это зачастую нештатная ситуация.
Мы не занимаемся разовыми продажами, у нас подписка и мы очень заинтересованы чтобы её продлевали.
Мы не занимаемся разовыми продажами, у нас подписка и мы очень заинтересованы чтобы её продлевали.
Это чудесно, но вы же дольше переписываться туда-сюда будете, чем эти четыре часа.
Если предусмотрено контрактом, то вопросы могут решаться и по скайпу, в отдельных случаях можем и доступ на сервер попросить. Всё это решаемые вопросы.
Учитывайте ещё соотношение цены и качества, как уже было упомянуто в топике, это должно быть дорогой админ, плюс он должен не скучать.
Учитывайте ещё соотношение цены и качества, как уже было упомянуто в топике, это должно быть дорогой админ, плюс он должен не скучать.
Ну, это уже убедительно :-)
И всё же, позвольте небольшой disclaimer:
show
.Тут со мной спорить начали, будто я что-то продать пытаюсь. Я даже и близко не продажник, я код разрабатываю, в чем не трудно убедиться посмотрев историю коммитов в nginx. Я не знаю деталей контрактов и прочего, я саппорт вижу только изнутри, как это работает. И готов его защищать, поскольку вижу, что он работает отлично, можно даже сказать, что это одна из тех вещей, которую было бы не стыдно порекомендовать лучшему другу.
Статья в первую очередь о версионировании. Перевел её для хабра, чтобы больше людей понимало, что у нас там с версиями происходит, плюс лишний раз призвать людей принять участие в опросе. Прошу не воспринимать как рекламу.
Статья в первую очередь о версионировании. Перевел её для хабра, чтобы больше людей понимало, что у нас там с версиями происходит, плюс лишний раз призвать людей принять участие в опросе. Прошу не воспринимать как рекламу.
нефиговый админ однако если с такой засадой сам за одну ночь разобрался. Думаю он стоит дороже чем nginx plus. ;)
… многие из которых используют новую архитектуру в разделяемой памяти, специфичную для Plus-версии— а вот это очень печально. Основная проблема внутренней архитектуры nginx, сильно ограничивающая возможности сторонних модулей и вынуждающая использовать страшные хаки для сихронизации между воркерами, получается, решена только в закрытой версии. Это уже не open core-модель, это какой-то half-open core.
Основная проблема, ограничивающая возможности сторонних модулей в том, что для написания любых модулей к высокопроизводительному серверу надо быть очень и очень квалифицированным программистом, понимающим как писать код под асинхронный демон на С.
Таких людей чрезвычайно мало и их стоимость во много раз больше, чем стоимость платных версий софта.
Таких людей чрезвычайно мало и их стоимость во много раз больше, чем стоимость платных версий софта.
Не надо быть очень квалифицированным программистом, чтобы понимать как писать код под асинхронный демон на C. Написать свой собственный примитивный http-сервер на C с использованием какой-нибудь libev вполне реально за день, а без libev под epoll и kqueue за пару-тройку дней. Другое дело, что знать архитектуру nginx, все подводные камни и понимать как наиболее эффективно решить ту или иную задачу в рамках этого сервера, для этого надо иметь немалый практический опыт.
Но symbix говорил не об этом, а о том, что в plus-версии используется архитектура, недоступная в открытой версии, а именно, использование разделяемой памяти. И в некоторых задачах, когда надо «шарить» данные между воркерами, это действительно проблема. К примеру, вы хотите использовать гео-базу на 100Мб. Без раделяемой памяти каждый из воркеров будет отъедать эти 100Мб. А если данных больше? Или вам нужно синхронизировать какие-нибудь счётчики между воркерами и вместо того, чтобы использовать разделяемую память, вы используете redis.
Но symbix говорил не об этом, а о том, что в plus-версии используется архитектура, недоступная в открытой версии, а именно, использование разделяемой памяти. И в некоторых задачах, когда надо «шарить» данные между воркерами, это действительно проблема. К примеру, вы хотите использовать гео-базу на 100Мб. Без раделяемой памяти каждый из воркеров будет отъедать эти 100Мб. А если данных больше? Или вам нужно синхронизировать какие-нибудь счётчики между воркерами и вместо того, чтобы использовать разделяемую память, вы используете redis.
Вообще, от nginx я ожидаю использования COW использования памяти. Разве не так работает? Плюс, какая-никакая, но общая память между ворукерами там есть, shared_mem. Тот же nginx_lua предоставляет доступ к нему.
И чего?
Если вам нужна разделяемая память, то у вас в принципе нет и не может быть никаких проблем оплатить лицензию на nginx+
Потому что если у вас нет денег на лицензию, значит вы в игрульки играетесь и вам хватит любого решения до тех пор, пока не появятся деньги.
Так что всё вполне нормально: поиграть можно с опенсорсом, а когда понадобится что-то больше, то либо пилите сами, либо делайте по-человечески и берите лицензию.
Есть, правда, известная проблема: админы и программисты очень не любят эскалировать до начальства возможность сэкономить деньги покупкой лицензии на софт, в который уже вложены сотни и тысячи человеко-часов работы и отладки. Куда как интереснее ковыряться самому.
Если вам нужна разделяемая память, то у вас в принципе нет и не может быть никаких проблем оплатить лицензию на nginx+
Потому что если у вас нет денег на лицензию, значит вы в игрульки играетесь и вам хватит любого решения до тех пор, пока не появятся деньги.
Так что всё вполне нормально: поиграть можно с опенсорсом, а когда понадобится что-то больше, то либо пилите сами, либо делайте по-человечески и берите лицензию.
Есть, правда, известная проблема: админы и программисты очень не любят эскалировать до начальства возможность сэкономить деньги покупкой лицензии на софт, в который уже вложены сотни и тысячи человеко-часов работы и отладки. Куда как интереснее ковыряться самому.
Ну вы же понимаете, что итоговая стоимость зависит от количества инсталляций, наличия внутренней специфики и еще массы факторов.
Да и я не о том совсем. Я совершенно не против такой модели, и я рад, что Игорь и его коллеги наконец имеют возможность получить достойное вознаграждение за годы труда. Просто все надо называть своими словами. Это — не open core.
Да и я не о том совсем. Я совершенно не против такой модели, и я рад, что Игорь и его коллеги наконец имеют возможность получить достойное вознаграждение за годы труда. Просто все надо называть своими словами. Это — не open core.
вынуждающая использовать страшные хаки для сихронизации между воркерамиУлыбнуло…
Не то чтобы я такие страшные хаки не видел — видел и не мало. Но, большая часть этих «хаков» была от незнания, непонимания и т.д.
Например в одном внутренне-корпоративном модуле (умная такая negotiate keep-alive аутентификация
Т.ч. не надо про проблемы внутренней архитектуры nginx, все в порятке там с этим. Иногда нужно просто RTFM и учить мат-часть.
Расскажите как сделать инкрементный счётчик, который могли бы использовать все воркеры, один для всех? Без костылей?
Запросто, вариантов штук пять на вскидку, ну например:
для счетчика, с чем нибудь типа фильтра по сессии, IP, keepalive conn-ID от nginx и т.д., делаем через sendevent к background-thread, который уже считает и инкрементит (один на всех). Вы когда-нибудь асинхронный логгер писали? Тот же принцип, хотя бы ринг буфер например (N writer / 1 reader). А для чтения воркерами синхронизация не нужна — простой шаред-массив (если разрешен dirty read).
Хотя лучше бы уточнить ТЗ ;)
Слово костыль, кстати, применяется некоторыми людьми по разному. Вот если у энжин нет например стандарной возможности реализовать такой, вами задуманый, счетчик — то что вы сами напишете — это все костыль?
Вопрос: Когда, по вашему, костыль превращается в модуль или API, если вы используеете 50% от энжин (отстальное самописное)?
А может 99%?
Вот я могу вашу задачу реализовать так: беру multithreaded lua, нет лучше Tcl и пишу в конфиге nginx, что-то вида:
а в location FastCGI например, что-то вида:
Это у меня костыль? Я про использование луа или тикля…
К сведенью, накидал ради интереса такое на коленке, привожу результаты замеров скорости (за 5 секунд стрес-теста). Это чтобы сразу закрыть тему скорости (а то постоянно спорят) — я тогда спрашиваю сможет ваш ПХП (питон, любимое подставить) отдать 1 354 224 запросов в секунду:
Повторю вопрос про костыль: что должен делать nginx, а что можно переложить на другие плечи и где он начинается ваш костыль?
для счетчика, с чем нибудь типа фильтра по сессии, IP, keepalive conn-ID от nginx и т.д., делаем через sendevent к background-thread, который уже считает и инкрементит (один на всех). Вы когда-нибудь асинхронный логгер писали? Тот же принцип, хотя бы ринг буфер например (N writer / 1 reader). А для чтения воркерами синхронизация не нужна — простой шаред-массив (если разрешен dirty read).
Хотя лучше бы уточнить ТЗ ;)
Слово костыль, кстати, применяется некоторыми людьми по разному. Вот если у энжин нет например стандарной возможности реализовать такой, вами задуманый, счетчик — то что вы сами напишете — это все костыль?
Вопрос: Когда, по вашему, костыль превращается в модуль или API, если вы используеете 50% от энжин (отстальное самописное)?
А может 99%?
Вот я могу вашу задачу реализовать так: беру multithreaded lua, нет лучше Tcl и пишу в конфиге nginx, что-то вида:
exec_tcl "thread::send -async [tsv::get background-worker bg1] [list incr_cntr CU1 users $remote_addr]";
а в location FastCGI например, что-то вида:
set_by_tcl $c "tsv::get CU1 users";
fastcgi_param X_USER_CNTR $c;
Это у меня костыль? Я про использование луа или тикля…
К сведенью, накидал ради интереса такое на коленке, привожу результаты замеров скорости (за 5 секунд стрес-теста). Это чтобы сразу закрыть тему скорости (а то постоянно спорят) — я тогда спрашиваю сможет ваш ПХП (питон, любимое подставить) отдать 1 354 224 запросов в секунду:
Запись: 0.738 ms/#, 6774784 #, 1354224.44 #/sec
Чтение: 0.482 ms/#, 10387456 #, 2076465.01 #/sec
Повторю вопрос про костыль: что должен делать nginx, а что можно переложить на другие плечи и где он начинается ваш костыль?
Да, надо сразу ставить задачу полностью. Когда писал про счётчик, думал об учёте ограничений в своём рекламном движке, т.е. когда несколько процессов одновременно используют одни и те же данные: показ состоялся, счётчик инкрементировали (атомарно). При этом все процессы используют этот же счётчик для контроля. Если использовать в этом случае shared memory, речь будет идти не о миллионах, а о сотнях миллионов операций в секунду.
Мио или 100 мио, здесь вторично — это как воткнуть еще 100 процессоров, но оставить ту же майнбоард с медлючими мостами, памятью, и особливо старым жестким диском и 10мбит сетью. Сравнимо, имхо… Вопрос по теме вы проигнорировали?
Если «Мио или 100 мио, здесь вторично», тогда к чему «я тогда спрашиваю сможет ваш ПХП (питон, любимое подставить) отдать 1 354 224 запросов в секунду»? Зачем вам nginx, если для вас не важно 2 порядка по скорости?
Какой конкретно вопрос я проигнорировал?
Какой конкретно вопрос я проигнорировал?
Вторично — не есть не важно.
Важнее имо, чтобы энжин не «просел», т.е. работал дальше асинхронно и шустро. Или у вас задача стояла только ваш счетчик отдавать?
А вопрос имелся ввиду — про косяк.
Важнее имо, чтобы энжин не «просел», т.е. работал дальше асинхронно и шустро. Или у вас задача стояла только ваш счетчик отдавать?
А вопрос имелся ввиду — про косяк.
Если использовать ваш метод, об атомарности использования счётчика можно забыть. На каждый запрос к одному из воркеру придётся всем остальным воркерам рассылать эти «инкременты». Таких счётчиков в рамках одного запроса может быть несколько. В результате большую часть времени nginx будет заниматься обработкой запросов для поддержания счётчиков. Это и есть костыль, потому как с shared memory достаточно сделать __sync_fetch_and_add, просто, быстро, атомарно.
Далее, про «косяк». На всей странице есть только одно слово «косяк» и оно в комментарии, на который я отвечаю. После моего комментария таких слов будет 3.
Что вы мне пытаетесь доказать? Что nginx прекрасный продукт? Я ещё 7 лет назад, когда писал свой первый демон на C для обработки запросов рекламной сети, досконально изучил архитектуру и реализацию nginx и я преклоняюсь перед Сысоевым как программистом, потому как код прекрасен и перфекционист внутри меня ликовал, не часто увидишь такой качественный, вылизанный код.
Изначально шла речь о том, что для синхронизации между воркерами приходится использовать костыли, от которых можно было бы избавиться, если была разделяемая память. Вы усомнились, я предложил задачу, вы предложили костыль, щедро посыпая это рассуждениями о том, как некоторые используют nginx, странными алегориями про железо и под конец не можете внятно объяснить какой именно вопрос я проигнорировал. Я не вижу смысла в продолжении этого диалога.
Далее, про «косяк». На всей странице есть только одно слово «косяк» и оно в комментарии, на который я отвечаю. После моего комментария таких слов будет 3.
Что вы мне пытаетесь доказать? Что nginx прекрасный продукт? Я ещё 7 лет назад, когда писал свой первый демон на C для обработки запросов рекламной сети, досконально изучил архитектуру и реализацию nginx и я преклоняюсь перед Сысоевым как программистом, потому как код прекрасен и перфекционист внутри меня ликовал, не часто увидишь такой качественный, вылизанный код.
Изначально шла речь о том, что для синхронизации между воркерами приходится использовать костыли, от которых можно было бы избавиться, если была разделяемая память. Вы усомнились, я предложил задачу, вы предложили костыль, щедро посыпая это рассуждениями о том, как некоторые используют nginx, странными алегориями про железо и под конец не можете внятно объяснить какой именно вопрос я проигнорировал. Я не вижу смысла в продолжении этого диалога.
Да диалог вероятно безсмысленнен…
Вы бы ветку еще раз проглядели… Разговор шел про «страшные хаки», вы же влезли в ветку с элементарнейшим примером (который сами же решили в одну атомарную функцию), который решается «без косяков» минимум 20-ю способами.
Когда вам акуратно намекнули, что де это здесь не обсуждается и этот пример вообще не для nginx (просто у него другие функции) — вы полезли в бутылку…
Если использовать ваш метод, об атомарности использования счётчика можно забыть.Чо это вдруг?!
Это и есть костыль, потому как с shared memory достаточно сделать __sync_fetch_and_add, просто, быстро, атомарно.А после перезагрузки считать его по новой? Вы ваш счетчик точно никуда больше не пишете? (db, gdbm, file etc.).
Вы бы ветку еще раз проглядели… Разговор шел про «страшные хаки», вы же влезли в ветку с элементарнейшим примером (который сами же решили в одну атомарную функцию), который решается «без косяков» минимум 20-ю способами.
Когда вам акуратно намекнули, что де это здесь не обсуждается и этот пример вообще не для nginx (просто у него другие функции) — вы полезли в бутылку…
Изначально шла речь о том, что для синхронизации между воркерами приходится использовать костылиЕще раз спрошу: А почему это вообще должно быть задачей nginx? НЕ надо синхронизировать его воркеры. Точка. Это ассинхронный сервер, и оставте его таким. Положите рядом другой сервис (с привязкой к nginx хоть на shared mem, хоть на scgi), который все что вам нужно синхронно умеет делать. Все.
Я ещё 7 лет назад, когда писал свой первый демон на C для обработки запросов рекламной сети, досконально изучил архитектуру и реализацию nginx и я преклоняюсь перед Сысоевым как программистом, потому как код прекрасен и перфекционист внутри меня ликовал, не часто увидишь такой качественный, вылизанный код.Это тут вообще для чего? Ну я свой первый демон лет 20-ть назад писал… Меряться будем?
Проблема необходимой квалификации действительно существует, и своими силами реализовать синхронизацию между воркерами можно (не на уровне модуля — так на уровне патчей). Но я не об этом. Действительно, «страшные хаки» часто получаются от незнания, но для того, чтобы воспользоваться готовым API, почитав исходники стандартных модулей, знаний нужно меньше, чем для реализации с нуля с погружением в deep internals. Проблема во внутренней архитектуре не в том, что там что-то сделано неправильно. Нет. То, что сделано — сделано хорошо, но штатных способов совместного использования памяти или синхронизации между воркерами там просто-напросто нет. Собственно, это «аукается» и в стандартных модулях — нормальные, консистентные способы управления proxy_cache отсутствуют.
Изначально, при создании Nginx Inc., было заявлено о модели open-core. Я, может быть, неверно понимаю этот термин, но shared memory API я уверенно отношу к core. Теперь же создается впечатление, что не только дополнительные модули, но и все улучшения core api пойдут в коммерческую версию, и никакого nginx 2 не будет, что печально.
Изначально, при создании Nginx Inc., было заявлено о модели open-core. Я, может быть, неверно понимаю этот термин, но shared memory API я уверенно отношу к core. Теперь же создается впечатление, что не только дополнительные модули, но и все улучшения core api пойдут в коммерческую версию, и никакого nginx 2 не будет, что печально.
нет, вы неверно понимаете этот термин.
Это совершенно нормально что расширения, которые реально нужны только тем, кто зарабатывает деньги, идут в платном виде.
Вопрос как всегда очень простой: сколько сейчас ваших строк кода в nginx, что бы рассуждать о печально/не печально? Что вы вложили в проект, что бы что-то требовать взамен? Опенсорс — это не халява, это всего лишь открытые исходники.
Это совершенно нормально что расширения, которые реально нужны только тем, кто зарабатывает деньги, идут в платном виде.
Вопрос как всегда очень простой: сколько сейчас ваших строк кода в nginx, что бы рассуждать о печально/не печально? Что вы вложили в проект, что бы что-то требовать взамен? Опенсорс — это не халява, это всего лишь открытые исходники.
Если говорить про NGINX Plus, то можно вспомнить и китайский Tengine )
Тоже с дополнительными фичами на базе nginx, но бесплатный.
Тоже с дополнительными фичами на базе nginx, но бесплатный.
Sign up to leave a comment.
Релиз NGINX 1.6 и 1.7. Особенности версионирования