После 19 экспериментальных выпусков в тестовой ветке 1.1.x представлена (http://nginx.org/#2012-04-23) новая стабильная версия высокопроизводительного HTTP-сервера nginx 1.2.0 (http://nginx.org). В дальнейшем в рамках новой стабильной ветки API не будет меняться, все существенные изменения будут развиваться в рамках новой экспериментальной ветки 1.3.x.
В соответствии с апрельским отчетом (http://news.netcraft.com/archives/2012/04/04/april-2012-web-...) компании Netcraft nginx используется на 12.76% всех активных сайтов и на 10.09% из миллиона самых посещаемых сайтов в мире. Год назад nginx использовался (http://news.netcraft.com/archives/2011/04/06/april-2011-web-...) на 8.68% всех активных сайтов и 6.52% популярных сайтов. За год nginx перешагнул (http://www.opennet.ru/opennews/art.shtml?num=33286) десятипроцентный рубеж и вытеснил (http://www.opennet.ru/opennews/art.shtml?num=32731) IIS на третье место в рейтинге популярности активных сайтов. В настоящее время под управлением nginx работает около 23.4 млн хостов. По данным W3Techs (http://w3techs.com/technologies/overview/web_server/all) 11% из миллиона самых посещаемых сайтов в мире используют nginx, в апреле прошлого года этот показатель составлял 6.8%. В России nginx используется (http://w3techs.com/technologies/breakdown/ws-nginx/top_level...) на 58.2% самых посещаемых сайтов (год назад - 46.9%).
Из улучшений, добавленных (http://nginx.org/ru/CHANGES.ru-1.2) по сравнению с веткой 1.0.x, можно отметить:- Модуль ngx_http_upstream_keepalive (http://wiki.nginx.org/HttpUpstreamKeepaliveModule) для включения keep-alive соединений с вышестоящими серверами;
- Модуль ngx_http_limit_zone_module, позволяющий ограничить число соединений по определённому критерию, переименован в ngx_http_limit_conn_module (http://nginx.org/ru/docs/http/ngx_http_limit_conn_module.html)
- Директива proxy_redirect (http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#pro...) теперь поддерживает регулярные выражения и переменные в первом параметре.
- Директива proxy_http_version (http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#pro...), задаёт версию протокола HTTP для проксирования.
- Директива fastcgi_keep_conn (http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#f...), позволяет организовать постоянные соединения с FastCGI-серверами.
- Директива worker_aio_requests.
- Директива limit_zone заменена директивой limit_conn_zone (http://nginx.org/ru/docs/http/ngx_http_limit_conn_module.htm...) с новым синтаксисом.
- Директива disable_symlinks (http://nginx.org/ru/docs/http/ngx_http_core_module.html#disa...),определяет, как следует поступать с символическими ссылками при открытии файлов.
- Директивы (http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#pro...) [proxy/fastcgi/scgi/uwsgi]_cache_lock, [proxy/fastcgi/scgi/uwsgi_cache_lock]_timeout. В директивах [proxy/fastcgi/scgi/uwsgi]_cache_path добавлена поддержка параметров loader_files, loader_sleep и loader_threshold;
- Директивы proxy_cookie_domain (http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#pro...) и proxy_cookie_path (http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#pro...), задают текст, который нужно изменить в атрибутах domain и path полей “Set-Cookie” заголовка ответа проксируемого сервера
- Директива pcre_jit (http://nginx.org/ru/docs/ngx_core_module.html#pcre_jit), которая разрешает или запрещает использование JIT-компиляции (PCRE JIT) для регулярных выражений, известных на момент парсинга конфигурации.
- Директивы xslt_param (http://nginx.org/ru/docs/http/ngx_http_xslt_module.html#xslt...) и xslt_string_param (http://nginx.org/ru/docs/http/ngx_http_xslt_module.html#xslt...), которые задают параметры для XSLT-шаблонов;
- Новая переменная $https (http://nginx.org/ru/docs/http/ngx_http_core_module.html#vari...), которая принимает значение "on" если соединение работает в режиме SSL.
- Новая переменная $connection_requests.
- Новые переменные $tcpinfo_rtt, $tcpinfo_rttvar, $tcpinfo_snd_cwnd и $tcpinfo_rcv_space (http://nginx.org/ru/docs/http/ngx_http_core_module.html#vari...) c информацией о клиентском TCP-соединении.- Поддержка указания нескольких DNS-серверов в директиве "resolver".
- Добавлен параметр valid в директиве resolver. По умолчанию теперь используется TTL, возвращённый DNS-сервером;
- Поддержка ограничения по нескольким limit_conn на одном уровне.
- Добавлен параметр so_keepalive в директиве listen;
- Добавлен параметр if_not_empty в директивах fastcgi/scgi/uwsgi_param;
- Теперь можно указать несколько ограничений limit_req одновременно.
- Добавлен параметр from в директиве disable_symlinks.
- Директива worker_cpu_affinity теперь работает на FreeBSD.
- Загрузчик кэша за каждую итерацию либо обрабатывает число файлов, указанное в параметре load_files, либо работает не дольше времени, указанного в параметре loader_threshold.
- Изменение во внутреннем API: теперь при внутреннем редиректе в именованный location контексты модулей очищаются.
- Если сервер, описанный в блоке upstream, был признан неработающим, то после истечения fail_timeout на него будет отправлен только один запрос; сервер будет считаться работающим, если успешно ответит на этот запрос.
- После перенаправления запроса с помощью директивы error_page директива proxy_pass без URI теперь использует изменённый URI.
- Ограничение на количество одновременных подзапросов поднято до 200.
- Теперь keepalive соединения не запрещены для Safari по умолчанию.Из добавленных в процессе разработки nginx 1.1.x новшеств, которые были перенесены в ветку 1.0.x можно выделить:
- Модуль ngx_http_mp4_module (http://nginx.org/ru/docs/http/ngx_http_mp4_module.html) для организации потокового вещания из файлов в формате H.264/AAC.
- Директива image_filter_sharpen (http://nginx.org/ru/docs/http/ngx_http_image_filter_module.h...) для повышения резкости итогового изображения.
- Директива lingering_close (http://nginx.org/ru/docs/http/ngx_http_core_module.html#ling...), управляет закрытием соединений с клиентами.
- Директивы uwsgi_buffering и scgi_buffering.
- Директива max_ranges (http://nginx.org/ru/docs/http/ngx_http_core_module.html#max_...), ограничивает максимальное допустимое число диапазонов в запросах с указанием диапазона запрашиваемых байт (byte-range requests).
- Уменьшение потребления памяти при использовании SSL.
- SSI команда if поддерживает выделения в регулярных
выражениях.- Параметры TLSv1.1 и TLSv1.2 в директиве ssl_protocols.
- Директивы return и error_page теперь могут использоваться
для возврата перенаправлений с кодом 307.
- Двойные кавычки экранируется при выводе
SSI-командой echo.- Cимволы 0x7F-0xFF в access_log записываются в виде
\xXX.
- Директивы "proxy/fastcgi/scgi/uwsgi_ignore_headers"
теперь поддерживают значения X-Accel-Limit-Rate, X-Accel-Buffering и
X-Accel-Charset.- На NetBSD поддерживаются accept фильтры.
- Если суммарный размер всех диапазонов больше
размера исходного ответа, то nginx возвращает только исходный ответ,
не обрабатывая диапазоны.- Уменьшение времени работы загрузчика кэша.
- Поддержка шифров с обменом ECDHE-ключами.
- Уменьшение времени загрузки конфигураций с большим количеством HTTPS серверов.
- Разделяемые зоны и кэши используют семафоры POSIX
в Solaris.URL: http://nginx.org/#2012-04-23
Новость: http://www.opennet.ru/opennews/art.shtml?num=33668
Обновил порты на Фряшечке, спасибо :)
Ну как там обычно говорят любители Генты и Арча: ждем ебилдов!
в арче никогда не ждут ебилдов
В арче в тестинге уже прилетело :3
ментально здоровый человек должен сторонится фразы про ебилды.
это уже ни разу не смешно и уже всем надоело.
> ментально здоровый человек должен сторонится фразы про ебилды.Это фрибсдшник, сэр. Найти ментально здорового среди них - что-то типа поиска верблюда в антарктиде.
> ментально здоровый человек должен сторонится фразы про ебилды.
> это уже ни разу не смешно и уже всем надоело.Если кто-то кажется нездоровым вам, это еще не значит, что они действительно нездоровы.
Факт вашего вашего собственного здоровья пока еще тоже не установлен.Хотя вполне понятно, что вам не смешно и надоело знать, что существуют какие-то вещи, недоступные и непонятные вам. Вот вам и приходится утешать себя мыслями о нездоровье людей, которые умеют извлекать пользу из вещей, недоступных для вас.
> Если кто-то кажется нездоровым вам, это еще не значит, что они действительно нездоровы.Да, когда тебе прилетит в продакшн что-то типа "Директива limit_zone заменена директивой limit_conn_zone с новым синтаксисом" и все нагнется если ты этим пользовался - вот тут мы и посмотрим кто будет здоров а кто нет.
Вот глядя на подобные ченжлоги и понимаешь что политика дебиана/редхата/etc по удержанию версии пакета до выпуска очередной системы не так уж и плоха. Потому что есть авторы которые вот в таком стиле полностью кладут на обратную совместимость и можно поймать некислый факап.
>> Если кто-то кажется нездоровым вам, это еще не значит, что они действительно нездоровы.
> Да, когда тебе прилетит в продакшн что-то типа "Директива limit_zone заменена директивой
> limit_conn_zone с новым синтаксисом" и все нагнется если ты этим пользовался
> - вот тут мы и посмотрим кто будет здоров а кто
> нет.
> Вот глядя на подобные ченжлоги и понимаешь что политика дебиана/редхата/etc по удержанию
> версии пакета до выпуска очередной системы не так уж и плоха.
> Потому что есть авторы которые вот в таком стиле полностью кладут
> на обратную совместимость и можно поймать некислый факап.Нет, тут дело не в авторах, а в том, что у нас слишком много "админов локалхоста" пытаются админить сервера и не понимают, что пора использовать другие подходы и инструменты...
А вот те, кто делают политику обновления для RHEL и других серверных продуктов это уже понимают, и им, например, не мешает выход новых версий ничем - раз в N лет можно затеять обновление формата конфигов даже на тысячах серверов.
> А вот те, кто делают политику обновления для RHEL и других серверных
> продуктов это уже понимают, и им, например, не мешает выход новых версий ничемКапитан, это вы?! :)
> Да, когда тебе прилетит в продакшн что-то типа "Директива limit_zone заменена директивой limit_conn_zone с новым синтаксисом" и все нагнется если ты этим пользовался - вот тут мы и посмотрим кто будет здоров а кто нет.То есть у вас возник какой-то баг, который вы не осилили сами исправить, и к тому же написать баг-репорт вам религия не позволяет. И из всего этого вы сделали все дальнейшие выводы.
> Вот глядя на подобные ченжлоги и понимаешь что политика дебиана/редхата/etc по удержанию версии пакета до выпуска очередной системы не так уж и плоха. Потому что есть авторы которые вот в таком стиле полностью кладут на обратную совместимость и можно поймать некислый факап.
Надо полагать, именно так вы понимаете принципиальное отличие "дебиана/редхата/etc" от систем, которые вы ненавидите, и которые опять-таки отождествляете в кучу между собой исключительно на основе вашей ненависти ко всему, в чем вы не способны разобраться.
И видимо вы убеждены, что именно указанная вами "политика" гарантирует отсутствие багов.
При этом вы эту "политику" даже грамотно сформулировать не можете. И тем более вам невдомек, что "база" BSD-систем как раз таки этой самой политики и придерживается. И наоборот, некоторые дистры на основе "дебиана/редхата/etc" от этой политики отказываются.
> То есть у вас возник какой-то баг, который вы не осилили сами
> исправить, и к тому же написать баг-репорт вам религия не позволяет.Кгм, это не баг, а сознательная разница в подходах. Одни предпочитают "тухлое, но не беспокоиться", другие начинают подпрыгивать, если пошёл третий час с момента выпуска новой версии, а её "всё нет".
[skip]
> То есть у вас возник какой-то баг, который вы не осилили сами
> исправить, и к тому же написать баг-репорт вам религия не позволяет.
> И из всего этого вы сделали все дальнейшие выводы.То-есть, автор сознательно изменил формат конфига и это не баг а фича. А вот если вкатить такую версию поверх старой, оно вполне может вполне ожидаемо нагнуться. Что означает что мало того что апдейт нельзя втулить автоматически (что для автопилотных систем не всегда хорошо) так еще и потребуется переделка конфига.
> Надо полагать, именно так вы понимаете принципиальное отличие "дебиана/редхата/etc" от
> систем, которые вы ненавидите, и которые опять-таки отождествляете в кучуЯ не "ненавижу" а различаю системы которые больше заточены "чтоб работало в боевых условиях" и "чтоб админ фигней мог пострадать". Политика апдейтов первых выработалась как раз за счет существования таких авторов (автор нжинкса далеко не единственный кто так делает, просто очень характерный представитель).
> между собой исключительно на основе вашей ненависти ко всему, в чем вы не способны разобраться.
Ну если вы опериуете такими идиотскими критериями, позволю себе немного глума в ответ: а вы знаете, у меня нет самоцели разрулить вообще все грабли всех систем лично, доказать всем какой я крутой мачо и разобраться в "именно вон той" системе, потому что видите ли для реал мачо только это - труЪ (так сосед Вася сказал!).
> И видимо вы убеждены, что именно указанная вами "политика" гарантирует отсутствие багов.
Она гарантирует отсутствие вышеупомянутых факапов.
А вы лишний раз показали что настолько пионер что даже не в состоянии осознать прочитанное при печати ответа. FAIL засчитан. А потом вы еще и удивляетесь вашей пионерской репутации. Нормально.
> более вам невдомек, что "база" BSD-систем как раз таки этой самой
> политики и придерживается.Какое мне дело до какой-то там базы? Или софт который в базе - ломать нельзя, а который не в базе - можно?
> И наоборот, некоторые дистры на основе "дебиана/редхата/etc" от этой политики отказываются.
И много вы их видели на серверах? :)
Именно. Софт, который непредсказуемо ломает структуру конфига при обновлении даже в минорах, да еще без детальных release notes - в принципе трудно юзабелен.
> Именно. Софт, который непредсказуемо ломает структуру конфига при обновлении даже в минорах,
> да еще без детальных release notes - в принципе трудно юзабелен.http://nginx.org/ru/CHANGES.ru-1.2
Даже на русском!
> Именно. Софт, который непредсказуемо ломает структуру конфигаУгу, как в apache2 дорвавшиеся студенты молча ломали семантику API (время запроса) -- так это было предсказуемо... про последовавший вал дыреней в 2.0.x и одержимое пихание этого сырого хлама в дистрибутивы я как тогда майнтейнер apache-1.3 в альте просто молчу, держал его до последнего. До 2.2 второй апач для production попросту не подходил.
Apache 1 и Apache 2 - это примерно как пятерка VS Audi A6...
> Что означает что мало того что апдейт нельзя втулить автоматически (что для
> автопилотных систем не всегда хорошо) так еще и потребуется переделка конфига.Дополню: "автопилотные системы" не бегают по сайтам апстримов каждые три минуты в поисках, чего бы пособирать -- потому как у вменяемых админов автообновления производятся из мест, в которых несовместимые обратно изменения являются ЧП. Будь это "вечнотухлая" ветка или свой контролируемый репозиторий "вечнонетухлой", куда изменения пропускаются после стендовых испытаний (обновляемость, функциональность, нагрузочная способность).
>> Если кто-то кажется нездоровым вам, это еще не значит, что они действительно нездоровы.
> Да, когда тебе прилетит в продакшн что-то типа "Директива limit_zone заменена директивой
> limit_conn_zone с новым синтаксисом" и все нагнется если ты этим пользовался
> - вот тут мы и посмотрим кто будет здоров а кто
> нет.а вот это проблема исключительно тех, кто считает плюсом обновление ПО по cron ;)
> а вот это проблема исключительно тех, кто считает плюсом обновление ПО по cron ;)"...вкалывают роботы, а не человек".
>> а вот это проблема исключительно тех, кто считает плюсом обновление ПО по cron ;)
> "...вкалывают роботы, а не человек".ну т.е. роботы будут читать changelog`и у обновляторов кроном? я, чесно говоря, сомневаюсь.
> ну т.е. роботы будут читать changelog`и у обновляторов кроном? я, чесно говоря, сомневаюсь.Так в том то и фикус что в нормальном дистре можно просто вкатить апдейт. Там будут секурити фиксы и может быть бэкпорты НЕ ЛОМАЮЩИХ ВСЕ изменений. Читают человеки - майнтайнеры. А вкалывают роботы. Это хорошо.
>> ну т.е. роботы будут читать changelog`и у обновляторов кроном? я, чесно говоря, сомневаюсь.
> Так в том то и фикус что в нормальном дистре можно просто
> вкатить апдейт. Там будут секурити фиксы и может быть бэкпорты НЕ
> ЛОМАЮЩИХ ВСЕ изменений. Читают человеки - майнтайнеры. А вкалывают роботы. Это
> хорошо.ВЕРОЯТНЕЕ всего не ломающих ВАШУ конфигурацию... любой грамотный админ крупной площадки, ВСЕ обновления ВСЕГДА проверяет вручную на СВОЕЙ конфигурации!
Более того, даже в дистрах вроде RHEL возможны обновления ЛОМАЮЩИЕ совместимость, если это необходимо для security-fix.
> обновления ЛОМАЮЩИЕ совместимость, если
> это необходимо для security-fix.Так не бывает.
>> обновления ЛОМАЮЩИЕ совместимость, если
>> это необходимо для security-fix.
> Так не бывает.Чо, правда?! А я и не знал...
> если это необходимо для security-fix.Бывает с примерно такой же частотой как падение метеоритов на головы граждан. Давайте все дружно жить в подземных бункерах? Заметьте, здесь не утверждается что эти бункера совсем никому не требуются :)
не я понял бы написал порт обновил. ото обсуждаем у кого мантенер круче.
Развитие nginx и не думает замедляться - это радует ;)
Глядишь, в 1.3 уже будет поддержка spdy, тогда он будет просто вне конкуренции ;)
SPDY обещалось в мае. 1.3.0 выйдет в мае?
выйдет
> Глядишь, в 1.3 уже будет поддержка spdy, тогда он будет простоА в 1.3.52 добавят эмуляцию апача... А в 1.3.99 число модулей превысит число апачевских... А в 2.1.199 размер кода превысит, и дистрибутивы заменят устаревший апач пакетом apache-compat-server-nginx... Ближе к релизу 2.4 на энжиникс фоундейшн будут сбрасывать платиновую помощь майкрософты и ненужные завалы опенсорса прочие карпорасты... Дети начнут спрашивать, "папа, а кто такой апаче хатэтэпэдэ?!"...
> А в 1.3.52 добавят эмуляцию апача...Будет так же жрать ресурсы, тормозить и форкать процессы? oO
форкает апач процессы или работает с мультитредной моделью зависит от используемого мпм. но большинство-в-интернете(тм) об этом не знает.
> форкает апач процессы или работает с мультитредной модельюО да, конечно, если вместо форка на соединение станет старт треда на соединение - какашка станет на целых три попугая вкуснее. А общая дефективность такой модели никуда не денется - такое в общем случае может положить школьник на диалапе. А отсутствие дуракозащищенности в этом суровом мире - хреново, да. А нжинкс - фиг завалишь, по крайней мере на статике... :)
ерунду какую-то говоришь
> ерунду какую-то говоришьКак аргументировано.
>> форкает апач процессы или работает с мультитредной моделью
> О да, конечно, если вместо форка на соединение станет старт треда нав жизне не делал системы на "неразрывный конект на бесконечной скорости" все делаем под задачу если лишний мег надо воткнуть и поставить апач - легко. у меня нет религиозных предрассутков - кроме энзиникса низачто ничего не поставлю. ну конечно когда надо сделать на том что есть или мапят просто некуда вставить - делаем спецрешение.
> если лишний мег надо воткнуть и поставить апач - легко. у меня нет религиозныхДа уж...
Лишний гиг тоже может не выручить. Когда по совету народа с mozilla.ru посмотрел внимательней на nginx хотя бы в качестве фронтэнда, потребление памяти/нагрузочная способность и впрямь улучшились примерно в десять раз. И это относительно первого апача.
> потребление
> памяти/нагрузочная способность и впрямь улучшились примерно в десять раз. И
> это относительно первого апача.Первый апач... ну что за некрофилия? Я не сомневаюсь, что nginx ведет себя куда лучше первого апача, но вот со вторым, а тем паче - с 2.4, уже надо сравнивать пристальнее, с оглядкой на разницу в функционале. Ну и да - если прикручиваете допустим PHP-FPM - будьте добры еще на него внимание обращать при расчёте нагрузки.
>> потребление памяти/нагрузочная способность и впрямь улучшились примерно в десять раз.
>> И это относительно первого апача.
> Первый апач... ну что за некрофилия?На дворе были 1.3 и 2.0. Первый со своими задачами (в т.ч. разумным расходам времени на поддержку) скорее справлялся, тогдашний второй -- категорически нет (игры в дыркофикс недели разумным расходом времени не считаю). Разумеется, смотреть нужно с бэкендом -- тогда им тот первый апач с каким mod_php или mod_perl и продолжил работать.
> На дворе были 1.3 и 2.0.Тогда, когда на дворе были только 1.3 и младшие 2.0, nginx был вообще неюзабелен - проще было допилить 2.0, чем пытаться завести сабж. Именно тогда было принято решение это поделие не юзать, в силу абсолютнейшей падучести оного при любом чихе.
Подход nginx/FSM определенно хорош, за исключением одной мелочи. Если падает апач в префорке/itk - падает 1 клиентский запрос. Если падает апач в воркере - падает пачка клиентских запросов. Если падает nginx в FSM - падает целиком. Поэтому использовать его на фронтенде можно лишь с минимумом функционала. А на бэкенд nginx ставить - FSM и прочее - это сокеты, годится разве что для мелких инсталляций. Ну и в те времена, о которых вы говорите - оно сыпалось очень часто. Поэтому и такая личная неприязнь к данному проекту. Сляпано на коленке потому что.
>> На дворе были 1.3 и 2.0.
> Тогда, когда на дворе были только 1.3 и младшие 2.0, nginx был
> вообще неюзабеленМожет, для Вас -- у меня nginx-0.1.x вполне справлялся со своими скромными задачами. А смотреть на эти вроде как уже и не младшие apache 2.0.50+ без слёз всё так же не получалось. Понимаю, что у нас с Вами разные предубеждения, но и не навязываю своё.
> Ну и в те времена, о которых вы говорите - оно сыпалось очень часто.
Интересу ради: двухэтажка с monit на бэкенды не?
Ну и повторюсь: в те времена у меня 1.3 бэкендом и работал...
> в жизне не делал системы на "неразрывный конект на бесконечной скорости" все
> делаем под задачу если лишний мег надо воткнуть и поставить апач - легко.А потом приходит школьник с GPRSом и спокойно кладет сайт с своего нетбука одной левой. Просто потому что наделать кучу соединений - много ресурсов не надо.
> А потом приходит школьник с GPRSом и спокойно кладет сайт с своего
> нетбука одной левой. Просто потому что наделать кучу соединений - много
> ресурсов не надо.Про mod_evasive слегка слышали? Школьнику в случае наличия данного модуля не светит абсолютно ничего.
>жрать ресурсы, тормозить и форкать процессы? oOТолько в проприертарном форке, проспонсированном Майкрософтом. И только на Уиндоуз-128.%)
> Только в проприертарном форке, проспонсированном Майкрософтом. И только на Уиндоуз-128.%)?
Оно везде так и от MPM зависит мало.
Глядишь и скоро ему apache для динамики будет уже не нужен.
Не получится. Архитектура не позволяет.
Ему он и не нужен. Он нужен пыхерам.
Нафига? php-fpm, spawn-cgi... мало?
> Он нужен пыхерам.Упоролся? Пых давно цепляется через fastcgi и опач становится как-то ни к чему. А админить 2 сервака вместо 1 - не есть хорошо.
пыхерам просто без htaccess-ов никак(ну или проблематично)
> пыхерам просто без htaccess-ов никакЭто кто придумал? Вон тот буратино? Ну у него и ник подходящий.
>> Он нужен пыхерам.
> Упоролся? Пых давно цепляется через fastcgi и опач становится как-то ни к
> чему. А админить 2 сервака вместо 1 - не есть хорошо.Специально для пыхеров повторяю два раза - он нужен ТОЛЬКО пыхерам, а "не он нужен ВСЕМ пыхерам".
> он нужен ТОЛЬКО пыхерам,А доказательства этого тезиса предоставить можно? Хотя с таким ником уместнее желать разве что замену на "сам себе злобный буратино" наверное :)
>> он нужен ТОЛЬКО пыхерам,
> А доказательства этого тезиса предоставить можно? Хотя с таким ником уместнее желать
> разве что замену на "сам себе злобный буратино" наверное :)Не позорьтесь.
Даже я знаю когда (массово) используется .htaccess.
> Не позорьтесь.К себе примените.
> Даже я знаю когда (массово) используется .htaccess.
Если где-то что-то используется - это еще не значит что это единственный вариант. Хотя у борцунов с php дрочащих на очередной кульный ЯП у которого своих недостатков на трех пыхов хватит такая фигня никогда не смущала.
А нахера ему Апач для динамики? Сто лет как везде повыкидывал Апач.
Уже сто лет как fpm SAPI нативное для пыхеров идёт в PHP. Работа через unix socket или сетевое соединени как FCGI.
Мне идеец нужеть только для SVN_WEBDAV. Вся остальная динамика отправила индейца в пеший эротический поход.
> Глядишь и скоро ему apache для динамики будет уже не нужен.Вчерась запустил очередной apacheless VPS для ещё одного проекта. На nginx. С динамикой. :)
> Вчерась запустил очередной apacheless VPSИ правильно делал ведь - апач памяти жрет ну просто трындец. И надо или круто лимитировать число воркеров в ущерб возможности отгрузки или при малейшем нашествии на сервер все встанет колом.
у апача есть незаменимая весчь которая в энджинксе появится бог знает когда - mod_security - если чО у мня апач стоит фронтом с секурным модулем и проксирует на энджинкс - и мифы про не производительность апача - идут лесом - прекрасно с нагрузкой справляется
> у апача есть незаменимая весчь которая в энджинксе появится бог знает когда
> - mod_security - если чО у мня апач стоит фронтом с
> секурным модулем и проксирует на энджинкс - и мифы про не
> производительность апача - идут лесом - прекрасно с нагрузкой справляетсяИ сколько твою домашнюю страничку человек в год посещает? Мама и ты?
>> у апача есть незаменимая весчь которая в энджинксе появится бог знает когда
>> - mod_security - если чО у мня апач стоит фронтом с
>> секурным модулем и проксирует на энджинкс - и мифы про не
>> производительность апача - идут лесом - прекрасно с нагрузкой справляется
> И сколько твою домашнюю страничку человек в год посещает? Мама и ты?када будешь держать 1К сайтов - узнаешь
> када будешь держать 1К сайтов - узнаешьЕсли это 1К домашних страничек пупкинов, на которых по полтора визита в день - не больно то убедительно получается.
ага а для домашних страничек безопасность не нужна ? - да ладно )))))))))))))
> ага а для домашних страничек безопасность не нужна ? - да ладно
> )))))))))))))Явно вырисовываются две позиции - людей, которые держат массу абонентов (провайдеры + хостеры), и "одиночек", которые занимаются одним ресурсом. Есть еще хайлоад, но, думается, у них позиция третья, и они сюда заходят редко.
а что по вашему значит хайлоад ?
и что это за третья сторона ?
то что они сюда не заходят - факт - они привыкли всё на деле проверять и узнавать и не нуждаются в рекомендациях тролей (вроде хабраюзеров) и популистов
> Если это 1К домашних страничек пупкинов, на которых по полтора визита в
> день - не больно то убедительно получается.Поинт в том, что под массовый сервис лично я бы nginx-only городить не рискнул. Максимум - на фронтенд, и то с оговорками. Под единоличный проект - вполне, там можно хоть на IIS собирать xD
хорошо было бы если можно было юзать прокси кеш без proxy_pass
Это как?Что вы собираетесь кешировать, если не проксируемое?
ну схема такаясначало в прокси пасе указываю сервер - потом через нджинкс собираю контент в кеш (агрессивно всё подряд) - делаю миррор (зеркало) сайта - а потом просто заменяю прокси пасс на несуществующий бекенд и говорю нджинксу чтобы использовал тока кеш
думаю понятно
> думаю понятноНе-а. Может, тебе нужен генератор статики, а не динамо + прокси-кеш + костыли?
для особо тупыхкраулер -> local_nginx ---(проксирует на реальный сайт и сохраняет в кеше)----> web_site
кеш держится довольно долго и кешируется всё подряд
потом в local_nginx заменяем proxy_pass http://мёртвый адрес и всё - статический миррор сайта готов с сохранением всех URL
Про директиву proxy_store слышали?
> Про директиву proxy_store слышали?ага - и энджинкс тянет контент оттуда если выпал бекенд ?
даже proxy_cache_use_stale не помогает - а в случае с прокси кешом - всё норма
ps: может proxy_store ещё сохраняет ответы от сервера - всякие перенаправления и нот фоунды ?
>> Про директиву proxy_store слышали?
> ага - и энджинкс тянет контент оттуда если выпал бекенд ?Если руки из нужного места растут, то настроить можно как угодно.
hint:
error_page 502 =200 @stored;
location @stored {
root ...
}> даже proxy_cache_use_stale не помогает - а в случае с прокси кешом - всё норма
И кто мешает использовать proxy_cache? Вы сами себе противоречите.
>>error_page 502 =200 @stored;ага и запрос в два раза дольще будет выполняться - сначало оброботка ошибки а потом перенаправление на именнованный локейшен а када там нет контента вернёт нотфоунд
>>И кто мешает использовать proxy_cache?
читайте первый комент
всё дело в том что нуно пихать фейковый несуществующий бекенд чтобы через proxy_cache_use_stale задействовать то что лежит в кеше.
Так вы определитесь, что вам надо. Если сначала смотреть сохраненную версию, то:location / {
root /path/to/storage;
try_files $uri @backend;
}location @backend {
root /path/to/storage;
proxy_pass ..;
proxy_store ..;
}Ваш первый коммент и далее про некий фейковый бэкенд - это бредни какие-то. Вы сеошник что ли?
вас продолжать дальше кормить или наелись ?100 раз уже повторяю - миррор сайта (по-русски - зеркало сайта) - а для чего он нуже это уже другой вопрос - вся суть в том чтобы зеркало сайта ничем не отличалось от реального
какой там может быть бекенд ?
Для этого есть специальные утилиты или вам нравится гвозди забивать микроскопом?
> Для этого есть специальные утилиты или вам нравится гвозди забивать микроскопом?
>>утилитыпросветите пжалуста - они также как и реальный сайт на энджинксе будут держать нагрузку ?
пс: для краулинга юзаю httrack если чО - есть ли есть альтернатива - буду рад, тока не предлагайте wget c параметром -r
> хорошо было бы если можно было юзать прокси кеш без proxy_passза минус спасибо - сначало спросите для чего это нужно
Хех, недавно видел инструкцию по настройке веб-сервера (или вообще LAMP, не помню точно), где говорилось, что nginx - это _не_ веб-сервер, а ускорялка для Apache. Ага, прямо вот такими фразами.
Хотя тут оба виноваты. Nginx нынче улучшает работу с бэкендами, а Apache - с фронтендами.
Недавно видел в книжку, где говорилось, что детей аист приносит. Ага, прямо так и говорилось.
Существуют ли сайты, где nginx главный и единственный движок (без Apache),
а не FrontEnd? И если уже совсем обнаглеть: существуют ли nginx-only-based CMS?
У меня пара сайтов чисто на nginx без всяких апачей живет. В качестве движка Drupal. Все работает :)P.S. Посетителей на них не особо много, но с теми, кто таки заходит, сей конфиг справляется на ура.
Конечно существуют, проблемы тут нет никакой.
> Существуют ли сайты, где nginx главный и единственный движок (без Apache),
> а не FrontEnd? И если уже совсем обнаглеть: существуют ли nginx-only-based CMS?Для небольшого локалхоста вполне годно. А вот под нагрузку такое ставить не стоит.
Выше был ответ дилетанта на вопрос дилетанта.
> Выше был ответ дилетанта на вопрос дилетанта.success story в студию или трепло
Я не виноват что у вас что-то не получилось. Лучше, давайте вы ваши возникшие проблемы озвучите.А наша success-story - это nginx + php-fpm. Он, между прочим, фичастее чем mod_php в плане управления "долговыполняющимися" процессами.
> А наша success-story - это nginx + php-fpm. Он, между прочим, фичастее
> чем mod_php в плане управления "долговыполняющимися" процессами.Нагрузка? 1000 посетителей в сутки?
У нас особых проблем нет - Apache как на фронтенде (worker), так и на бэкенде (mpm-itk).
>Нагрузка? 1000 посетителей в сутки?15к+ посетителей и 200к+ хитов в сутки, достаточная нагрузка? После отказа от апача, общая загрузка сервера заметно снизилась.
Ну, так, что бы "специалиста" расслабить (того, у которого nginx+fpm только одного посетителя в сутки выдерживает). Связка такая же - nginx+fpm, от 90 до 120к уников в сутки, хитов - 3-5 лямов. Как-то так, да. Учите матчасть.
> Ну, так, что бы "специалиста" расслабить (того, у которого nginx+fpm только одного
> посетителя в сутки выдерживает). Связка такая же - nginx+fpm, от 90
> до 120к уников в сутки, хитов - 3-5 лямов. Как-то так,
> да. Учите матчасть.А хостнейм? :)
> А хостнейм? :)Вы свои скажите, а мы посмотрим сколько посетителей опеннета умеют запускать "утилиты для бенчмарков и нагрузочного тестирования". Ну и заодно посмотрим насколько ваш апач крут :)
я отстал от жизни и HTTP/1.1 в nginx уже сделали?
> я отстал от жизни и HTTP/1.1 в nginx уже сделали?Вижу, в 1.1 добавили chunked. Вопрос снят. Надо бы попробовать вернуться к этому серверу, смысл видимо есть.
> смысл видимо есть.Лучше скажи какой смысл в этом неповоротливом древнем утюге? У apache все что ни проект - то монструозный и тормозной переросток для энтерпрайза, где меньше чем 16 ядер и 128 гигз - вообще не машина, типа. Не, в теории на машине с бесконечной оперативой и столько же процессорных ядер, апач бесконечно масштабируем и ни во что не упирается. На практике он почему-то имеет свойство дико жрать ресурсы, так что если на сервер приперся хабраэффект/слэшдотэффект/кактамего - начинается полный ахтунг.
1000 в сутки, в среднем, это один клик в 1,5 минуты =) С этим мой телефон справится, даже если туда апач поставить и мускул.
> У нас особых проблем нет - Apache как на фронтенде (worker),Проблемы начинаются когда школьник начитавшийся журнала "хакер" тыщщу конекций пускает для лулзов. При этом апач или выжирает все ресурсы на сервере, если лимиты не настроены и все дохнет к такой-то матери, или вредитель узурпирует всех воркеров на длительный срок выбрав лимиты, так что остальным воркеров почти не достается. Для юзера сие выглядит довольно однофигственно: он не обслужен и обламывается по таймауту.
Результат? Все сайты с более-менее серьезной нагрузкой и/или подвергающиеся пакостям от пионерии очень быстро осознают что апач с воркерами в роли фронтэнда не лучше моей бабушки в роли балерины. А такие как вы понимают только когда им 10К конекций в лоб предъявят так что все нагибается.
> Результат? Все сайты с более-менее серьезной нагрузкой и/или подвергающиеся пакостям от
> пионерии очень быстро осознают что апач с воркерами в роли фронтэнда
> не лучше моей бабушки в роли балерины. А такие как вы
> понимают только когда им 10К конекций в лоб предъявят так что
> все нагибается.Для этого существуют превентивные меры еще на входе. К слову говоря, когда предъявят 10005000+ коннектов - загнётся любой сервер, вне зависимости от софта. Просто памяти не хватит. В случае кластера - умножайте на число хостов. Поэтому пионерия, расчитывающая, что nginx спасёт их от всех бед, обречена в любом случае.
Nginx расходует примерно 300 байт на одно соединение. Так что пионерия может спать спокойно.
> Nginx расходует примерно 300 байт на одно соединение. Так что пионерия может
> спать спокойно.Еще разое, хоть в теме уже было. Nginx выдерживал ддосы до ширины канала, фильтруя трафик. Так что прекратите уже красноглазие, осваивайте лучше lighthttpd, nginx и haproxy. А уж если преданы Apache Foundation - то осваивайте Traffic Server, что по сути та-же хрень что и вышеупомянутые три продукта.
> Для этого существуют превентивные меры еще на входе.Да, мы сначала воткнем хилый фронтэнд а потом у нас будет головняк что он дохнет от каждого пшика.
> К слову говоря, когда предъявят 10005000+ коннектов - загнётся любой сервер,
Нжинкс не загнется, например. Он процессы не форкает - ему пофиг. Машина состояний - она и есть машина состояний. Потребление ресурсов на само по себе жонглирование тыщщами соединениями там кардинально ниже, сравнимо с затратами клиента.
> вне зависимости от софта.
Размечтался. То-то у сайтов подвергающихся "пионерским досам" такого плана первым делом отрастает на входе нжинкс почему-то.
> Просто памяти не хватит.
В случае с апачем ее жрач кардинально больший - на форки процессов. А в нжинксе только ядром на буфера, только сие и на клиенте жрется что делает атаку куда более симметричной по ресурсам и менее интересной для клиента.
> В случае кластера - умножайте на число хостов.
Да понятный фиг, энтерпрайзники богатые, им для защиты от нетбука и жпрс свистка воткнуть кластер за несколько десятков килобаксов не вопрос. А что если у хаксора два нетбука окажется случайно? Спецом под него удвоить парк серверов? Вот это и называется апач головного мозга...
> Поэтому пионерия, расчитывающая, что nginx спасёт их от всех бед,
> обречена в любом случае.От всех не спасет, однако сайты с нжинксом как правило не лагают по дикому от хабраслэшдотэффектов и не валятся совсем уж пионерскими атаками. Лично видел как интернет магазины дико клинило от пионерских атак конкурентов вплоть до втыкания нжинкса фронтом, после чего таковым резко полегчало и конкуренты забили на атаки в силу затратности и нужды платить за более мощные атаки которые совсем уж наколенными методами не делаются.
>> К слову говоря, когда предъявят 10005000+ коннектов - загнётся любой сервер,
> Нжинкс не загнется, например.И на основании ж чего такой вывод? На каждый сокет требуется энный размер памяти - загнётся что угодно, не только nginx.
>> вне зависимости от софта.
> Размечтался. То-то у сайтов подвергающихся "пионерским досам" такого плана первым делом
> отрастает на входе нжинкс почему-то.У пионерских сайтов, подвергающихся пионерским досам. Fixed.
> В случае с апачем ее жрач кардинально больший - на форки процессов.
Логично. Но сути это не меняет.
> А в нжинксе только ядром на буфера
Огаога. А вы лично-то хоть смотрели, как у nginx'а дела с буферизацией обстоят? Там одно из двух: либо выделяем мелкий буфер, и имеем проблемы с размером хедеров, либо выделяем большой буфер, и имеем хороший такой жрач по памяти на запрос.
> сие и на клиенте жрется
Не-а. Клиент может вообще не использовать буферы - в случае DoS ему поддержание псевдо-соединения нужно только до момента отправки запроса. После того, как запрос ушел, сервер взялся за работу. Против таких гавриков неплохо помогает небуферизованная отправка первого пакета с хедерами перед какой-либо тяжелой обработкой динамики.
>> В случае кластера - умножайте на число хостов.
> Да понятный фиг, энтерпрайзники богатые, им для защиты от нетбука и жпрс
> свистка воткнуть кластер за несколько десятков килобаксов не вопросКластеры делаются из-за тяжелой динамики, а не "для защиты". Для защиты ставятся фронтенды с рядом модулей. А чаще - вообще аппаратные решения на периметр.
> И на основании ж чего такой вывод? На каждый сокет требуется энный
> размер памяти - загнётся что угодно, не только nginx.Только в случае апача требуется еще и куча памяти на сами процессы апача и загибон наступает намного быстрее. Если меряться буферами сокетов - мощный сервант ваш нетбук переспорит на раз и успешная атака потребует кучу оборудования (==стоит дорого). А вот если там еще и апачовые процессы будут память жрать то единственный вшивый нетбук спокойно завалит многопроцессорный xeon пнув воркеров по максимуму и узурпировав их.
>> отрастает на входе нжинкс почему-то.
> У пионерских сайтов, подвергающихся пионерским досам. Fixed.Ну да, конечно, только у вас сайты не пионерские. А вот у всех остальных - пионеры. Особенно если не по вашему делают.
>> В случае с апачем ее жрач кардинально больший - на форки процессов.
> Логично. Но сути это не меняет.Это меняет затраты атакующего на атаку. Если в одном случае ему хватит чуть ли не мобильника с GPRS, во втором ему надо ставить уже парк серверов примерно равный по мощности тому что у конторы чтобы просто ощутимо затормозить это, т.к. буфера сокетов на обоих концах линка примерно одинаково жрутся. Гуглить про "усиление атаки". Вот апач дает некислое плечо атакующему, позволяя валить мощные сервера с всякой ерунды. Откровенная такая атака на ресурсы с большим плечом получается.
> проблемы с размером хедеров, либо выделяем большой буфер, и имеем хороший
> такой жрач по памяти на запрос.А нефиг слать большие хидеры. Ну нет у легитимного клиента валидного повода так делать, а проблемы ботов волнуют только ботов. За такое вообще сразу банан и пусть бот/хаксор отдыхает.
>> сие и на клиенте жрется
> Не-а. Клиент может вообще не использовать буферы - в случае DoS ему
> поддержание псевдо-соединения нужно только до момента отправки запроса.На этот момент он должен помнить о соединении и держать под него буфера, etc. Более того, если совсем не забирать данные из соединение и не трекать его, со стороны сервера можно довольно оперативно давить такое по таймауту, просто установив его достаточно скромным.
> После того, как запрос ушел, сервер взялся за работу. Против таких гавриков
> неплохо помогает небуферизованная отправка первого пакета с хедерами перед
> какой-либо тяжелой обработкой динамики.Ну спасибо тебе кэп. Обычно при пионерской атаке гаврик начинает просто неспешно качать твои 300 кб простыни на скорости 1Кб/сек. Это просто, делается типовыми утилями и требует минимум и ресурсов и мозгов. А вот на 1 свой буфер сокета такой гаврик займет 1 воркер апача + некую память под буфер сокета на сервере. И озадачивая собой воркера на 5 минут. А если 1000 воркеров так форкануть - сервер чудно сколлапсирует, или потому что память на серваке кончается, или потому что все воркеры заняты обслуживанием хакера на ближайшие 5 минут. Ну а юзер зайдя на сайт и так и сяк получает таймаут и отползает восвояси. Цель атами достигнута - сайт недоступен :). А машине состояние пофиг. Ну висит 1000 малоактивных соединений - и пусть висит. Она вообще на них дергается лишь когда состояние меняется.
>> Да понятный фиг, энтерпрайзники богатые, им для защиты от нетбука и жпрс
>> свистка воткнуть кластер за несколько десятков килобаксов не вопрос
> Кластеры делаются из-за тяжелой динамики, а не "для защиты". Для защиты ставятся
> фронтенды с рядом модулей. А чаще - вообще аппаратные решения на периметр.Ну да, ну да. А у юзеров нжинксы один сраный 10-баксовый вдсник выдерживает хабраслэшдотэффекты если сделано с умом. Во сколько раз затраты бабла отличаются - сами посчитаете.
>>> Только в случае апача требуется еще и куча памятиВыбросьте уже винду.
Under Linux, fork() is implemented using copy-on-write pages.>>> А нефиг слать большие хидеры.
А может вообще нефиг запросы слать? И не свалится ничего. Большие хедеры сплошь и рядом встречаются, на тех же цискокомах и прочем куки несколько по килобайт весят. Почему нет?
>>> А у юзеров нжинксы один сраный 10-баксовый вдсник
Нищебродство - основа. Всё правильно, 10-баксовый вдсник хорошо годится для васяпупкинпейдж, отсюда и вывод про пионеров.
>>> Обычно при пионерской атаке гаврик начинает просто неспешно качать твои 300 кб простыни на скорости 1Кб/сек.
Ну и? Опять пионерство ака "поставим silver bullet и всё будет тип-топ"?
Как это в nginx+fpm/fcgi вас спасет от форка? В случае Apache статика отдается через sendfile, и форк требует минимум памяти, угу. А в случае динамики ваш FPM/FCGI тупо завалится, и результат будет един.
Т.е. в приведенном примере хоть nginx, хоть apache, хоть light - защита должна делаться другими методами. У апача есть mod_evasive, спасающий от пионеров с 1-2-3 IP, и более-менее стабильное API в пределах ветки, если писать свой модуль против более хитрозадых. А у nginx?
Трепло тут ты, nginx под нагрузкой работает отлично.
Если не понимаешь почему - это не повод рассказывать чушь.
Success story - полрунета.
Nginx frontend + php-fpm backend масштабируется в любую сторону.
Пять лет в разных highload проектах, ни разу не видел апача в production.
Хотя коллеги по цеху рассказывают, что не смогли отойти от mod_php и используют связку nginx + apache. Я не использовал ни разу с момента прихода в highload.
Ну и если тебя прям совсем цифры интересуют - на входе ~5k rps, ~80 mbit обрабатываются парой закарпленных nginx. И это далеко не предел.
Верю, что и апач это осилит. Но не использую.
> Трепло тут ты, nginx под нагрузкой работает отлично.
> Если не понимаешь почему - это не повод рассказывать чушь.
> Success story - полрунета.Ты не понимаешь ни сути, ни причины. Хотя - это одна из причин, по которой nginx популярен в рунете - сильна идеология поиска silver bullet вместо решения прямых задач надежности и масштабируемости.
>> Трепло тут ты, nginx под нагрузкой работает отлично.
>> Если не понимаешь почему - это не повод рассказывать чушь.
>> Success story - полрунета.
> Ты не понимаешь ни сути, ни причины. Хотя - это одна
> из причин, по которой nginx популярен в рунете - сильна идеология
> поиска silver bullet вместо решения прямых задач надежности и масштабируемости.Расскажи, пожалуйста, что же я не понимаю.
Заодно представься что ли, что за проект ведешь/поддерживаешь.
> Расскажи, пожалуйста, что же я не понимаю.
> Заодно представься что ли, что за проект ведешь/поддерживаешь.И, раз ты уж всё понимаешь, расскажи принципиальное отличие apache от nginx.
У меня тут вакансия есть, но нужен понимающий.
Nginx не блокируемый.
> Nginx не блокируемый.Nginx как раз ОЧЕНЬ блокируемый =)
Он не блокирующий, это да.
> И, раз ты уж всё понимаешь, расскажи принципиальное отличие apache от nginx.State machine обслуживающая в 1 потоке много соединений сразу (nginx) vs 1 поток или процесс на соединение у апача (как минимум с типовыми дефолтными воркерами). Первое менее затратно по ресурсам, особенно на статике или при проксировании, ясен пень.
Я ответил на ваш вопрос? Мне интересно - проверить самого себя и корректность знаний лишний раз всяко не лишне :)
> У меня тут вакансия есть, но нужен понимающий.А что за вакансия?
> Я ответил на ваш вопрос?На пятерку.
На пять с плюсом можно еще вспомнить про цену переключения контекста при мультитрединге.> А что за вакансия?
Админская, вестимо
>> Я ответил на ваш вопрос?
> На пятерку.Значит у меня полимеры на месте :).
> На пять с плюсом можно еще вспомнить про цену переключения контекста при мультитрединге.
Можно.
>> А что за вакансия?
> Админская, вестимоНу огласите вилку, чтоли и чего вообще хотите. Вдруг оно интересным окажется?
> Ну огласите вилку, чтоли и чего вообще хотите. Вдруг оно интересным окажется?welcome в почту: dolphin@sendmail.ru
>> И, раз ты уж всё понимаешь, расскажи принципиальное отличие apache от nginx.
> State machine обслуживающая в 1 потоке много соединений сразу (nginx) vs 1
> поток или процесс на соединение у апача (как минимум с типовыми
> дефолтными воркерами). Первое менее затратно по ресурсам, особенно на статике или
> при проксировании, ясен пень.
> Я ответил на ваш вопрос? Мне интересно - проверить самого себя и
> корректность знаний лишний раз всяко не лишне :)
>> У меня тут вакансия есть, но нужен понимающий.
> А что за вакансия?так это не отличие apache от nginx, а отличие mpm prefork от nginx. т.к. если использовать mpm worker или mpm event и интерпретатор через fcgi, то использование апача или нгинкса уже становится вопросом религии.
> через fcgi, то использование апача или нгинкса уже становится вопросом религии.У апача помнится все воркеры кроме наиболее дебильных сто лет были как нечто кривое, бажное и дико экспериментальное, поэтому так как вы говорите - было только на бумаге. А на реальных серверах почему-то именно так как описано по жизни. Наверное, всем лень эксперименты на себе любимых ставить.
А у нжинкса такая модель сервирования - с самого начала и отнюдь не как эксперименты. "Небольшая" такая разница.
>> через fcgi, то использование апача или нгинкса уже становится вопросом религии.
> У апача помнится все воркеры кроме наиболее дебильных сто лет были как
> нечто кривое, бажное и дико экспериментальное, поэтому так как вы говорите
> - было только на бумаге. А на реальных серверах почему-то именно
> так как описано по жизни. Наверное, всем лень эксперименты на себе
> любимых ставить.
> А у нжинкса такая модель сервирования - с самого начала и отнюдь
> не как эксперименты. "Небольшая" такая разница.это не так. проблема была с mod_php и мультитредным мпм. с ним действительно были проблемы. в случае с fastcgi и мультитредными мпм проблем нет.
> это не так. проблема была с mod_php и мультитредным мпм. с ним
> действительно были проблемы. в случае с fastcgi и мультитредными мпм проблем нет.А у меня нет этого неповоротливого утюга и проблем с ним соответственно нет. State machines FTW. Особенно для отдачи статики. А если кто слишком криворук чтобы такое программить... ну так чего от энтерпрайз-шараг ожидать?
> так это не отличие apache от nginx, а отличие mpm prefork от nginx.Коллега, у nginx и apache принципиально разный подход к обработке соединений.
В апаче один запрос обрабатывается одним основным тредом и его хелперами, какой бы mpm не использовался. Выбор mpm - это всего лишь оптимизация процесса обработки соединений.
mpm_event, в теории, значительно увеличивает пропускную способность, но не производительность, так как соединение по-прежнему обслуживается отдельным тредом-хелпером, хоть и освобождая основной тред.nginx все соединения обрабатывает одним тредом, т.к. он работает не в контексте соединения, а в контексте пакета, перекладывая большую часть задач на ядро (backlog, sendfile, aio, accepf filters и проч). В nginx есть, грубо говоря, массив состояний соединения, и каждый пакет изменяет эти состояния, тогда как апач выделяет отдельный тред под обработку соединения. В общем теорию КА (FSM) вам на изучение.
Вот принципиальная разница, поэтому апач не может обработать 10k одновременных соединений, а nginx не может работать с cgi (не путать с *cgi, для которых nginx выступает проксёй) т.к. это его блокирует - операция обработки пакета должна занимать крайне малое конечное время.
P.S. mpm_worker тоже мало отличается - создается N форков по M тредов. И всё равно на одно соединение - один тред.
Кстати, еще раз: у апача существует аналог nginx - Apache Traffic Server, что как бы говорит о том, что апач сам по себе не может быть фронтом на больших нагрузках.
> В общем теорию КА (FSM) вам на изучение.Теорию КО (Cap'n Obvious) вам на изучение, Кэп.
> Вот принципиальная разница, поэтому апач не может обработать 10k одновременных соединений,
Кэп?
> а nginx не может работать с cgi (не путать с *cgi,
Кэп?!
> для которых nginx выступает проксёй) т.к. это его блокирует - операция
> обработки пакета должна занимать крайне малое конечное время.Нет, ну Кэп же!
Капитан, а вы не хотите мне рассказать сколько будет 2+2?
> P.S. mpm_worker тоже мало отличается - создается N форков по M тредов.
> И всё равно на одно соединение - один тред.Эк вас сегодня на капитанство то прошибло.
> Эк вас сегодня на капитанство то прошибло.Ну так раз кэп, то как вы сравниваете nginx и апач?
> Success story - полрунета.рунет - не показатель. какбэ. у него специфика. в рунете и BSD можно встретить
>> Success story - полрунета.
> рунет - не показатель. какбэ. у него специфика. в рунете и BSD
> можно встретитьВы что-то имеете против BSD?
>>> Success story - полрунета.
>> рунет - не показатель. какбэ. у него специфика. в рунете и BSD
>> можно встретить
> Вы что-то имеете против BSD?конкретно у него, видимо, попоболь, т.к. на бсд не нужно патчить ядро и недософт, чтобы она могла темринировать клиентские pppoe, например. У него есть некие Пачти ядра linux, и Патчи на некоего pppoed (или че там). Только с этими Патчами (дада, с большой буквы П) оно может хоть как-то работать.
>>>> Success story - полрунета.
>>> рунет - не показатель. какбэ. у него специфика. в рунете и BSD
>>> можно встретить
>> Вы что-то имеете против BSD?
> конкретно у него, видимо, попоболь, т.к. на бсд не нужно патчить ядро
> и недософт, чтобы она могла темринировать клиентские pppoe, например. У него
> есть некие Пачти ядра linux, и Патчи на некоего pppoed (или
> че там). Только с этими Патчами (дада, с большой буквы П)
> оно может хоть как-то работать.Ну, коллега, тут вы тоже перебираете. Просто я, например, знаю где лучше чёрт, где лучше пингвин, а где и солярку стоит попробовать. И по этому всегда удивляюсь красноглазию или бздфилии. Кесарю - кесарево.
> Ну, коллега, тут вы тоже перебираете. Просто я, например, знаю где лучше
> чёрт, где лучше пингвин, а где и солярку стоит попробовать. И
> по этому всегда удивляюсь красноглазию или бздфилии. Кесарю - кесарево.если научите как по другому ставить на место "специалиста" alexat, не так толсто, я буду признателен. знающие системы "по l.o.r`у" типа него.. несколько утомляют.
> если научите как по другому ставить на место "специалиста" alexat, не так
> толсто, я буду признателен. знающие системы "по l.o.r`у" типа него.. несколько
> утомляют.Как ребенка, разговаривая, объясняя. Вы же не бьёте детей, если они еще чего-то не понимают? Они же дети, вырастут - научатся.
> если научите как по другому ставить на место "специалиста" alexat, не так
> толсто, я буду признателен. знающие системы "по l.o.r`у" типа него.. несколько
> утомляют.вы можете просто пройти лесом, надежнее и тоньше
> конкретно у него, видимо, попоболь,Судя по коментам, болит пониже хвоста совсем не у него.
> конкретно у него, видимо, попоболь, т.к. на бсд не нужно патчить ядро"На бсд" для многих задач (да-да, и виртуализации) ядро патчить просто нечем, кроме Ваших золотых рук... может, давайте рядом с [[LicenseComparison]] ещё какой [[PlatformComparison]] или там [[Сравнение фрюниксов]] начнём выписывать?
>> конкретно у него, видимо, попоболь, т.к. на бсд не нужно патчить ядро
> "На бсд" для многих задач (да-да, и виртуализации) ядро патчить просто нечем,ну нечем, и что?:-)
> кроме Ваших золотых рук... может, давайте рядом с [[LicenseComparison]] ещё какой
> [[PlatformComparison]] или там [[Сравнение фрюниксов]] начнём выписывать?а это чем-то чему-либо поможет?
можно пытаться натянуть презерватив на глобус^W^W^Wнекие патчи на некие ядра, только зачем, если можно взять нечто готовое? у меня есть 2 тачки с линуксом, не скажу что я рад этому факту, но в тех задачах оно работает. фря не смогла, солярис не пробовал, но, думаю, рез-т будет не сильно лучше чем с fbsd. 10+ Тб инфы, преимущественно фильмы по 1.4Тб, дофига одновременно смотрящих/качающих с этой тачки хомячков, тут софтрейд+xfs показал себя значительно лучше raidz, на том же железе. Но г-н alexat убежден, что линукс в его задачах рвет всех, хотя "всех" он врядли видел, не то что пробовал. Однако сей факт не мешает ему тупить на форумах, обсирая ОСь которую он не знает/не видел.
>> может, давайте рядом с [[LicenseComparison]] ещё какой [[PlatformComparison]]
>> или там [[Сравнение фрюниксов]] начнём выписывать?
> а это чем-то чему-либо поможет?Не исключено, ведь по крайней мере:
- будет куда нос засунуть на предмет текущего состояния (как свой, так и чужой);
- вместо фекания металий требующим спуску пара можно будет предложить
технические раскопки и в меру сил -- грамотное оформление.Например, ссылки на те же сравнения производительности современных альтернатив poll(2) в контексте высоконагруженных веб-серверов могут пригодиться.
> Но г-н alexat убежден, что линукс в его задачах рвет всех,
> хотя "всех" он врядли видел, не то что пробовал. Однако сей
> факт не мешает ему тупить на форумах, обсирая ОСь которую он
> не знает/не видел.BSD в данном контексте нежизнеспособно. Когда оно перестанет крашиться под сетевой нагрузкой, тогда и поговорим.
> BSD в данном контексте нежизнеспособно. Когда оно перестанет крашиться под сетевой нагрузкой,
> тогда и поговорим.и, конечно же, есть что показать в цифрах, в подтверждение, правда?;-)
> и, конечно же, есть что показать в цифрах, в подтверждение, правда?;-)go читать на наге, ни одного дельного совета, зато полно крашлогов
>> и, конечно же, есть что показать в цифрах, в подтверждение, правда?;-)
> go читать на наге, ни одного дельного совета, зато полно крашлогов
>> и, конечно же, есть что показать в цифрах, в подтверждение, правда?;-)
> go читать на наге, ни одного дельного совета, зато полно крашлоговДавайте поговорим, ибо я не видел, как оно крашится, хотя пользую BSD вместе с линуксом давно.
Коллега, знания, полученные на ЛОРе и НАГе объективными считать крайне сложно. Прошу оперировать своим опытом.
Если запускать BSD на домашнем ПК с сетью на 8319 то о надёжности разговаривать не приходится. Я BSD гоняю на HP, раньше было на Supermicro (говно еще то, но хотя бы серверное). В производительность TCP-стека упирался, а вот крашей под нагрузкой не видел ни разу. Видимо руки кривые - BSD ни разу не крашилась по нагрузке =)В линуксе мне не нравится, что нет одной простой операции - вывести количество соединений в backlog, что бы хотя бы понимать справляется ли софт с accept'ом соединений.
Еще в линуксе расстраивает отсутствие вменяемого CARP/VRRP/аналога. uCARP кривой и работает в userland.
Так что еще раз: кесарю - кесарево и любой софт надо уметь готовить, а не ссылаться на НАГ.
> Давайте поговорим, ибо я не видел, как оно крашится, хотя пользую BSD
> вместе с линуксом давно.Давайте. У вас есть хотя бы 4G/350Kpps сквозняком через железку?
> Коллега, знания, полученные на ЛОРе и НАГе объективными считать крайне сложно. Прошу
> оперировать своим опытом.Тут еще специфика: провайдерская эксплуатация. Во-первых это прогон трафика. Большого. Измеряемо петабайтами за срок менее полугода. Шейперы и прочее. Локально фактически не терминируется ничего - приходит трафик, инкапсулируется или декапсулируется PPPoE, шейпится, возможно NAT'ится, уходит. Постоянные поднятия-опускания интерфейсов, постоянные изменения правил шейпера и файрвола.
В данном случае опыт таков, что железки стоят под нагрузкой 24/7/365, и если оно грохнется - взвоет несколько тысяч абонентов, потому что все они получают интернет домой через эту железку. BSD на таких нагрузках не живет как при личном опыте, так и по опыту людей на наге.
В провайдере вообще лучше использовать что-то железное и более приспособленное, ну да не всегда экономически оправдано.
Мой опыт с BSD только до 1G/200kpps с терминацией трафика на BSD либо на nginx, либо на mpd. Mpd во фре до стабилизации accel_ppp в линухе давал хороший выигрыш по пропускной способности - из опыта построения VPDN-сервиса.Но мы-то сейчас об nginx говорим, а FreeBSD для nginx - дом родной. А вкупе с ядреным carp - так вообще неплохое решение для первичного приёма трафика.
> go читать на наге, ни одного дельного совета, зато полно крашлоговИ в списке рассылки нжинкса так же. Если перец с крахом/взвисом системы в сети или ФС - это почти наверняка bsdшник.
> можно пытаться натянуть презерватив на глобус^W^W^Wнекие патчи на некие ядра,Вот только почему-то это приходится делать сугубо тигарам и изенам. А у остальных оно или и так работает, или у них очень кастомная задача, под которую по любому придется, в любой ОС. Так что или расскажи что ты там такое уникальное патчишь, или признай что у тебя весенний гон.
http://hh.ru/ - nginx без всяких апачей...
> http://hh.ru/ - nginx без всяких апачей...вот это вот неплохой пример какбэ. очень даже. тут уже спорить не с чем. но вот насчет "без всяких апачей" всё равно можно посомневаться - откуда дровишки?
>> http://hh.ru/ - nginx без всяких апачей...
> вот это вот неплохой пример какбэ. очень даже. тут уже спорить не
> с чем. но вот насчет "без всяких апачей" всё равно можно
> посомневаться - откуда дровишки?Ну я как бэ кишочки http://hh.ru/ правил... Конфиги nginx видел и даже патчи для этих конфигов писал... ;)
>>> http://hh.ru/ - nginx без всяких апачей...
>> вот это вот неплохой пример какбэ. очень даже. тут уже спорить не
>> с чем. но вот насчет "без всяких апачей" всё равно можно
>> посомневаться - откуда дровишки?
> Ну я как бэ кишочки http://hh.ru/ правил... Конфиги nginx видел и даже
> патчи для этих конфигов писал... ;)ну тогда может не стоит скрывать факт что там nginx+java, чтобы уж совсем по-честному было? ;-)
> ну тогда может не стоит скрывать факт что там nginx+java, чтобы уж
> совсем по-честному было? ;-)Как это влияет на отсутствие апача, интересно? :)
>> ну тогда может не стоит скрывать факт что там nginx+java, чтобы уж
>> совсем по-честному было? ;-)
> Как это влияет на отсутствие апача, интересно? :)ну тут вопрос спорный, чтоже хуже, апач или жава;)
но а вообще да, про "без апача" я пропустил как-то;(
>>>> http://hh.ru/ - nginx без всяких апачей...
>>> вот это вот неплохой пример какбэ. очень даже. тут уже спорить не
>>> с чем. но вот насчет "без всяких апачей" всё равно можно
>>> посомневаться - откуда дровишки?
>> Ну я как бэ кишочки http://hh.ru/ правил... Конфиги nginx видел и даже
>> патчи для этих конфигов писал... ;)
> ну тогда может не стоит скрывать факт что там nginx+java, чтобы уж
> совсем по-честному было? ;-)Я могу сказать больше, всю динамику там вначале ловит Python, а Java там в самом конце pipeline.
Подробнее можно тут глянуть: https://github.com/hhru/frontik , это это tornado-based сервер для накладывания xslt на данные от бэкендов.
gdeetotdom.ru = nginx + php_fcgi (вопросы модности новых версий, php_fpm и всего прочего прошу не обсуждать, не по моей воле не дали сделать).
Посещаемость: http://www.liveinternet.ru/stat/ged/badoo.com = nginx + php_fpm (предлагаю самим найти прув авторства)
wordpress.org
wordpress.com
yandex.ru
> wordpress.org
> wordpress.com
> yandex.ruУ яндекса свой http-сервер, что характерно - проприетарный.
Вы с гуглом перепутали.
Не, не перепутал. Они используют в своих проектах nginx, lighthttpd, свой Phantom (можно нагуглить) и, насколько помню, ещё один, тож собственной разработки.
> Не, не перепутал. Они используют в своих проектах nginx, lighthttpd, свой Phantom
> (можно нагуглить) и, насколько помню, ещё один, тож собственной разработки.Так все-таки нжинкс используют же? В чем соврал оратор который до вас? :)
>> Не, не перепутал. Они используют в своих проектах nginx, lighthttpd, свой Phantom
>> (можно нагуглить) и, насколько помню, ещё один, тож собственной разработки.
> Так все-таки нжинкс используют же? В чем соврал оратор который до вас?
> :)Ни в чем, просто я уточнил.
Как раз под нагрузку и стоит. При вервой возможности от apache надо избавляться.
С какого перепуга? nginx+php выдержит намного большую нагрузку чем nginx+apache+php. И вообще apache только для .htaccess нужен. Другого применения для apache я не нашёл.
> Для небольшого локалхоста вполне годно. А вот под нагрузку такое ставить не стоит.Вам наверное нравятся его жирные воркеры оптом. Не, ну если повезло и кто-то проплатил 64-ядерный сервак с 256гигз оперативы - то и апач быстрый сервер и совсем не жрет ресурсы тогда :). А если ресурсы лимитированы - вот тут с апачем один гемор...
Превосходно работает и с пыхом, проблем не видел. Единственно для чего теперь держим апач на одном из серверов - работа с svn по http
> Единственно для чего теперь держим апач на одном из серверов - работа с svn по httpтакже можно скормить nginx-у
Хмм, есть что-то подобное mod_dav_svn для nginx? Что-то не могу нагуглить рабочего решенья
> Хмм, есть что-то подобное mod_dav_svn для nginx? Что-то не могу нагуглить рабочего
> решенья* http://github.com/arut/nginx-dav-ext-module нерабочее?
* дать денег сысоев фоундейшн?
>> Хмм, есть что-то подобное mod_dav_svn для nginx? Что-то не могу нагуглить рабочего
>> решенья
> * http://github.com/arut/nginx-dav-ext-module нерабочее?* Оно не для того.
> * дать денег сысоев фоундейшн?* Зачем, если есть mod_dav_svn ? Я запускаю для него отдельный апачик и проксирую.
>> * дать денег сысоев фоундейшн?
> * Зачем, если есть mod_dav_svn ? Я запускаю для него отдельный апачик и проксирую.Ну, в общем-то незачем. Больше самообразовательный поиск пределов конкретного инструмента (пока четра на песке тут: не может .htaccess / шаред хостинг и WebDAV для SVN). //Ну, и конечно, потролить чуток, как же без. (Интересно, а git %))) не R/O по http умеет, и нужен ли ему для этого именно-таки апач?)
>>> * дать денег сысоев фоундейшн?
>> * Зачем, если есть mod_dav_svn ? Я запускаю для него отдельный апачик и проксирую.
> Ну, в общем-то незачем. Больше самообразовательный поиск пределов конкретного инструмента
> (пока четра на песке тут: не может .htaccess / шаред хостинг
> и WebDAV для SVN). //Ну, и конечно, потролить чуток, как же
> без. (Интересно, а git %))) не R/O по http умеет, и
> нужен ли ему для этого именно-таки апач?)нет, git работает чисто по WebDAV, и в случае апача используется mod_dav_fs.
Вот в случае использования указанного выше модуля nginx (который реализует недостающие DAV-методы), наверное можно запустить доступ к git-репозитарию средствами nginx.
Другое дело, что в случае git, например, я не знаю способа разделить доступ пользователей к веткам, например. AFAIK, это by-design так.
> Вот в случае использования указанного выше модуля nginx (который реализует недостающие
> DAV-методы), наверное можно запустить доступ к git-репозитарию средствами nginx.
> Другое дело, что в случае git, например, я не знаю способа разделить
> доступ пользователей к веткам, например. AFAIK, это by-design так.Скорее не by-desing, а просто сделано только то, что было нужно для решения конкретных задач. Игорь знает о нехватке различного функционала в WebDAV, но на когда в плане стоит исправление я не спрашивал, ибо лично мне WebDAV ни разу не был нужен в последнее время.
Потому, что нормальные люди имеют доступ к git'у по ssh, а в качестве контроля доступа используют gitosis или gitolite
>> Единственно для чего теперь держим апач на одном из серверов - работа с svn по http
> также можно скормить nginx-уа вот и нет.
>> Существуют ли сайты, где nginx главный и единственный движок (без Apache),
>> а не FrontEnd? И если уже совсем обнаглеть: существуют ли nginx-only-based CMS?
> Если не считать пых, то почти все остальные сайты на nginx превосходно
> обходятся без apache.Пых в первую очередь прекрасно обходится без апача. Это уже сильно позже появилась поддержка UWSGI/SCGI для руби и питона.
>>> Существуют ли сайты, где nginx главный и единственный движок (без Apache),
>>> а не FrontEnd? И если уже совсем обнаглеть: существуют ли nginx-only-based CMS?
>> Если не считать пых, то почти все остальные сайты на nginx превосходно
>> обходятся без apache.
> Пых в первую очередь прекрасно обходится без апача. Это уже сильно позже
> появилась поддержка UWSGI/SCGI для руби и питона.Вот не надо, FastCGI в nginx давно, и нормальная поддержка для него в Python и Ruby появилась куда раньше, чем в PHP.
А uWSGI да, появился поздно... я месяц Игорю Сысоеву на мозги капал при каждом удобном случее, чтобы он принял их модуль в основную ветку... мне даже немного стыдно, но уж очень надо было для одного проекта тогда! :(
Но uWSGI вообще появился поздно, а вот flup (наверное до сих пор самая популярная реализация FastCGI) уже очень давно существует.
> Вот не надо, FastCGI в nginx давно, и нормальная поддержка для него
> в Python и Ruby появилась куда раньше, чем в PHP.Чего не надо-то? =)) Читайте полный тред. Я о том и говорю, что всё это давно уже работает.
>> Вот не надо, FastCGI в nginx давно, и нормальная поддержка для него
>> в Python и Ruby появилась куда раньше, чем в PHP.
> Чего не надо-то? =)) Читайте полный тред. Я о том и говорю,
> что всё это давно уже работает.Не, вы написали, что пых в ПЕРВУЮ очередь, а на самом деле в нём нормальный FastCGI появился наверное последним... Впрочем стоит признать, что mod_php, для своего времени, работал очень даже неплохо! :)
>>> Вот не надо, FastCGI в nginx давно, и нормальная поддержка для него
>>> в Python и Ruby появилась куда раньше, чем в PHP.
>> Чего не надо-то? =)) Читайте полный тред. Я о том и говорю,
>> что всё это давно уже работает.
> Не, вы написали, что пых в ПЕРВУЮ очередь, а на самом деле
> в нём нормальный FastCGI появился наверное последним... Впрочем стоит признать, что
> mod_php, для своего времени, работал очень даже неплохо! :)Ммм. Я FastCgi юзаю где-то с 0.6, если мне память не изменяет.
В любом случае это было в 2006 или 2007 году - давно уже.
> Существуют ли сайты, где nginx главный и единственный движок (без Apache),
> а не FrontEnd? И если уже совсем обнаглеть: существуют ли nginx-only-based CMS?* dpkg -l | grep nginx
ii nginx-common 1.1.17-2~bpo60+1 small, but very powerful and efficient web server (common files)
ii nginx-full 1.1.17-2~bpo60+1 nginx web server with full set of core modules
* dpkg -l | grep php
* dpkg -l | grep apache
ii apache2-utils 2.2.16-6+squeeze6 utility programs for webservers
>Существуют ли сайты, где nginx главный и единственный движок (без Apache), а не FrontEnd?У меня несколько штук на lighttpd
> У меня несколько штук на lighttpdУ него есть ряд дурных свойств в плане проксирования/реакции на runaway скрипта когла тот пошел вразнос и генерит большую портянку. В этом случае лайти, целиком буферизующий запрос в памяти, может выжрать нетривиальный объем оперативы. И что хуже - потом он ее не отдаст.
По факту - нет, должен быть обработчик кода. FastCGI, UWSGI, SCGI.
Зачастую вместо apache/mod_php используется nginx + php-fpm.
php-fpm - облегченный fastcgi-обработчик php. Проще и производительнее апача.
nginx хорош своей архитектурой FSM, которая позволяет обрабатывать очень много соединений одним процессом, гибкостью конфигурации и богатым функционалом по предварительному разбору запросов. FreeBSD 8.1/nginx с легкостью выдерживал DDOSы под гигабит, отдавая 500 на специфичный для бота запрос.
Я вот например работаю уже 6 лет в эксплуатации различных онлайн сервисов и ни разу не встречал апача в production. Только nginx либо более узкоспециализированные балансировщики.
> Существуют ли сайты, где nginx главный и единственный движок (без Apache)Да. Превеликое множество.
> существуют ли nginx-only-based CMS
не слышал. и в принципе если нет завязки на нгинкс-специфик модули то собственно это прото вебсервер с php.
Любой сайт на php работает без apache. Другое дело, что шаред хостинга нет на чистом nginx.
> Любой сайт на php работает без apache. Другое дело, что шаред хостинга
> нет на чистом nginx.Делается, кстати, на раз... я делал пару раз под заказ подобные решения, для внутреннего использования.
Продавать это массам конечно нельзя, но только потому что служба поддержки сколлапсирует под тысячями запросов вроде "а почему у меня .htaccess не работает? ну и что, что вы не заявляете его поддержку! мне на всё плевать, делайте чтобы работало, я вам 3 доллара заплатил, уроды!"
А технически делается даже немного проще чем на апаче - формат конфига проще на мой взгляд.
>> Любой сайт на php работает без apache. Другое дело, что шаред хостинга
>> нет на чистом nginx.
> Делается, кстати, на раз... я делал пару раз под заказ подобные решения,
> для внутреннего использования.
> Продавать это массам конечно нельзя, но только потому что служба поддержки сколлапсирует
> под тысячями запросов вроде "а почему у меня .htaccess не работает?
> ну и что, что вы не заявляете его поддержку! мне на
> всё плевать, делайте чтобы работало, я вам 3 доллара заплатил, уроды!"
> А технически делается даже немного проще чем на апаче - формат конфига
> проще на мой взгляд.Вживую видел shared-хостинг на nginx и скрипт для парсинга .htaccess
Криво, но работало =)
> А технически делается даже немного проще чем на апаче - формат конфига
> проще на мой взгляд.Как по мне - так значительно проще и более читаемый.
>> А технически делается даже немного проще чем на апаче - формат конфига
>> проще на мой взгляд.
> Как по мне - так значительно проще и более читаемый.А для организации шаред-хостинга куда важнее не читаемость, а писуемость! ;)
> А для организации шаред-хостинга куда важнее не читаемость, а писуемость! ;)Для организации шаред хостинга лучше всего пойти и застрелиться чтоб не засирать уже мир этими помойками - рассадниками хакерья и геморроя для вебдевов.
> Существуют ли сайты, где nginx главный и единственный движок (без Apache),
> а не FrontEnd?Полно. И точно существуют, мои тоже потихоньку перебираются на такую конфигурацию.
> И если уже совсем обнаглеть: существуют ли nginx-only-based CMS?
Зачем бы, httpd ведь разные на местности бывают... под рукой ChiliProject на nginx+unicorn и TYPO3 на nginx+php-fpm вполне себя комфортно чувствуют.
В качестве localhosta использую Cherokee и тоже очн доволен
> [proxy/fastcgi/scgi/uwsgi]Он как не хотел из "каропки" поддерживать WSGI так и не хочет. А я как пользую fastcgi+supervisor не переходя на uwsgi так и пользую. Каждый при своем короч... Но! Абыдна, однако!
> nginx используется на 12.76%Нуканешна. А позади него стоит старый добрый Апач.
> Нуканешна. А позади него стоит старый добрый Апач.Нахрена? Вас прикалывает админить 2 сервака вместо 1? Сомнительно что много админов разделяют ваш оптимизм по этому поводу :)
>> Нуканешна. А позади него стоит старый добрый Апач.
> Нахрена? Вас прикалывает админить 2 сервака вместо 1? Сомнительно что много админов
> разделяют ваш оптимизм по этому поводу :)Не, я много таких консерваторов видел.
Как правило из-за того, что не осиливают переписать mod_rewrit'овые правила для ngx_rewriteКстати, среди проектов Apache же есть отличный балансер. Странно, что его мало кто использует. Я, впрочем, тоже не щупал. Кто нибудь что нибудь про него знает?
> Кстати, среди проектов Apache же есть отличный балансер.А нжинкс как бы вполне себе сервер+прокси а не только балансер... наверное поэтому никто и не прется от идеи юзать апачевское добро. Вы как предпочитаете, админить 1 софтину или несколько? Ответ очевиден!
>> Кстати, среди проектов Apache же есть отличный балансер.
> А нжинкс как бы вполне себе сервер+прокси а не только балансер... наверное
> поэтому никто и не прется от идеи юзать апачевское добро. Вы
> как предпочитаете, админить 1 софтину или несколько? Ответ очевиден!не прутся, но альтернативы нет.
говорят же - для одиночных проектов nginx без вариантов, а на массовом хостинге - апач ещё как нужен, хоть где-то ибо .htaccess nginx не умеет, а он сильно юзерам нужен.
>>> Кстати, среди проектов Apache же есть отличный балансер.
>> А нжинкс как бы вполне себе сервер+прокси а не только балансер... наверное
>> поэтому никто и не прется от идеи юзать апачевское добро. Вы
>> как предпочитаете, админить 1 софтину или несколько? Ответ очевиден!
> не прутся, но альтернативы нет.
> говорят же - для одиночных проектов nginx без вариантов, а на массовом
> хостинге - апач ещё как нужен, хоть где-то ибо .htaccess nginx
> не умеет, а он сильно юзерам нужен.у меня есть видос где сысоев горит .htaccess не будет. и это правильно он должен быть лёгкий
твой любимый полный сервак досят медленные соединнения и поставив nginx перед - проблема возможно решиться.
> хостинге - апач ещё как нужен, хоть где-то ибо .htaccess nginx
> не умеет, а он сильно юзерам нужен.Особенно смешно выглядит когда Вася и Петя что-то не поделили а заодно падает или взламывается еще пяток крЮтых корпоративных сайтов которые виноваты только тем что их угораздило валяться в том же общественном туалете.
Админю небольшой shared хостинг. Приходится использовать связку Apache+Nginx именно из-за htaccess. Городить огород с интерпретатором даже и в голову не приходило - получить рутовую дыру таким образом проще простого.
Для проектных серверов да, проще использовать nginx only.
у тебя че за система на хосте? МАК если возмозно ну ли как там у линуксойдов похожее. апач выкинешь.
У вас там какой мак? Опийный чтоли? O_O