форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Релиз http-сервера nginx 1.2.0"	+/–
Сообщение от opennews (??) on 24-Апр-12, 00:24
После 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.dev/opennews/art.shtml?num=33286) десятипроцентный рубеж и вытеснил (http://www.opennet.dev/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.dev/opennews/art.shtml?num=33668
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Релиз http-сервера nginx 1.2.0"	+/–
Сообщение от Аноним (??) on 24-Апр-12, 00:24
Обновил порты на Фряшечке, спасибо :) Ну как там обычно говорят любители Генты и Арча: ждем ебилдов!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	37. "Релиз http-сервера nginx 1.2.0"	+2 +/–
	Сообщение от 1 (??) on 24-Апр-12, 10:45
	в арче никогда не ждут ебилдов
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	44. "Релиз http-сервера nginx 1.2.0"	–1 +/–
	Сообщение от Mephisto (??) on 24-Апр-12, 11:24
	В арче в тестинге уже прилетело :3
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	73. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Аноним (??) on 24-Апр-12, 23:18
	ментально здоровый человек должен сторонится фразы про ебилды. это уже ни разу не смешно и уже всем надоело.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	79. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Аноним (??) on 24-Апр-12, 23:54
	> ментально здоровый человек должен сторонится фразы про ебилды. Это фрибсдшник, сэр. Найти ментально здорового среди них - что-то типа поиска верблюда в антарктиде.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	81. "Релиз http-сервера nginx 1.2.0"	–1 +/–
	Сообщение от Аноним (??) on 25-Апр-12, 00:11
	> ментально здоровый человек должен сторонится фразы про ебилды. > это уже ни разу не смешно и уже всем надоело. Если кто-то кажется нездоровым вам, это еще не значит, что они действительно нездоровы. Факт вашего вашего собственного здоровья пока еще тоже не установлен. Хотя вполне понятно, что вам не смешно и надоело знать, что существуют какие-то вещи, недоступные и непонятные вам. Вот вам и приходится утешать себя мыслями о нездоровье людей, которые умеют извлекать пользу из вещей, недоступных для вас.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	92. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 02:29
	> Если кто-то кажется нездоровым вам, это еще не значит, что они действительно нездоровы. Да, когда тебе прилетит в продакшн что-то типа "Директива limit_zone заменена директивой limit_conn_zone с новым синтаксисом" и все нагнется если ты этим пользовался - вот тут мы и посмотрим кто будет здоров а кто нет. Вот глядя на подобные ченжлоги и понимаешь что политика дебиана/редхата/etc по удержанию версии пакета до выпуска очередной системы не так уж и плоха. Потому что есть авторы которые вот в таком стиле полностью кладут на обратную совместимость и можно поймать некислый факап.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	93. "Релиз http-сервера nginx 1.2.0"	+4 +/–
	Сообщение от oxyum (ok) on 25-Апр-12, 02:53
	>> Если кто-то кажется нездоровым вам, это еще не значит, что они действительно нездоровы. > Да, когда тебе прилетит в продакшн что-то типа "Директива limit_zone заменена директивой > limit_conn_zone с новым синтаксисом" и все нагнется если ты этим пользовался > - вот тут мы и посмотрим кто будет здоров а кто > нет. > Вот глядя на подобные ченжлоги и понимаешь что политика дебиана/редхата/etc по удержанию > версии пакета до выпуска очередной системы не так уж и плоха. > Потому что есть авторы которые вот в таком стиле полностью кладут > на обратную совместимость и можно поймать некислый факап. Нет, тут дело не в авторах, а в том, что у нас слишком много "админов локалхоста" пытаются админить сервера и не понимают, что пора использовать другие подходы и инструменты... А вот те, кто делают политику обновления для RHEL и других серверных продуктов это уже понимают, и им, например, не мешает выход новых версий ничем - раз в N лет можно затеять обновление формата конфигов даже на тысячах серверов.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	117. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 11:11
	> А вот те, кто делают политику обновления для RHEL и других серверных > продуктов это уже понимают, и им, например, не мешает выход новых версий ничем Капитан, это вы?! :)
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	95. "Релиз http-сервера nginx 1.2.0"	–1 +/–
	Сообщение от Аноним (??) on 25-Апр-12, 03:02
	> Да, когда тебе прилетит в продакшн что-то типа "Директива limit_zone заменена директивой limit_conn_zone с новым синтаксисом" и все нагнется если ты этим пользовался - вот тут мы и посмотрим кто будет здоров а кто нет. То есть у вас возник какой-то баг, который вы не осилили сами исправить, и к тому же написать баг-репорт вам религия не позволяет. И из всего этого вы сделали все дальнейшие выводы. > Вот глядя на подобные ченжлоги и понимаешь что политика дебиана/редхата/etc по удержанию версии пакета до выпуска очередной системы не так уж и плоха. Потому что есть авторы которые вот в таком стиле полностью кладут на обратную совместимость и можно поймать некислый факап. Надо полагать, именно так вы понимаете принципиальное отличие "дебиана/редхата/etc" от систем, которые вы ненавидите, и которые опять-таки отождествляете в кучу между собой исключительно на основе вашей ненависти ко всему, в чем вы не способны разобраться. И видимо вы убеждены, что именно указанная вами "политика" гарантирует отсутствие багов. При этом вы эту "политику" даже грамотно сформулировать не можете. И тем более вам невдомек, что "база" BSD-систем как раз таки этой самой политики и придерживается. И наоборот, некоторые дистры на основе "дебиана/редхата/etc" от этой политики отказываются.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	97. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Michael Shigorin (ok) on 25-Апр-12, 03:14
	> То есть у вас возник какой-то баг, который вы не осилили сами > исправить, и к тому же написать баг-репорт вам религия не позволяет. Кгм, это не баг, а сознательная разница в подходах.  Одни предпочитают "тухлое, но не беспокоиться", другие начинают подпрыгивать, если пошёл третий час с момента выпуска новой версии, а её "всё нет". [skip]
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	122. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 11:30
	> То есть у вас возник какой-то баг, который вы не осилили сами > исправить, и к тому же написать баг-репорт вам религия не позволяет. > И из всего этого вы сделали все дальнейшие выводы. То-есть, автор сознательно изменил формат конфига и это не баг а фича. А вот если вкатить такую версию поверх старой, оно вполне может вполне ожидаемо нагнуться. Что означает что мало того что апдейт нельзя втулить автоматически (что для автопилотных систем не всегда хорошо) так еще и потребуется переделка конфига. > Надо полагать, именно так вы понимаете принципиальное отличие "дебиана/редхата/etc" от > систем, которые вы ненавидите, и которые опять-таки отождествляете в кучу Я не "ненавижу" а различаю системы которые больше заточены "чтоб работало в боевых условиях" и "чтоб админ фигней мог пострадать". Политика апдейтов первых выработалась как раз за счет существования таких авторов (автор нжинкса далеко не единственный кто так делает, просто очень характерный представитель). > между собой исключительно на основе вашей ненависти ко всему, в чем вы не способны разобраться. Ну если вы опериуете такими идиотскими критериями, позволю себе немного глума в ответ: а вы знаете, у меня нет самоцели разрулить вообще все грабли всех систем лично, доказать всем какой я крутой мачо и разобраться в "именно вон той" системе, потому что видите ли для реал мачо только это - труЪ (так сосед Вася сказал!). > И видимо вы убеждены, что именно указанная вами "политика" гарантирует отсутствие багов. Она гарантирует отсутствие вышеупомянутых факапов. А вы лишний раз показали что настолько пионер что даже не в состоянии осознать прочитанное при печати ответа. FAIL засчитан. А потом вы еще и удивляетесь вашей пионерской репутации. Нормально. > более вам невдомек, что "база" BSD-систем как раз таки этой самой > политики и придерживается. Какое мне дело до какой-то там базы? Или софт который в базе - ломать нельзя, а который не в базе - можно? > И наоборот, некоторые дистры на основе "дебиана/редхата/etc" от этой политики отказываются. И много вы их видели на серверах? :)
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	133. "Релиз http-сервера nginx 1.2.0"	–1 +/–
	Сообщение от AlexAT (ok) on 25-Апр-12, 11:46
	Именно. Софт, который непредсказуемо ломает структуру конфига при обновлении даже в минорах, да еще без детальных release notes - в принципе трудно юзабелен.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	144. "Релиз http-сервера nginx 1.2.0"	+2 +/–
	Сообщение от oxyum (ok) on 25-Апр-12, 12:43
	> Именно. Софт, который непредсказуемо ломает структуру конфига при обновлении даже в минорах, > да еще без детальных release notes - в принципе трудно юзабелен. http://nginx.org/ru/CHANGES.ru-1.2 Даже на русском!
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	152. "Релиз http-сервера nginx 1.2.0"	+1 +/–
	Сообщение от Michael Shigorin (ok) on 25-Апр-12, 13:34
	> Именно. Софт, который непредсказуемо ломает структуру конфига Угу, как в apache2 дорвавшиеся студенты молча ломали семантику API (время запроса) -- так это было предсказуемо... про последовавший вал дыреней в 2.0.x и одержимое пихание этого сырого хлама в дистрибутивы я как тогда майнтейнер apache-1.3 в альте просто молчу, держал его до последнего.  До 2.2 второй апач для production попросту не подходил.
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	156. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от AlexAT (ok) on 25-Апр-12, 17:12
	Apache 1 и Apache 2 - это примерно как пятерка VS Audi A6...
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	153. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Michael Shigorin (ok) on 25-Апр-12, 13:39
	> Что означает что мало того что апдейт нельзя втулить автоматически (что для > автопилотных систем не всегда хорошо) так еще и потребуется переделка конфига. Дополню: "автопилотные системы" не бегают по сайтам апстримов каждые три минуты в поисках, чего бы пособирать -- потому как у вменяемых админов автообновления производятся из мест, в которых несовместимые обратно изменения являются ЧП.  Будь это "вечнотухлая" ветка или свой контролируемый репозиторий "вечнонетухлой", куда изменения пропускаются после стендовых испытаний (обновляемость, функциональность, нагрузочная способность).
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	116. "Релиз http-сервера nginx 1.2.0"	+1 +/–
	Сообщение от тигар (ok) on 25-Апр-12, 10:52
	>> Если кто-то кажется нездоровым вам, это еще не значит, что они действительно нездоровы. > Да, когда тебе прилетит в продакшн что-то типа "Директива limit_zone заменена директивой > limit_conn_zone с новым синтаксисом" и все нагнется если ты этим пользовался > - вот тут мы и посмотрим кто будет здоров а кто > нет. а вот это проблема исключительно тех, кто считает плюсом обновление ПО по cron ;)
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	124. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 11:36
	> а вот это проблема исключительно тех, кто считает плюсом обновление ПО по cron ;) "...вкалывают роботы, а не человек".
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	137. "Релиз http-сервера nginx 1.2.0"	+1 +/–
	Сообщение от тигар (ok) on 25-Апр-12, 11:51
	>> а вот это проблема исключительно тех, кто считает плюсом обновление ПО по cron ;) > "...вкалывают роботы, а не человек". ну т.е. роботы будут читать changelog`и у обновляторов кроном? я, чесно говоря, сомневаюсь.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	162. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 20:30
	> ну т.е. роботы будут читать changelog`и у обновляторов кроном? я, чесно говоря, сомневаюсь. Так в том то и фикус что в нормальном дистре можно просто вкатить апдейт. Там будут секурити фиксы и может быть бэкпорты НЕ ЛОМАЮЩИХ ВСЕ изменений. Читают человеки - майнтайнеры. А вкалывают роботы. Это хорошо.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	165. "Релиз http-сервера nginx 1.2.0"	+1 +/–
	Сообщение от oxyum (ok) on 25-Апр-12, 22:30
	>> ну т.е. роботы будут читать changelog`и у обновляторов кроном? я, чесно говоря, сомневаюсь. > Так в том то и фикус что в нормальном дистре можно просто > вкатить апдейт. Там будут секурити фиксы и может быть бэкпорты НЕ > ЛОМАЮЩИХ ВСЕ изменений. Читают человеки - майнтайнеры. А вкалывают роботы. Это > хорошо. ВЕРОЯТНЕЕ всего не ломающих ВАШУ конфигурацию... любой грамотный админ крупной площадки, ВСЕ обновления ВСЕГДА проверяет вручную на СВОЕЙ конфигурации! Более того, даже в дистрах вроде RHEL возможны обновления ЛОМАЮЩИЕ совместимость, если это необходимо для security-fix.
	Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

	177. "Релиз http-сервера nginx 1.2.0"	–1 +/–
	Сообщение от vle (ok) on 26-Апр-12, 16:44
	> обновления ЛОМАЮЩИЕ совместимость, если > это необходимо для security-fix. Так не бывает.
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	181. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от oxyum (ok) on 26-Апр-12, 18:53
	>> обновления ЛОМАЮЩИЕ совместимость, если >> это необходимо для security-fix. > Так не бывает. Чо, правда?! А я и не знал...
	Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

	190. "Релиз http-сервера nginx 1.2.0"	+1 +/–
	Сообщение от Аноним (??) on 27-Апр-12, 03:09
	> если это необходимо для security-fix. Бывает с примерно такой же частотой как падение метеоритов на головы граждан. Давайте все дружно жить в подземных бункерах? Заметьте, здесь не утверждается что эти бункера совсем никому не требуются :)
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	183. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Arti (??) on 26-Апр-12, 23:02
	не я понял бы написал порт обновил. ото обсуждаем у кого мантенер круче.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Релиз http-сервера nginx 1.2.0"	+2 +/–
Сообщение от zuborg on 24-Апр-12, 00:33
Развитие nginx и не думает замедляться - это радует ;) Глядишь, в 1.3 уже будет поддержка spdy, тогда он будет просто вне конкуренции ;)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	27. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Hugo Reyes (ok) on 24-Апр-12, 10:09
	SPDY обещалось в мае. 1.3.0 выйдет в мае?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	43. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от vovans (ok) on 24-Апр-12, 11:08
	выйдет
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	49. "Релиз http-сервера nginx 1.2.0"	+1 +/–
	Сообщение от Andrey Mitrofanov on 24-Апр-12, 14:22
	> Глядишь, в 1.3 уже будет поддержка spdy, тогда он будет просто А в 1.3.52 добавят эмуляцию апача... А в 1.3.99 число модулей превысит число апачевских... А в 2.1.199 размер кода превысит, и дистрибутивы заменят устаревший апач пакетом apache-compat-server-nginx... Ближе к релизу 2.4 на энжиникс фоундейшн будут сбрасывать платиновую помощь майкрософты и ненужные завалы опенсорса прочие карпорасты... Дети начнут спрашивать, "папа, а кто такой апаче хатэтэпэдэ?!"...
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	69. "Релиз http-сервера nginx 1.2.0"	+1 +/–
	Сообщение от Аноним (??) on 24-Апр-12, 23:01
	> А в 1.3.52 добавят эмуляцию апача... Будет так же жрать ресурсы, тормозить и форкать процессы? oO
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	90. "Релиз http-сервера nginx 1.2.0"	–1 +/–
	Сообщение от user455 on 25-Апр-12, 01:39
	форкает апач процессы или работает с мультитредной моделью зависит от используемого мпм. но большинство-в-интернете(тм) об этом не знает.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	99. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 06:11
	> форкает апач процессы или работает с мультитредной моделью О да, конечно, если вместо форка на соединение станет старт треда на соединение - какашка станет на целых три попугая вкуснее. А общая дефективность такой модели никуда не денется - такое в общем случае может положить школьник на диалапе. А отсутствие дуракозащищенности в этом суровом мире - хреново, да. А нжинкс - фиг завалишь, по крайней мере на статике... :)
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	114. "Релиз http-сервера nginx 1.2.0"	–2 +/–
	Сообщение от user455 on 25-Апр-12, 10:42
	ерунду какую-то говоришь
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	125. "Релиз http-сервера nginx 1.2.0"	+1 +/–
	Сообщение от Аноним (??) on 25-Апр-12, 11:36
	> ерунду какую-то говоришь Как аргументировано.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	184. "Релиз http-сервера nginx 1.2.0"	–1 +/–
	Сообщение от Arti (??) on 26-Апр-12, 23:10
	>> форкает апач процессы или работает с мультитредной моделью > О да, конечно, если вместо форка на соединение станет старт треда на в жизне не делал системы на "неразрывный конект на бесконечной скорости" все делаем под задачу если лишний мег надо воткнуть и поставить апач - легко. у меня нет религиозных предрассутков - кроме энзиникса низачто ничего не поставлю. ну конечно когда надо сделать на том что есть или мапят просто некуда вставить - делаем спецрешение.
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	188. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Michael Shigorin (ok) on 27-Апр-12, 00:50
	> если лишний мег надо воткнуть и поставить апач - легко. у меня нет религиозных Да уж... Лишний гиг тоже может не выручить.  Когда по совету народа с mozilla.ru посмотрел внимательней на nginx хотя бы в качестве фронтэнда, потребление памяти/нагрузочная способность и впрямь улучшились примерно в десять раз.  И это относительно первого апача.
	Ответить | Правка | ^ к родителю #184 | Наверх | Cообщить модератору

	197. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от AlexAT (ok) on 27-Апр-12, 08:06
	> потребление > памяти/нагрузочная способность и впрямь улучшились примерно в десять раз.  И > это относительно первого апача. Первый апач... ну что за некрофилия? Я не сомневаюсь, что nginx ведет себя куда лучше первого апача, но вот со вторым, а тем паче - с 2.4, уже надо сравнивать пристальнее, с оглядкой на разницу в функционале. Ну и да - если прикручиваете допустим PHP-FPM - будьте добры еще на него внимание обращать при расчёте нагрузки.
	Ответить | Правка | ^ к родителю #188 | Наверх | Cообщить модератору

	209. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Michael Shigorin (ok) on 28-Апр-12, 02:38
	>> потребление памяти/нагрузочная способность и впрямь улучшились примерно в десять раз. >> И это относительно первого апача. > Первый апач... ну что за некрофилия? На дворе были 1.3 и 2.0.  Первый со своими задачами (в т.ч. разумным расходам времени на поддержку) скорее справлялся, тогдашний второй -- категорически нет (игры в дыркофикс недели разумным расходом времени не считаю).  Разумеется, смотреть нужно с бэкендом -- тогда им тот первый апач с каким mod_php или mod_perl и продолжил работать.
	Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

	211. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от AlexAT (ok) on 28-Апр-12, 09:34
	> На дворе были 1.3 и 2.0. Тогда, когда на дворе были только 1.3 и младшие 2.0, nginx был вообще неюзабелен - проще было допилить 2.0, чем пытаться завести сабж. Именно тогда было принято решение это поделие не юзать, в силу абсолютнейшей падучести оного при любом чихе. Подход nginx/FSM определенно хорош, за исключением одной мелочи. Если падает апач в префорке/itk - падает 1 клиентский запрос. Если падает апач в воркере - падает пачка клиентских запросов. Если падает nginx в FSM - падает целиком. Поэтому использовать его на фронтенде можно лишь с минимумом функционала. А на бэкенд nginx ставить - FSM и прочее - это сокеты, годится разве что для мелких инсталляций. Ну и в те времена, о которых вы говорите - оно сыпалось очень часто. Поэтому и такая личная неприязнь к данному проекту. Сляпано на коленке потому что.
	Ответить | Правка | ^ к родителю #209 | Наверх | Cообщить модератору

	212. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Michael Shigorin (ok) on 28-Апр-12, 14:42
	>> На дворе были 1.3 и 2.0. > Тогда, когда на дворе были только 1.3 и младшие 2.0, nginx был > вообще неюзабелен Может, для Вас -- у меня nginx-0.1.x вполне справлялся со своими скромными задачами.  А смотреть на эти вроде как уже и не младшие apache 2.0.50+ без слёз всё так же не получалось.  Понимаю, что у нас с Вами разные предубеждения, но и не навязываю своё. > Ну и в те времена, о которых вы говорите - оно сыпалось очень часто. Интересу ради: двухэтажка с monit на бэкенды не? Ну и повторюсь: в те времена у меня 1.3 бэкендом и работал...
	Ответить | Правка | ^ к родителю #211 | Наверх | Cообщить модератору

	191. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Аноним (??) on 27-Апр-12, 03:11
	> в жизне не делал системы на "неразрывный конект на бесконечной скорости" все > делаем под задачу если лишний мег надо воткнуть и поставить апач - легко. А потом приходит школьник с GPRSом и спокойно кладет сайт с своего нетбука одной левой. Просто потому что наделать кучу соединений - много ресурсов не надо.
	Ответить | Правка | ^ к родителю #184 | Наверх | Cообщить модератору

	196. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от AlexAT (ok) on 27-Апр-12, 08:03
	> А потом приходит школьник с GPRSом и спокойно кладет сайт с своего > нетбука одной левой. Просто потому что наделать кучу соединений - много > ресурсов не надо. Про mod_evasive слегка слышали? Школьнику в случае наличия данного модуля не светит абсолютно ничего.
	Ответить | Правка | ^ к родителю #191 | Наверх | Cообщить модератору

	110. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Andrey Mitrofanov on 25-Апр-12, 10:04
	>жрать ресурсы, тормозить и форкать процессы? oO Только в проприертарном форке, проспонсированном Майкрософтом. И только на Уиндоуз-128.%)
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	148. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Алекс (??) on 25-Апр-12, 12:59
	> Только в проприертарном форке, проспонсированном Майкрософтом. И только на Уиндоуз-128.%) ? Оно везде так и от MPM зависит мало.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

3. "Релиз http-сервера nginx 1.2.0"	+/–
Сообщение от ILYA INDIGO (ok) on 24-Апр-12, 01:11
Глядишь и скоро ему apache для динамики будет уже не нужен.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от AlexAT (ok) on 24-Апр-12, 07:21
	Не получится. Архитектура не позволяет.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	13. "Релиз http-сервера nginx 1.2.0"	–1 +/–
	Сообщение от бедный буратино (ok) on 24-Апр-12, 07:37
	Ему он и не нужен. Он нужен пыхерам.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	54. "Релиз http-сервера nginx 1.2.0"	+2 +/–
	Сообщение от FSA (ok) on 24-Апр-12, 17:02
	Нафига? php-fpm, spawn-cgi... мало?
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	70. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Аноним (??) on 24-Апр-12, 23:03
	> Он нужен пыхерам. Упоролся? Пых давно цепляется через fastcgi и опач становится как-то ни к чему. А админить 2 сервака вместо 1 - не есть хорошо.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	76. "Релиз http-сервера nginx 1.2.0"	–1 +/–
	Сообщение от anonimous on 24-Апр-12, 23:29
	пыхерам просто без htaccess-ов никак(ну или проблематично)
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	80. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Аноним (??) on 24-Апр-12, 23:55
	> пыхерам просто без htaccess-ов никак Это кто придумал? Вон тот буратино? Ну у него и ник подходящий.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	96. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от бедный буратино (ok) on 25-Апр-12, 03:03
	>> Он нужен пыхерам. > Упоролся? Пых давно цепляется через fastcgi и опач становится как-то ни к > чему. А админить 2 сервака вместо 1 - не есть хорошо. Специально для пыхеров повторяю два раза - он нужен ТОЛЬКО пыхерам, а "не он нужен ВСЕМ пыхерам".
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	100. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 06:13
	> он нужен ТОЛЬКО пыхерам, А доказательства этого тезиса предоставить можно? Хотя с таким ником уместнее желать разве что замену на "сам себе злобный буратино" наверное :)
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	149. "Релиз http-сервера nginx 1.2.0"	–1 +/–
	Сообщение от Алекс (??) on 25-Апр-12, 13:05
	>> он нужен ТОЛЬКО пыхерам, > А доказательства этого тезиса предоставить можно? Хотя с таким ником уместнее желать > разве что замену на "сам себе злобный буратино" наверное :) Не позорьтесь. Даже я знаю когда (массово) используется .htaccess.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	163. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 21:28
	> Не позорьтесь. К себе примените. > Даже я знаю когда (массово) используется .htaccess. Если где-то что-то используется - это еще не значит что это единственный вариант. Хотя у борцунов с php дрочащих на очередной кульный ЯП у которого своих недостатков на трех пыхов хватит такая фигня никогда не смущала.
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	22. "Релиз http-сервера nginx 1.2.0"	+3 +/–
	Сообщение от Волька on 24-Апр-12, 09:14
	А нахера ему Апач для динамики? Сто лет как везде повыкидывал Апач.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	41. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Нету имени on 24-Апр-12, 10:59
	Уже сто лет как fpm SAPI нативное для пыхеров идёт в PHP. Работа через unix socket или сетевое соединени как FCGI.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	46. "Релиз http-сервера nginx 1.2.0"	+1 +/–
	Сообщение от kazh on 24-Апр-12, 12:31
	Мне идеец нужеть только для SVN_WEBDAV. Вся остальная динамика отправила индейца в пеший эротический поход.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	94. "Релиз http-сервера nginx 1.2.0"	+1 +/–
	Сообщение от Michael Shigorin (ok) on 25-Апр-12, 02:57
	> Глядишь и скоро ему apache для динамики будет уже не нужен. Вчерась запустил очередной apacheless VPS для ещё одного проекта.  На nginx.  С динамикой. :)
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	101. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 06:14
	> Вчерась запустил очередной apacheless VPS И правильно делал ведь - апач памяти жрет ну просто трындец. И надо или круто лимитировать число воркеров в ущерб возможности отгрузки или при малейшем нашествии на сервер все встанет колом.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	166. "Релиз http-сервера nginx 1.2.0"	–2 +/–
	Сообщение от Sw00p aka Jerom on 26-Апр-12, 00:07
	у апача есть незаменимая весчь которая в энджинксе появится бог знает когда - mod_security - если чО у мня апач стоит фронтом с секурным модулем и проксирует на энджинкс - и мифы про не производительность апача - идут лесом - прекрасно с нагрузкой справляется
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	167. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Stream on 26-Апр-12, 01:14
	> у апача есть незаменимая весчь которая в энджинксе появится бог знает когда > - mod_security - если чО у мня апач стоит фронтом с > секурным модулем и проксирует на энджинкс - и мифы про не > производительность апача - идут лесом - прекрасно с нагрузкой справляется И сколько твою домашнюю страничку человек в год посещает? Мама и ты?
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	175. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Sw00p aka Jerom on 26-Апр-12, 14:33
	>> у апача есть незаменимая весчь которая в энджинксе появится бог знает когда >> - mod_security - если чО у мня апач стоит фронтом с >> секурным модулем и проксирует на энджинкс - и мифы про не >> производительность апача - идут лесом - прекрасно с нагрузкой справляется > И сколько твою домашнюю страничку человек в год посещает? Мама и ты? када будешь держать 1К сайтов - узнаешь
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

	192. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Аноним (??) on 27-Апр-12, 03:12
	> када будешь держать 1К сайтов - узнаешь Если это 1К домашних страничек пупкинов, на которых по полтора визита в день - не больно то убедительно получается.
	Ответить | Правка | ^ к родителю #175 | Наверх | Cообщить модератору

	199. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Sw00p aka Jerom on 27-Апр-12, 14:00
	ага а для домашних страничек безопасность не нужна ? - да ладно )))))))))))))
	Ответить | Правка | ^ к родителю #192 | Наверх | Cообщить модератору

	200. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от AlexAT (ok) on 27-Апр-12, 18:40
	> ага а для домашних страничек безопасность не нужна ? - да ладно > ))))))))))))) Явно вырисовываются две позиции - людей, которые держат массу абонентов (провайдеры + хостеры), и "одиночек", которые занимаются одним ресурсом. Есть еще хайлоад, но, думается, у них позиция третья, и они сюда заходят редко.
	Ответить | Правка | ^ к родителю #199 | Наверх | Cообщить модератору

	203. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Sw00p aka Jerom on 27-Апр-12, 21:45
	а что по вашему значит хайлоад ? и что это за третья сторона ? то что они сюда не заходят - факт - они привыкли всё на деле проверять и узнавать и не нуждаются в рекомендациях тролей (вроде хабраюзеров) и популистов
	Ответить | Правка | ^ к родителю #200 | Наверх | Cообщить модератору

	201. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от AlexAT (ok) on 27-Апр-12, 18:41
	> Если это 1К домашних страничек пупкинов, на которых по полтора визита в > день - не больно то убедительно получается. Поинт в том, что под массовый сервис лично я бы nginx-only городить не рискнул. Максимум - на фронтенд, и то с оговорками. Под единоличный проект - вполне, там можно хоть на IIS собирать xD
	Ответить | Правка | ^ к родителю #192 | Наверх | Cообщить модератору

4. "Релиз http-сервера nginx 1.2.0"	–2 +/–
Сообщение от Sw00p aka Jerom on 24-Апр-12, 01:46
хорошо было бы если можно было юзать прокси кеш без proxy_pass
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	30. "Релиз http-сервера nginx 1.2.0"	+2 +/–
	Сообщение от Аноним (??) on 24-Апр-12, 10:24
	Это как? Что вы собираетесь кешировать, если не проксируемое?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	108. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Sw00p aka Jerom on 25-Апр-12, 09:58
	ну схема такая сначало в прокси пасе указываю сервер - потом через нджинкс собираю контент в кеш (агрессивно всё подряд) - делаю миррор (зеркало) сайта - а потом просто заменяю прокси пасс на несуществующий бекенд и говорю нджинксу чтобы использовал тока кеш думаю понятно
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	111. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Andrey Mitrofanov on 25-Апр-12, 10:07
	> думаю понятно Не-а. Может, тебе нужен генератор статики, а не динамо + прокси-кеш + костыли?
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	158. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Sw00p aka Jerom on 25-Апр-12, 17:36
	для особо тупых краулер -> local_nginx ---(проксирует на реальный сайт и сохраняет в кеше)----> web_site кеш держится довольно долго и кешируется всё подряд потом в local_nginx заменяем proxy_pass http://мёртвый адрес и всё - статический миррор сайта готов с сохранением всех URL
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	159. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Stream on 25-Апр-12, 18:36
	Про директиву proxy_store слышали?
	Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

	161. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Sw00p aka Jerom on 25-Апр-12, 19:35
	> Про директиву proxy_store слышали? ага - и энджинкс тянет контент оттуда если выпал бекенд ? даже proxy_cache_use_stale не помогает - а в случае с прокси кешом - всё норма ps: может proxy_store ещё сохраняет ответы от сервера - всякие перенаправления и нот фоунды ?
	Ответить | Правка | ^ к родителю #159 | Наверх | Cообщить модератору

	168. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Stream on 26-Апр-12, 01:24
	>> Про директиву proxy_store слышали? > ага - и энджинкс тянет контент оттуда если выпал бекенд ? Если руки из нужного места растут, то настроить можно как угодно. hint: error_page 502 =200 @stored; location @stored {   root ... } > даже proxy_cache_use_stale не помогает - а в случае с прокси кешом - всё норма И кто мешает использовать proxy_cache? Вы сами себе противоречите.
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

	174. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Sw00p aka Jerom on 26-Апр-12, 14:29
	>>error_page 502 =200 @stored; ага и запрос в два раза дольще будет выполняться - сначало оброботка ошибки а потом перенаправление на именнованный локейшен а када там нет контента вернёт нотфоунд >>И кто мешает использовать proxy_cache? читайте первый комент всё дело в том что нуно пихать фейковый несуществующий бекенд чтобы через proxy_cache_use_stale задействовать то что лежит в кеше.
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

	176. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Stream on 26-Апр-12, 14:59
	Так вы определитесь, что вам надо. Если сначала смотреть сохраненную версию, то: location / {    root /path/to/storage;    try_files $uri @backend; } location @backend {    root /path/to/storage;    proxy_pass ..;    proxy_store ..; } Ваш первый коммент и далее про некий фейковый бэкенд - это бредни какие-то. Вы сеошник что ли?
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	178. "Релиз http-сервера nginx 1.2.0"	–1 +/–
	Сообщение от Sw00p aka Jerom on 26-Апр-12, 17:51
	вас продолжать дальше кормить или наелись ? 100 раз уже повторяю - миррор сайта (по-русски - зеркало сайта) - а для чего он нуже это уже другой вопрос - вся суть в том чтобы зеркало сайта ничем не отличалось от реального какой там может быть бекенд ?
	Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

	202. "Релиз http-сервера nginx 1.2.0"	–1 +/–
	Сообщение от Stream on 27-Апр-12, 19:31
	Для этого есть специальные утилиты или вам нравится гвозди забивать микроскопом?
	Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

	204. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Sw00p aka Jerom on 27-Апр-12, 21:47
	> Для этого есть специальные утилиты или вам нравится гвозди забивать микроскопом? >>утилиты просветите пжалуста - они также как и реальный сайт на энджинксе будут держать нагрузку ? пс: для краулинга юзаю httrack если чО - есть ли есть альтернатива - буду рад, тока не предлагайте wget c параметром -r
	Ответить | Правка | ^ к родителю #202 | Наверх | Cообщить модератору

	109. "Релиз http-сервера nginx 1.2.0"	–2 +/–
	Сообщение от Sw00p aka Jerom on 25-Апр-12, 09:58
	> хорошо было бы если можно было юзать прокси кеш без proxy_pass за минус спасибо - сначало спросите для чего это нужно
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

5. "Релиз http-сервера nginx 1.2.0"	–4 +/–
Сообщение от h31 (ok) on 24-Апр-12, 02:42
Хех, недавно видел инструкцию по настройке веб-сервера (или вообще LAMP, не помню точно), где говорилось, что nginx - это _не_ веб-сервер, а ускорялка для Apache. Ага, прямо вот такими фразами. Хотя тут оба виноваты. Nginx нынче улучшает работу с бэкендами, а Apache - с фронтендами.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Релиз http-сервера nginx 1.2.0"	+7 +/–
	Сообщение от Stream on 24-Апр-12, 02:58
	Недавно видел в книжку, где говорилось, что детей аист приносит. Ага, прямо так и говорилось.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Вопрос дилетанта"	+/–
Сообщение от MadAdmin on 24-Апр-12, 06:28
Существуют ли сайты, где nginx главный и единственный движок (без Apache), а не FrontEnd? И если уже совсем обнаглеть: существуют ли nginx-only-based CMS?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "Вопрос дилетанта"	+1 +/–
	Сообщение от dalco (ok) on 24-Апр-12, 07:05
	У меня пара сайтов чисто на nginx без всяких апачей живет. В качестве движка Drupal. Все работает :) P.S. Посетителей на них не особо много, но с теми, кто таки заходит, сей конфиг справляется на ура.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	9. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 24-Апр-12, 07:08
	Конечно существуют, проблемы тут нет никакой.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	11. "Вопрос дилетанта"	–10 +/–
	Сообщение от AlexAT (ok) on 24-Апр-12, 07:22
	> Существуют ли сайты, где nginx главный и единственный движок (без Apache), > а не FrontEnd? И если уже совсем обнаглеть: существуют ли nginx-only-based CMS? Для небольшого локалхоста вполне годно. А вот под нагрузку такое ставить не стоит.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	12. "Вопрос дилетанта"	+11 +/–
	Сообщение от PavelR (ok) on 24-Апр-12, 07:26
	Выше был ответ дилетанта на вопрос дилетанта.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	24. "Вопрос дилетанта"	–4 +/–
	Сообщение от AlexAT (ok) on 24-Апр-12, 09:49
	> Выше был ответ дилетанта на вопрос дилетанта. success story в студию или трепло
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	25. "Вопрос дилетанта"	+/–
	Сообщение от PavelR (ok) on 24-Апр-12, 10:00
	Я не виноват что у вас что-то не получилось. Лучше, давайте вы ваши возникшие проблемы озвучите. А наша success-story - это nginx + php-fpm. Он, между прочим, фичастее чем mod_php в плане управления "долговыполняющимися" процессами.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	26. "Вопрос дилетанта"	+/–
	Сообщение от AlexAT (ok) on 24-Апр-12, 10:02
	> А наша success-story - это nginx + php-fpm. Он, между прочим, фичастее > чем mod_php в плане управления "долговыполняющимися" процессами. Нагрузка? 1000 посетителей в сутки? У нас особых проблем нет - Apache как на фронтенде (worker), так и на бэкенде (mpm-itk).
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	53. "Вопрос дилетанта"	+1 +/–
	Сообщение от Vaso Petrovich on 24-Апр-12, 15:02
	>Нагрузка? 1000 посетителей в сутки? 15к+ посетителей и 200к+ хитов в сутки, достаточная нагрузка? После отказа от апача, общая загрузка сервера заметно снизилась.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	59. "Вопрос дилетанта"	+/–
	Сообщение от Doh on 24-Апр-12, 17:51
	Ну, так, что бы "специалиста" расслабить (того, у которого nginx+fpm только одного посетителя в сутки выдерживает). Связка такая же - nginx+fpm, от 90 до 120к уников в сутки, хитов - 3-5 лямов. Как-то так, да. Учите матчасть.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	61. "Вопрос дилетанта"	+/–
	Сообщение от AlexAT (ok) on 24-Апр-12, 19:08
	> Ну, так, что бы "специалиста" расслабить (того, у которого nginx+fpm только одного > посетителя в сутки выдерживает). Связка такая же - nginx+fpm, от 90 > до 120к уников в сутки, хитов - 3-5 лямов. Как-то так, > да. Учите матчасть. А хостнейм? :)
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	193. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 27-Апр-12, 04:18
	> А хостнейм? :) Вы свои скажите, а мы посмотрим сколько посетителей опеннета умеют запускать "утилиты для бенчмарков и нагрузочного тестирования". Ну и заодно посмотрим насколько ваш апач крут :)
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	62. "Вопрос дилетанта"	+/–
	Сообщение от AlexAT (ok) on 24-Апр-12, 19:19
	я отстал от жизни и HTTP/1.1 в nginx уже сделали?
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	65. "Вопрос дилетанта"	+1 +/–
	Сообщение от AlexAT (ok) on 24-Апр-12, 19:26
	> я отстал от жизни и HTTP/1.1 в nginx уже сделали? Вижу, в 1.1 добавили chunked. Вопрос снят. Надо бы попробовать вернуться к этому серверу, смысл видимо есть.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	102. "Вопрос дилетанта"	+1 +/–
	Сообщение от Аноним (??) on 25-Апр-12, 06:18
	> смысл видимо есть. Лучше скажи какой смысл в этом неповоротливом древнем утюге? У apache все что ни проект - то монструозный и тормозной переросток для энтерпрайза, где меньше чем 16 ядер и 128 гигз - вообще не машина, типа. Не, в теории на машине с бесконечной оперативой и столько же процессорных ядер, апач бесконечно масштабируем и ни во что не упирается. На практике он почему-то имеет свойство дико жрать ресурсы, так что если на сервер приперся хабраэффект/слэшдотэффект/кактамего - начинается полный ахтунг.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	68. "Вопрос дилетанта"	+2 +/–
	Сообщение от rshadow (ok) on 24-Апр-12, 20:58
	1000 в сутки, в среднем, это один клик в 1,5 минуты =) С этим мой телефон справится, даже если туда апач поставить и мускул.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	164. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 21:44
	> У нас особых проблем нет - Apache как на фронтенде (worker), Проблемы начинаются когда школьник начитавшийся журнала "хакер" тыщщу конекций пускает для лулзов. При этом апач или выжирает все ресурсы на сервере, если лимиты не настроены и все дохнет к такой-то матери, или вредитель узурпирует всех воркеров на длительный срок выбрав лимиты, так что остальным воркеров почти не достается. Для юзера сие выглядит довольно однофигственно: он не обслужен и обламывается по таймауту. Результат? Все сайты с более-менее серьезной нагрузкой и/или подвергающиеся пакостям от пионерии очень быстро осознают что апач с воркерами в роли фронтэнда не лучше моей бабушки в роли балерины. А такие как вы понимают только когда им 10К конекций в лоб предъявят так что все нагибается.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	169. "Вопрос дилетанта"	+/–
	Сообщение от AlexAT (ok) on 26-Апр-12, 07:05
	> Результат? Все сайты с более-менее серьезной нагрузкой и/или подвергающиеся пакостям от > пионерии очень быстро осознают что апач с воркерами в роли фронтэнда > не лучше моей бабушки в роли балерины. А такие как вы > понимают только когда им 10К конекций в лоб предъявят так что > все нагибается. Для этого существуют превентивные меры еще на входе. К слову говоря, когда предъявят 10005000+ коннектов - загнётся любой сервер, вне зависимости от софта. Просто памяти не хватит. В случае кластера - умножайте на число хостов. Поэтому пионерия, расчитывающая, что nginx спасёт их от всех бед, обречена в любом случае.
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

	170. "Вопрос дилетанта"	+/–
	Сообщение от theDolphin on 26-Апр-12, 10:46
	Nginx расходует примерно 300 байт на одно соединение. Так что пионерия может спать спокойно.
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

	171. "Вопрос дилетанта"	+/–
	Сообщение от theDolphin on 26-Апр-12, 10:55
	> Nginx расходует примерно 300 байт на одно соединение. Так что пионерия может > спать спокойно. Еще разое, хоть в теме уже было. Nginx выдерживал ддосы до ширины канала, фильтруя трафик. Так что прекратите уже красноглазие, осваивайте лучше lighthttpd, nginx и haproxy. А уж если преданы Apache Foundation - то осваивайте Traffic Server, что по сути та-же хрень что и вышеупомянутые три продукта.
	Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

	194. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 27-Апр-12, 04:40
	> Для этого существуют превентивные меры еще на входе. Да, мы сначала воткнем хилый фронтэнд а потом у нас будет головняк что он дохнет от каждого пшика. > К слову говоря, когда предъявят 10005000+ коннектов - загнётся любой сервер, Нжинкс не загнется, например. Он процессы не форкает - ему пофиг. Машина состояний - она и есть машина состояний. Потребление ресурсов на само по себе жонглирование тыщщами соединениями там кардинально ниже, сравнимо с затратами клиента. > вне зависимости от софта. Размечтался. То-то у сайтов подвергающихся "пионерским досам" такого плана первым делом отрастает на входе нжинкс почему-то. > Просто памяти не хватит. В случае с апачем ее жрач кардинально больший - на форки процессов. А в нжинксе только ядром на буфера, только сие и на клиенте жрется что делает атаку куда более симметричной по ресурсам и менее интересной для клиента. > В случае кластера - умножайте на число хостов. Да понятный фиг, энтерпрайзники богатые, им для защиты от нетбука и жпрс свистка воткнуть кластер за несколько десятков килобаксов не вопрос. А что если у хаксора два нетбука окажется случайно? Спецом под него удвоить парк серверов? Вот это и называется апач головного мозга... > Поэтому пионерия, расчитывающая, что nginx спасёт их от всех бед, > обречена в любом случае. От всех не спасет, однако сайты с нжинксом как правило не лагают по дикому от хабраслэшдотэффектов и не валятся совсем уж пионерскими атаками. Лично видел как интернет магазины дико клинило от пионерских атак конкурентов вплоть до втыкания нжинкса фронтом, после чего таковым резко полегчало и конкуренты забили на атаки в силу затратности и нужды платить за более мощные атаки которые совсем уж наколенными методами не делаются.
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

	195. "Вопрос дилетанта"	+/–
	Сообщение от AlexAT (ok) on 27-Апр-12, 07:59
	>> К слову говоря, когда предъявят 10005000+ коннектов - загнётся любой сервер, > Нжинкс не загнется, например. И на основании ж чего такой вывод? На каждый сокет требуется энный размер памяти - загнётся что угодно, не только nginx. >> вне зависимости от софта. > Размечтался. То-то у сайтов подвергающихся "пионерским досам" такого плана первым делом > отрастает на входе нжинкс почему-то. У пионерских сайтов, подвергающихся пионерским досам. Fixed. > В случае с апачем ее жрач кардинально больший - на форки процессов. Логично. Но сути это не меняет. > А в нжинксе только ядром на буфера Огаога. А вы лично-то хоть смотрели, как у nginx'а дела с буферизацией обстоят? Там одно из двух: либо выделяем мелкий буфер, и имеем проблемы с размером хедеров, либо выделяем большой буфер, и имеем хороший такой жрач по памяти на запрос. > сие и на клиенте жрется Не-а. Клиент может вообще не использовать буферы - в случае DoS ему поддержание псевдо-соединения нужно только до момента отправки запроса. После того, как запрос ушел, сервер взялся за работу. Против таких гавриков неплохо помогает небуферизованная отправка первого пакета с хедерами перед какой-либо тяжелой обработкой динамики. >> В случае кластера - умножайте на число хостов. > Да понятный фиг, энтерпрайзники богатые, им для защиты от нетбука и жпрс > свистка воткнуть кластер за несколько десятков килобаксов не вопрос Кластеры делаются из-за тяжелой динамики, а не "для защиты". Для защиты ставятся фронтенды с рядом модулей. А чаще - вообще аппаратные решения на периметр.
	Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

	213. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 01-Май-12, 18:56
	> И на основании ж чего такой вывод? На каждый сокет требуется энный > размер памяти - загнётся что угодно, не только nginx. Только в случае апача требуется еще и куча памяти на сами процессы апача и загибон наступает намного быстрее. Если меряться буферами сокетов - мощный сервант ваш нетбук переспорит на раз и успешная атака потребует кучу оборудования (==стоит дорого). А вот если там еще и апачовые процессы будут память жрать то единственный вшивый нетбук спокойно завалит многопроцессорный xeon пнув воркеров по максимуму и узурпировав их. >> отрастает на входе нжинкс почему-то. > У пионерских сайтов, подвергающихся пионерским досам. Fixed. Ну да, конечно, только у вас сайты не пионерские. А вот у всех остальных - пионеры. Особенно если не по вашему делают. >> В случае с апачем ее жрач кардинально больший - на форки процессов. > Логично. Но сути это не меняет. Это меняет затраты атакующего на атаку. Если в одном случае ему хватит чуть ли не мобильника с GPRS, во втором ему надо ставить уже парк серверов примерно равный по мощности тому что у конторы чтобы просто ощутимо затормозить это, т.к. буфера сокетов на обоих концах линка примерно одинаково жрутся. Гуглить про "усиление атаки". Вот апач дает некислое плечо атакующему, позволяя валить мощные сервера с всякой ерунды. Откровенная такая атака на ресурсы с большим плечом получается. > проблемы с размером хедеров, либо выделяем большой буфер, и имеем хороший > такой жрач по памяти на запрос. А нефиг слать большие хидеры. Ну нет у легитимного клиента валидного повода так делать, а проблемы ботов волнуют только ботов. За такое вообще сразу банан и пусть бот/хаксор отдыхает. >> сие и на клиенте жрется > Не-а. Клиент может вообще не использовать буферы - в случае DoS ему > поддержание псевдо-соединения нужно только до момента отправки запроса. На этот момент он должен помнить о соединении и держать под него буфера, etc. Более того, если совсем не забирать данные из соединение и не трекать его, со стороны сервера можно довольно оперативно давить такое по таймауту, просто установив его достаточно скромным. > После того, как запрос ушел, сервер взялся за работу. Против таких гавриков > неплохо помогает небуферизованная отправка первого пакета с хедерами перед > какой-либо тяжелой обработкой динамики. Ну спасибо тебе кэп. Обычно при пионерской атаке гаврик начинает просто неспешно качать твои 300 кб простыни на скорости 1Кб/сек. Это просто, делается типовыми утилями и требует минимум и ресурсов и мозгов. А вот на 1 свой буфер сокета такой гаврик займет 1 воркер апача + некую память под буфер сокета на сервере. И озадачивая собой воркера на 5 минут. А если 1000 воркеров так форкануть - сервер чудно сколлапсирует, или потому что память на серваке кончается, или потому что все воркеры заняты обслуживанием хакера на ближайшие 5 минут. Ну а юзер зайдя на сайт и так и сяк получает таймаут и отползает восвояси. Цель атами достигнута - сайт недоступен :). А машине состояние пофиг. Ну висит 1000 малоактивных соединений - и пусть висит. Она вообще на них дергается лишь когда состояние меняется. >> Да понятный фиг, энтерпрайзники богатые, им для защиты от нетбука и жпрс >> свистка воткнуть кластер за несколько десятков килобаксов не вопрос > Кластеры делаются из-за тяжелой динамики, а не "для защиты". Для защиты ставятся > фронтенды с рядом модулей. А чаще - вообще аппаратные решения на периметр. Ну да, ну да. А у юзеров нжинксы один сраный 10-баксовый вдсник выдерживает хабраслэшдотэффекты если сделано с умом. Во сколько раз затраты бабла отличаются - сами посчитаете.
	Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

	214. "Вопрос дилетанта"	+/–
	Сообщение от AlexAT (ok) on 02-Май-12, 20:54
	>>> Только в случае апача требуется еще и куча памяти Выбросьте уже винду. 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?
	Ответить | Правка | ^ к родителю #213 | Наверх | Cообщить модератору

	29. "Вопрос дилетанта"	+1 +/–
	Сообщение от Аноним (??) on 24-Апр-12, 10:22
	Трепло тут ты, nginx под нагрузкой работает отлично. Если не понимаешь почему - это не повод рассказывать чушь. Success story - полрунета. Nginx frontend + php-fpm backend масштабируется в любую сторону. Пять лет в разных highload проектах, ни разу не видел апача в production. Хотя коллеги по цеху рассказывают, что не смогли отойти от mod_php и используют связку nginx + apache. Я не использовал ни разу с момента прихода в highload. Ну и если тебя прям совсем цифры интересуют - на входе ~5k rps, ~80 mbit обрабатываются парой закарпленных nginx. И это далеко не предел. Верю, что и апач это осилит. Но не использую.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	34. "Вопрос дилетанта"	–7 +/–
	Сообщение от AlexAT (ok) on 24-Апр-12, 10:37
	> Трепло тут ты, nginx под нагрузкой работает отлично. > Если не понимаешь почему - это не повод рассказывать чушь. > Success story - полрунета. Ты не понимаешь ни сути,  ни причины. Хотя - это одна из причин, по которой nginx популярен в рунете - сильна идеология поиска silver bullet вместо решения прямых задач надежности и масштабируемости.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	36. "Вопрос дилетанта"	+1 +/–
	Сообщение от Аноним (??) on 24-Апр-12, 10:45
	>> Трепло тут ты, nginx под нагрузкой работает отлично. >> Если не понимаешь почему - это не повод рассказывать чушь. >> Success story - полрунета. > Ты не понимаешь ни сути,  ни причины. Хотя - это одна > из причин, по которой nginx популярен в рунете - сильна идеология > поиска silver bullet вместо решения прямых задач надежности и масштабируемости. Расскажи, пожалуйста, что же я не понимаю. Заодно представься что ли, что за проект ведешь/поддерживаешь.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	38. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 24-Апр-12, 10:48
	> Расскажи, пожалуйста, что же я не понимаю. > Заодно представься что ли, что за проект ведешь/поддерживаешь. И, раз ты уж всё понимаешь, расскажи принципиальное отличие apache от nginx. У меня тут вакансия есть, но нужен понимающий.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	39. "Вопрос дилетанта"	+/–
	Сообщение от Nas_tradamus (ok) on 24-Апр-12, 10:55
	Nginx не блокируемый.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	40. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 24-Апр-12, 10:56
	> Nginx не блокируемый. Nginx как раз ОЧЕНЬ блокируемый =) Он не блокирующий, это да.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	71. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 24-Апр-12, 23:15
	> И, раз ты уж всё понимаешь, расскажи принципиальное отличие apache от nginx. State machine обслуживающая в 1 потоке много соединений сразу (nginx) vs 1 поток или процесс на соединение у апача (как минимум с типовыми дефолтными воркерами). Первое менее затратно по ресурсам, особенно на статике или при проксировании, ясен пень.   Я ответил на ваш вопрос? Мне интересно - проверить самого себя и корректность знаний лишний раз всяко не лишне :) > У меня тут вакансия есть, но нужен понимающий. А что за вакансия?
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	82. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 00:23
	> Я ответил на ваш вопрос? На пятерку. На пять с плюсом можно еще вспомнить про цену переключения контекста при мультитрединге. > А что за вакансия? Админская, вестимо
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	130. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 11:44
	>> Я ответил на ваш вопрос? > На пятерку. Значит у меня полимеры на месте :). > На пять с плюсом можно еще вспомнить про цену переключения контекста при мультитрединге. Можно. >> А что за вакансия? > Админская, вестимо Ну огласите вилку, чтоли и чего вообще хотите. Вдруг оно интересным окажется?
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	141. "Вопрос дилетанта"	+1 +/–
	Сообщение от theDolphin on 25-Апр-12, 12:11
	> Ну огласите вилку, чтоли и чего вообще хотите. Вдруг оно интересным окажется? welcome в почту: dolphin@sendmail.ru
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	91. "Вопрос дилетанта"	–1 +/–
	Сообщение от user455 on 25-Апр-12, 01:46
	>> И, раз ты уж всё понимаешь, расскажи принципиальное отличие apache от nginx. > State machine обслуживающая в 1 потоке много соединений сразу (nginx) vs 1 > поток или процесс на соединение у апача (как минимум с типовыми > дефолтными воркерами). Первое менее затратно по ресурсам, особенно на статике или > при проксировании, ясен пень. > Я ответил на ваш вопрос? Мне интересно - проверить самого себя и > корректность знаний лишний раз всяко не лишне :) >> У меня тут вакансия есть, но нужен понимающий. > А что за вакансия? так это не отличие apache от nginx, а отличие mpm prefork от nginx. т.к. если использовать mpm worker или mpm event и интерпретатор через fcgi, то использование апача или нгинкса уже становится вопросом религии.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	103. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 06:25
	> через fcgi, то использование апача или нгинкса уже становится вопросом религии. У апача помнится все воркеры кроме наиболее дебильных сто лет были как нечто кривое, бажное и дико экспериментальное, поэтому так как вы говорите - было только на бумаге. А на реальных серверах почему-то именно так как описано по жизни. Наверное, всем лень эксперименты на себе любимых ставить. А у нжинкса такая модель сервирования - с самого начала и отнюдь не как эксперименты. "Небольшая" такая разница.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	115. "Вопрос дилетанта"	+/–
	Сообщение от user455 on 25-Апр-12, 10:43
	>> через fcgi, то использование апача или нгинкса уже становится вопросом религии. > У апача помнится все воркеры кроме наиболее дебильных сто лет были как > нечто кривое, бажное и дико экспериментальное, поэтому так как вы говорите > - было только на бумаге. А на реальных серверах почему-то именно > так как описано по жизни. Наверное, всем лень эксперименты на себе > любимых ставить. > А у нжинкса такая модель сервирования - с самого начала и отнюдь > не как эксперименты. "Небольшая" такая разница. это не так. проблема была с mod_php и мультитредным мпм. с ним действительно были проблемы. в случае с fastcgi и мультитредными мпм проблем нет.
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	132. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 11:46
	> это не так. проблема была с mod_php и мультитредным мпм. с ним > действительно были проблемы. в случае с fastcgi и мультитредными мпм проблем нет. А у меня нет этого неповоротливого утюга и проблем с ним соответственно нет. State machines FTW. Особенно для отдачи статики. А если кто слишком криворук чтобы такое программить... ну так чего от энтерпрайз-шараг ожидать?
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	123. "Вопрос дилетанта"	+1 +/–
	Сообщение от Аноним (??) on 25-Апр-12, 11:34
	> так это не отличие 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 тредов. И всё равно на одно соединение - один тред.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	126. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 11:38
	Кстати, еще раз: у апача существует аналог nginx - Apache Traffic Server, что как бы говорит о том, что апач сам по себе не может быть фронтом на больших нагрузках.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	135. "Вопрос дилетанта"	–4 +/–
	Сообщение от Аноним (??) on 25-Апр-12, 11:49
	> В общем теорию КА (FSM) вам на изучение. Теорию КО (Cap'n Obvious) вам на изучение, Кэп. > Вот принципиальная разница, поэтому апач не может обработать 10k одновременных соединений, Кэп? > а nginx не может работать с cgi (не путать с *cgi, Кэп?! > для которых nginx выступает проксёй) т.к. это его блокирует - операция > обработки пакета должна занимать крайне малое конечное время. Нет, ну Кэп же! Капитан, а вы не хотите мне рассказать сколько будет 2+2? > P.S. mpm_worker тоже мало отличается - создается N форков по M тредов. > И всё равно на одно соединение - один тред. Эк вас сегодня на капитанство то прошибло.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	140. "Вопрос дилетанта"	+1 +/–
	Сообщение от theDolphin on 25-Апр-12, 12:08
	> Эк вас сегодня на капитанство то прошибло. Ну так раз кэп, то как вы сравниваете nginx и апач?
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	63. "Вопрос дилетанта"	+/–
	Сообщение от AlexAT (ok) on 24-Апр-12, 19:19
	> Success story - полрунета. рунет - не показатель. какбэ. у него специфика. в рунете и BSD можно встретить
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	83. "Вопрос дилетанта"	–3 +/–
	Сообщение от Аноним (??) on 25-Апр-12, 00:24
	>> Success story - полрунета. > рунет - не показатель. какбэ. у него специфика. в рунете и BSD > можно встретить Вы что-то имеете против BSD?
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	119. "Вопрос дилетанта"	–3 +/–
	Сообщение от тигар (ok) on 25-Апр-12, 11:26
	>>> Success story - полрунета. >> рунет - не показатель. какбэ. у него специфика. в рунете и BSD >> можно встретить > Вы что-то имеете против BSD? конкретно у него, видимо, попоболь, т.к. на бсд не нужно патчить ядро и недософт, чтобы она могла темринировать клиентские pppoe, например. У него есть некие Пачти ядра linux, и Патчи на некоего pppoed (или че там). Только с этими Патчами (дада, с большой буквы П) оно может хоть как-то работать.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	128. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 11:41
	>>>> Success story - полрунета. >>> рунет - не показатель. какбэ. у него специфика. в рунете и BSD >>> можно встретить >> Вы что-то имеете против BSD? > конкретно у него, видимо, попоболь, т.к. на бсд не нужно патчить ядро > и недософт, чтобы она могла темринировать клиентские pppoe, например. У него > есть некие Пачти ядра linux, и Патчи на некоего pppoed (или > че там). Только с этими Патчами (дада, с большой буквы П) > оно может хоть как-то работать. Ну, коллега, тут вы тоже перебираете. Просто я, например, знаю где лучше чёрт, где лучше пингвин, а где и солярку стоит попробовать. И по этому всегда удивляюсь красноглазию или бздфилии. Кесарю - кесарево.
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	134. "Вопрос дилетанта"	–2 +/–
	Сообщение от тигар (ok) on 25-Апр-12, 11:49
	> Ну, коллега, тут вы тоже перебираете. Просто я, например, знаю где лучше > чёрт, где лучше пингвин, а где и солярку стоит попробовать. И > по этому всегда удивляюсь красноглазию или бздфилии. Кесарю - кесарево. если научите как по другому ставить на место "специалиста" alexat, не так толсто, я буду признателен. знающие системы "по l.o.r`у" типа него.. несколько утомляют.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	146. "Вопрос дилетанта"	+1 +/–
	Сообщение от theDolphin on 25-Апр-12, 12:51
	> если научите как по другому ставить на место "специалиста" alexat, не так > толсто, я буду признателен. знающие системы "по l.o.r`у" типа него.. несколько > утомляют. Как ребенка, разговаривая, объясняя. Вы же не бьёте детей, если они еще чего-то не понимают? Они же дети, вырастут - научатся.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	154. "Вопрос дилетанта"	+1 +/–
	Сообщение от AlexAT (ok) on 25-Апр-12, 17:07
	> если научите как по другому ставить на место "специалиста" alexat, не так > толсто, я буду признателен. знающие системы "по l.o.r`у" типа него.. несколько > утомляют. вы можете просто пройти лесом, надежнее и тоньше
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	136. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 11:50
	> конкретно у него, видимо, попоболь, Судя по коментам, болит пониже хвоста совсем не у него.
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	142. "Вопрос дилетанта"	+/–
	Сообщение от Michael Shigorin (ok) on 25-Апр-12, 12:30
	> конкретно у него, видимо, попоболь, т.к. на бсд не нужно патчить ядро "На бсд" для многих задач (да-да, и виртуализации) ядро патчить просто нечем, кроме Ваших золотых рук... может, давайте рядом с [[LicenseComparison]] ещё какой [[PlatformComparison]] или там [[Сравнение фрюниксов]] начнём выписывать?
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	145. "Вопрос дилетанта"	+/–
	Сообщение от тигар (ok) on 25-Апр-12, 12:45
	>> конкретно у него, видимо, попоболь, т.к. на бсд не нужно патчить ядро > "На бсд" для многих задач (да-да, и виртуализации) ядро патчить просто нечем, ну нечем, и что?:-) > кроме Ваших золотых рук... может, давайте рядом с [[LicenseComparison]] ещё какой > [[PlatformComparison]] или там [[Сравнение фрюниксов]] начнём выписывать? а это чем-то чему-либо поможет? можно пытаться натянуть презерватив на глобус^W^W^Wнекие патчи на некие ядра, только зачем, если можно взять нечто готовое? у меня есть 2 тачки с линуксом, не скажу что я рад этому факту, но в тех задачах оно работает. фря не смогла, солярис не пробовал, но, думаю, рез-т будет не сильно лучше чем с fbsd. 10+ Тб инфы, преимущественно фильмы по 1.4Тб, дофига одновременно смотрящих/качающих с этой тачки хомячков, тут софтрейд+xfs показал себя значительно лучше raidz, на том же железе. Но г-н alexat убежден, что линукс в его задачах рвет всех, хотя "всех" он врядли видел, не то что пробовал. Однако сей факт не мешает ему тупить на форумах, обсирая ОСь которую он не знает/не видел.
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	150. "Вопрос дилетанта"	+/–
	Сообщение от Michael Shigorin (ok) on 25-Апр-12, 13:10
	>> может, давайте рядом с [[LicenseComparison]] ещё какой [[PlatformComparison]] >> или там [[Сравнение фрюниксов]] начнём выписывать? > а это чем-то чему-либо поможет? Не исключено, ведь по крайней мере: - будет куда нос засунуть на предмет текущего состояния (как свой, так и чужой); - вместо фекания металий требующим спуску пара можно будет предложить   технические раскопки и в меру сил -- грамотное оформление. Например, ссылки на те же сравнения производительности современных альтернатив poll(2) в контексте высоконагруженных веб-серверов могут пригодиться.
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	155. "Вопрос дилетанта"	+/–
	Сообщение от AlexAT (ok) on 25-Апр-12, 17:09
	> Но г-н alexat убежден, что линукс в его задачах рвет всех, > хотя "всех" он врядли видел, не то что пробовал. Однако сей > факт не мешает ему тупить на форумах, обсирая ОСь которую он > не знает/не видел. BSD в данном контексте нежизнеспособно. Когда оно перестанет крашиться под сетевой нагрузкой, тогда и поговорим.
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	157. "Вопрос дилетанта"	+/–
	Сообщение от тигар (ok) on 25-Апр-12, 17:15
	> BSD в данном контексте нежизнеспособно. Когда оно перестанет крашиться под сетевой нагрузкой, > тогда и поговорим. и, конечно же, есть что показать в цифрах, в подтверждение, правда?;-)
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	160. "Вопрос дилетанта"	+/–
	Сообщение от AlexAT (ok) on 25-Апр-12, 19:10
	> и, конечно же, есть что показать в цифрах, в подтверждение, правда?;-) go читать на наге, ни одного дельного совета, зато полно крашлогов
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

	172. "Вопрос дилетанта"	+/–
	Сообщение от theDolphin (ok) on 26-Апр-12, 11:15
	>> и, конечно же, есть что показать в цифрах, в подтверждение, правда?;-) > go читать на наге, ни одного дельного совета, зато полно крашлогов >> и, конечно же, есть что показать в цифрах, в подтверждение, правда?;-) > go читать на наге, ни одного дельного совета, зато полно крашлогов Давайте поговорим, ибо я не видел, как оно крашится, хотя пользую BSD вместе с линуксом давно. Коллега, знания, полученные на ЛОРе и НАГе объективными считать крайне сложно. Прошу оперировать своим опытом. Если запускать BSD на домашнем ПК с сетью на 8319 то о надёжности разговаривать не приходится. Я BSD гоняю на HP, раньше было на Supermicro (говно еще то, но хотя бы серверное). В производительность TCP-стека упирался, а вот крашей под нагрузкой не видел ни разу. Видимо руки кривые - BSD ни разу не крашилась по нагрузке =) В линуксе мне не нравится, что нет одной простой операции - вывести количество соединений в backlog, что бы хотя бы понимать справляется ли софт с accept'ом соединений. Еще в линуксе расстраивает отсутствие вменяемого CARP/VRRP/аналога. uCARP кривой и работает в userland. Так что еще раз: кесарю - кесарево и любой софт надо уметь готовить, а не ссылаться на НАГ.
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	179. "Вопрос дилетанта"	+/–
	Сообщение от AlexAT (ok) on 26-Апр-12, 17:56
	> Давайте поговорим, ибо я не видел, как оно крашится, хотя пользую BSD > вместе с линуксом давно. Давайте. У вас есть хотя бы 4G/350Kpps сквозняком через железку?
	Ответить | Правка | ^ к родителю #172 | Наверх | Cообщить модератору

	180. "Вопрос дилетанта"	+/–
	Сообщение от AlexAT (ok) on 26-Апр-12, 18:00
	> Коллега, знания, полученные на ЛОРе и НАГе объективными считать крайне сложно. Прошу > оперировать своим опытом. Тут еще специфика: провайдерская эксплуатация. Во-первых это прогон трафика. Большого. Измеряемо петабайтами за срок менее полугода. Шейперы и прочее. Локально фактически не терминируется ничего - приходит трафик, инкапсулируется или декапсулируется PPPoE, шейпится, возможно NAT'ится, уходит. Постоянные поднятия-опускания интерфейсов, постоянные изменения правил шейпера и файрвола. В данном случае опыт таков, что железки стоят под нагрузкой 24/7/365, и если оно грохнется - взвоет несколько тысяч абонентов, потому что все они получают интернет домой через эту железку. BSD на таких нагрузках не живет как при личном опыте, так и по опыту людей на наге.
	Ответить | Правка | ^ к родителю #172 | Наверх | Cообщить модератору

	182. "Вопрос дилетанта"	+/–
	Сообщение от theDolphin (ok) on 26-Апр-12, 22:39
	В провайдере вообще лучше использовать что-то железное и более приспособленное, ну да не всегда экономически оправдано. Мой опыт с BSD только до 1G/200kpps с терминацией трафика на BSD либо на nginx, либо на mpd. Mpd во фре до стабилизации accel_ppp в линухе давал хороший выигрыш по пропускной способности - из опыта построения VPDN-сервиса. Но мы-то сейчас об nginx говорим, а FreeBSD для nginx - дом родной. А вкупе с ядреным carp - так вообще неплохое решение для первичного приёма трафика.
	Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

	205. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 28-Апр-12, 01:25
	> go читать на наге, ни одного дельного совета, зато полно крашлогов И в списке рассылки нжинкса так же. Если перец с крахом/взвисом системы в сети или ФС - это почти наверняка bsdшник.
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	198. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 27-Апр-12, 12:25
	> можно пытаться натянуть презерватив на глобус^W^W^Wнекие патчи на некие ядра, Вот только почему-то это приходится делать сугубо тигарам и изенам. А у остальных оно или и так работает, или у них очень кастомная задача, под которую по любому придется, в любой ОС. Так что или расскажи что ты там такое уникальное патчишь, или признай что у тебя весенний гон.
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	31. "Вопрос дилетанта"	+2 +/–
	Сообщение от oxyum (ok) on 24-Апр-12, 10:27
	http://hh.ru/ - nginx без всяких апачей...
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	64. "Вопрос дилетанта"	+/–
	Сообщение от AlexAT (ok) on 24-Апр-12, 19:20
	> http://hh.ru/ - nginx без всяких апачей... вот это вот неплохой пример какбэ. очень даже. тут уже спорить не с чем. но вот насчет "без всяких апачей" всё равно можно посомневаться - откуда дровишки?
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	75. "Вопрос дилетанта"	+2 +/–
	Сообщение от oxyum (ok) on 24-Апр-12, 23:29
	>> http://hh.ru/ - nginx без всяких апачей... > вот это вот неплохой пример какбэ. очень даже. тут уже спорить не > с чем. но вот насчет "без всяких апачей" всё равно можно > посомневаться - откуда дровишки? Ну я как бэ кишочки http://hh.ru/ правил... Конфиги nginx видел и даже патчи для этих конфигов писал... ;)
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	120. "Вопрос дилетанта"	–1 +/–
	Сообщение от тигар (ok) on 25-Апр-12, 11:27
	>>> http://hh.ru/ - nginx без всяких апачей... >> вот это вот неплохой пример какбэ. очень даже. тут уже спорить не >> с чем. но вот насчет "без всяких апачей" всё равно можно >> посомневаться - откуда дровишки? > Ну я как бэ кишочки http://hh.ru/ правил... Конфиги nginx видел и даже > патчи для этих конфигов писал... ;) ну тогда может не стоит скрывать факт что там nginx+java, чтобы уж совсем по-честному было? ;-)
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	138. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 11:51
	> ну тогда может не стоит скрывать факт что там nginx+java, чтобы уж > совсем по-честному было? ;-) Как это влияет на отсутствие апача, интересно?  :)
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	139. "Вопрос дилетанта"	–1 +/–
	Сообщение от тигар (ok) on 25-Апр-12, 11:59
	>> ну тогда может не стоит скрывать факт что там nginx+java, чтобы уж >> совсем по-честному было? ;-) > Как это влияет на отсутствие апача, интересно?  :) ну тут вопрос спорный, чтоже хуже, апач или жава;) но а вообще да, про "без апача" я пропустил как-то;(
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	147. "Вопрос дилетанта"	+1 +/–
	Сообщение от oxyum (ok) on 25-Апр-12, 12:53
	>>>> http://hh.ru/ - nginx без всяких апачей... >>> вот это вот неплохой пример какбэ. очень даже. тут уже спорить не >>> с чем. но вот насчет "без всяких апачей" всё равно можно >>> посомневаться - откуда дровишки? >> Ну я как бэ кишочки http://hh.ru/ правил... Конфиги nginx видел и даже >> патчи для этих конфигов писал... ;) > ну тогда может не стоит скрывать факт что там nginx+java, чтобы уж > совсем по-честному было? ;-) Я могу сказать больше, всю динамику там вначале ловит Python, а Java там в самом конце pipeline. Подробнее можно тут глянуть: https://github.com/hhru/frontik , это это tornado-based сервер для накладывания xslt на данные от бэкендов.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	47. "Вопрос дилетанта"	+1 +/–
	Сообщение от TeXHaPb (ok) on 24-Апр-12, 12:58
	gdeetotdom.ru = nginx + php_fcgi (вопросы модности новых версий, php_fpm и всего прочего прошу не обсуждать, не по моей воле не дали сделать). Посещаемость: http://www.liveinternet.ru/stat/ged/ badoo.com = nginx + php_fpm (предлагаю самим найти прув авторства)
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	35. "Вопрос дилетанта"	+/–
	Сообщение от Stream on 24-Апр-12, 10:40
	wordpress.org wordpress.com yandex.ru
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	42. "Вопрос дилетанта"	–2 +/–
	Сообщение от Аноним (??) on 24-Апр-12, 11:03
	> wordpress.org > wordpress.com > yandex.ru У яндекса свой http-сервер, что характерно - проприетарный.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	45. "Вопрос дилетанта"	+/–
	Сообщение от Stream on 24-Апр-12, 11:55
	Вы с гуглом перепутали.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	50. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 24-Апр-12, 14:43
	Не, не перепутал. Они используют в своих проектах nginx, lighthttpd, свой Phantom (можно нагуглить) и, насколько помню, ещё один, тож собственной разработки.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	105. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 06:28
	> Не, не перепутал. Они используют в своих проектах nginx, lighthttpd, свой Phantom > (можно нагуглить) и, насколько помню, ещё один, тож собственной разработки. Так все-таки нжинкс используют же? В чем соврал оратор который до вас? :)
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	129. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 11:43
	>> Не, не перепутал. Они используют в своих проектах nginx, lighthttpd, свой Phantom >> (можно нагуглить) и, насколько помню, ещё один, тож собственной разработки. > Так все-таки нжинкс используют же? В чем соврал оратор который до вас? > :) Ни в чем, просто я уточнил.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	48. "Вопрос дилетанта"	+2 +/–
	Сообщение от Аноним (??) on 24-Апр-12, 14:06
	Как раз под нагрузку и стоит. При вервой возможности от apache надо избавляться.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	57. "Вопрос дилетанта"	+/–
	Сообщение от FSA (ok) on 24-Апр-12, 17:13
	С какого перепуга? nginx+php выдержит намного большую нагрузку чем nginx+apache+php. И вообще apache только для .htaccess нужен. Другого применения для apache я не нашёл.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	72. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 24-Апр-12, 23:17
	> Для небольшого локалхоста вполне годно. А вот под нагрузку такое ставить не стоит. Вам наверное нравятся его жирные воркеры оптом. Не, ну если повезло и кто-то проплатил 64-ядерный сервак с 256гигз оперативы - то и апач быстрый сервер и совсем не жрет ресурсы тогда :). А если ресурсы лимитированы - вот тут с апачем один гемор...
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	23. "Вопрос дилетанта"	+/–
	Сообщение от arka on 24-Апр-12, 09:29
	Превосходно работает и с пыхом, проблем не видел. Единственно для чего теперь держим апач на одном из серверов - работа с svn по http
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	52. "Вопрос дилетанта"	+/–
	Сообщение от Куяврик on 24-Апр-12, 14:57
	> Единственно для чего теперь держим апач на одном из серверов - работа с svn по http также можно скормить nginx-у
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	56. "Вопрос дилетанта"	+/–
	Сообщение от arka on 24-Апр-12, 17:08
	Хмм, есть что-то подобное mod_dav_svn для nginx? Что-то не могу нагуглить рабочего решенья
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	58. "Вопрос дилетанта"	+/–
	Сообщение от Andrey Mitrofanov on 24-Апр-12, 17:25
	> Хмм, есть что-то подобное mod_dav_svn для nginx? Что-то не могу нагуглить рабочего > решенья * http://github.com/arut/nginx-dav-ext-module нерабочее? * дать денег сысоев фоундейшн?
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	67. "Вопрос дилетанта"	+/–
	Сообщение от PavelR (ok) on 24-Апр-12, 20:22
	>> Хмм, есть что-то подобное mod_dav_svn для nginx? Что-то не могу нагуглить рабочего >> решенья > * http://github.com/arut/nginx-dav-ext-module нерабочее? * Оно не для того. > * дать денег сысоев фоундейшн? * Зачем, если есть mod_dav_svn ? Я запускаю для него отдельный апачик и проксирую.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	112. "Вопрос дилетанта"	–1 +/–
	Сообщение от Andrey Mitrofanov on 25-Апр-12, 10:14
	>> * дать денег сысоев фоундейшн? >  * Зачем, если есть mod_dav_svn ? Я запускаю для него отдельный апачик и проксирую. Ну, в общем-то незачем. Больше самообразовательный поиск пределов конкретного инструмента (пока четра на песке тут: не может .htaccess / шаред хостинг и WebDAV для SVN). //Ну, и конечно, потролить чуток, как же без. (Интересно, а git %))) не R/O по http умеет, и нужен ли ему для этого именно-таки апач?)
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	118. "Вопрос дилетанта"	+/–
	Сообщение от PavelR (ok) on 25-Апр-12, 11:20
	>>> * дать денег сысоев фоундейшн? >>  * Зачем, если есть mod_dav_svn ? Я запускаю для него отдельный апачик и проксирую. > Ну, в общем-то незачем. Больше самообразовательный поиск пределов конкретного инструмента > (пока четра на песке тут: не может .htaccess / шаред хостинг > и WebDAV для SVN). //Ну, и конечно, потролить чуток, как же > без. (Интересно, а git %))) не R/O по http умеет, и > нужен ли ему для этого именно-таки апач?) нет, git работает чисто по WebDAV, и в случае апача используется mod_dav_fs. Вот в случае использования указанного выше модуля nginx (который реализует недостающие DAV-методы), наверное можно запустить доступ к git-репозитарию средствами nginx. Другое дело, что в случае git, например, я не знаю способа разделить доступ пользователей к веткам, например. AFAIK, это by-design так.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	143. "Вопрос дилетанта"	+/–
	Сообщение от oxyum (ok) on 25-Апр-12, 12:39
	> Вот в случае использования указанного выше модуля nginx (который реализует недостающие > DAV-методы), наверное можно запустить доступ к git-репозитарию средствами nginx. > Другое дело, что в случае git, например, я не знаю способа разделить > доступ пользователей к веткам, например. AFAIK, это by-design так. Скорее не by-desing, а просто сделано только то, что было нужно для решения конкретных задач. Игорь знает о нехватке различного функционала в WebDAV, но на когда в плане стоит исправление я не спрашивал, ибо лично мне WebDAV ни разу не был нужен в последнее время.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	173. "Вопрос дилетанта"	+/–
	Сообщение от Andoriyu on 26-Апр-12, 13:55
	Потому, что нормальные люди имеют доступ к git'у по ssh, а в качестве контроля доступа используют gitosis или gitolite
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	121. "Вопрос дилетанта"	+/–
	Сообщение от тигар (ok) on 25-Апр-12, 11:29
	>> Единственно для чего теперь держим апач на одном из серверов - работа с svn по http > также можно скормить nginx-у а вот и нет.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	33. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 24-Апр-12, 10:36
	>> Существуют ли сайты, где nginx главный и единственный движок (без Apache), >> а не FrontEnd? И если уже совсем обнаглеть: существуют ли nginx-only-based CMS? > Если не считать пых, то почти все остальные сайты на nginx превосходно > обходятся без apache. Пых в первую очередь прекрасно обходится без апача. Это уже сильно позже появилась поддержка UWSGI/SCGI для руби и питона.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	77. "Вопрос дилетанта"	+1 +/–
	Сообщение от oxyum (ok) on 24-Апр-12, 23:34
	>>> Существуют ли сайты, где nginx главный и единственный движок (без Apache), >>> а не FrontEnd? И если уже совсем обнаглеть: существуют ли nginx-only-based CMS? >> Если не считать пых, то почти все остальные сайты на nginx превосходно >> обходятся без apache. > Пых в первую очередь прекрасно обходится без апача. Это уже сильно позже > появилась поддержка UWSGI/SCGI для руби и питона. Вот не надо, FastCGI в nginx давно, и нормальная поддержка для него в Python и Ruby появилась куда раньше, чем в PHP. А uWSGI да, появился поздно... я месяц Игорю Сысоеву на мозги капал при каждом удобном случее, чтобы он принял их модуль в основную ветку... мне даже немного стыдно, но уж очень надо было для одного проекта тогда! :( Но uWSGI вообще появился поздно, а вот flup (наверное до сих пор самая популярная реализация FastCGI) уже очень давно существует.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	84. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 00:27
	> Вот не надо, FastCGI в nginx давно, и нормальная поддержка для него > в Python и Ruby появилась куда раньше, чем в PHP. Чего не надо-то? =)) Читайте полный тред. Я о том и говорю, что всё это давно уже работает.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	88. "Вопрос дилетанта"	+1 +/–
	Сообщение от oxyum (ok) on 25-Апр-12, 00:43
	>> Вот не надо, FastCGI в nginx давно, и нормальная поддержка для него >> в Python и Ruby появилась куда раньше, чем в PHP. > Чего не надо-то? =)) Читайте полный тред. Я о том и говорю, > что всё это давно уже работает. Не, вы написали, что пых в ПЕРВУЮ очередь, а на самом деле в нём нормальный FastCGI появился наверное последним... Впрочем стоит признать, что mod_php, для своего времени, работал очень даже неплохо! :)
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	131. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 11:45
	>>> Вот не надо, FastCGI в nginx давно, и нормальная поддержка для него >>> в Python и Ruby появилась куда раньше, чем в PHP. >> Чего не надо-то? =)) Читайте полный тред. Я о том и говорю, >> что всё это давно уже работает. > Не, вы написали, что пых в ПЕРВУЮ очередь, а на самом деле > в нём нормальный FastCGI появился наверное последним... Впрочем стоит признать, что > mod_php, для своего времени, работал очень даже неплохо! :) Ммм. Я FastCgi юзаю где-то с 0.6, если мне память не изменяет. В любом случае это было в 2006 или 2007 году - давно уже.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	15. "Вопрос дилетанта"	–2 +/–
	Сообщение от бедный буратино (ok) on 24-Апр-12, 07:41
	> Существуют ли сайты, где 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
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	18. "Вопрос дилетанта"	+/–
	Сообщение от kurokaze (ok) on 24-Апр-12, 08:32
	>Существуют ли сайты, где nginx главный и единственный движок (без Apache), а не FrontEnd? У меня несколько штук на lighttpd
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	106. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 06:31
	> У меня несколько штук на lighttpd У него есть ряд дурных свойств в плане проксирования/реакции на runaway скрипта когла тот пошел вразнос и генерит большую портянку. В этом случае лайти, целиком буферизующий запрос в памяти, может выжрать нетривиальный объем оперативы. И что хуже - потом он ее не отдаст.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	32. "Вопрос дилетанта"	+1 +/–
	Сообщение от Аноним (??) on 24-Апр-12, 10:34
	По факту - нет, должен быть обработчик кода. FastCGI, UWSGI, SCGI. Зачастую вместо apache/mod_php используется nginx + php-fpm. php-fpm - облегченный fastcgi-обработчик php. Проще и производительнее апача. nginx хорош своей архитектурой FSM, которая позволяет обрабатывать очень много соединений одним процессом, гибкостью конфигурации и богатым функционалом по предварительному разбору запросов. FreeBSD 8.1/nginx с легкостью выдерживал DDOSы под гигабит, отдавая 500 на специфичный для бота запрос. Я вот например работаю уже 6 лет в эксплуатации различных онлайн сервисов и ни разу не встречал апача в production. Только nginx либо более узкоспециализированные балансировщики.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	51. "Вопрос дилетанта"	+/–
	Сообщение от Куяврик on 24-Апр-12, 14:56
	> Существуют ли сайты, где nginx главный и единственный движок (без Apache) Да. Превеликое множество. > существуют ли nginx-only-based CMS не слышал. и в принципе если нет завязки на нгинкс-специфик модули то собственно это прото вебсервер с php.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	55. "Вопрос дилетанта"	+/–
	Сообщение от FSA (ok) on 24-Апр-12, 17:07
	Любой сайт на php работает без apache. Другое дело, что шаред хостинга нет на чистом nginx.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	78. "Вопрос дилетанта"	+2 +/–
	Сообщение от oxyum (ok) on 24-Апр-12, 23:39
	> Любой сайт на php работает без apache. Другое дело, что шаред хостинга > нет на чистом nginx. Делается, кстати, на раз... я делал пару раз под заказ подобные решения, для внутреннего использования. Продавать это массам конечно нельзя, но только потому что служба поддержки сколлапсирует под тысячями запросов вроде "а почему у меня .htaccess не работает? ну и что, что вы не заявляете его поддержку! мне на всё плевать, делайте чтобы работало, я вам 3 доллара заплатил, уроды!" А технически делается даже немного проще чем на апаче - формат конфига проще на мой взгляд.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	86. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 00:39
	>> Любой сайт на php работает без apache. Другое дело, что шаред хостинга >> нет на чистом nginx. > Делается, кстати, на раз... я делал пару раз под заказ подобные решения, > для внутреннего использования. > Продавать это массам конечно нельзя, но только потому что служба поддержки сколлапсирует > под тысячями запросов вроде "а почему у меня .htaccess не работает? > ну и что, что вы не заявляете его поддержку! мне на > всё плевать, делайте чтобы работало, я вам 3 доллара заплатил, уроды!" > А технически делается даже немного проще чем на апаче - формат конфига > проще на мой взгляд. Вживую видел shared-хостинг на nginx и скрипт для парсинга .htaccess Криво, но работало =)
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	87. "Вопрос дилетанта"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 00:40
	> А технически делается даже немного проще чем на апаче - формат конфига > проще на мой взгляд. Как по мне - так значительно проще и более читаемый.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	89. "Вопрос дилетанта"	+1 +/–
	Сообщение от oxyum (ok) on 25-Апр-12, 00:45
	>> А технически делается даже немного проще чем на апаче - формат конфига >> проще на мой взгляд. > Как по мне - так значительно проще и более читаемый. А для организации шаред-хостинга куда важнее не читаемость, а писуемость! ;)
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	206. "Вопрос дилетанта"	–1 +/–
	Сообщение от Аноним (??) on 28-Апр-12, 01:28
	> А для организации шаред-хостинга куда важнее не читаемость, а писуемость! ;) Для организации шаред хостинга лучше всего пойти и застрелиться чтоб не засирать уже мир этими помойками - рассадниками хакерья и геморроя для вебдевов.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	98. "Вопрос дилетанта"	+/–
	Сообщение от Michael Shigorin (ok) on 25-Апр-12, 03:21
	> Существуют ли сайты, где nginx главный и единственный движок (без Apache), > а не FrontEnd? Полно.  И точно существуют, мои тоже потихоньку перебираются на такую конфигурацию. > И если уже совсем обнаглеть: существуют ли nginx-only-based CMS? Зачем бы, httpd ведь разные на местности бывают... под рукой ChiliProject на nginx+unicorn и TYPO3 на nginx+php-fpm вполне себя комфортно чувствуют.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

28. "Релиз http-сервера nginx 1.2.0"	–1 +/–
Сообщение от Аноним (??) on 24-Апр-12, 10:16
В качестве localhosta использую Cherokee и тоже очн доволен
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

60. "Релиз http-сервера nginx 1.2.0"	–2 +/–
Сообщение от Игорь (??) on 24-Апр-12, 18:42
> [proxy/fastcgi/scgi/uwsgi] Он как не хотел из "каропки" поддерживать WSGI так и не хочет. А я как пользую fastcgi+supervisor не переходя на uwsgi так и пользую. Каждый при своем короч... Но! Абыдна, однако!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

66. "Релиз http-сервера nginx 1.2.0"	–1 +/–
Сообщение от Аноним (??) on 24-Апр-12, 20:15
> nginx используется на 12.76% Нуканешна. А позади него стоит старый добрый Апач.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	74. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Аноним (??) on 24-Апр-12, 23:20
	> Нуканешна. А позади него стоит старый добрый Апач. Нахрена? Вас прикалывает админить 2 сервака вместо 1? Сомнительно что много админов разделяют ваш оптимизм по этому поводу :)
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	85. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 00:36
	>> Нуканешна. А позади него стоит старый добрый Апач. > Нахрена? Вас прикалывает админить 2 сервака вместо 1? Сомнительно что много админов > разделяют ваш оптимизм по этому поводу :) Не, я много таких консерваторов видел. Как правило из-за того, что не осиливают переписать mod_rewrit'овые правила для ngx_rewrite Кстати, среди проектов Apache же есть отличный балансер. Странно, что его мало кто использует. Я, впрочем, тоже не щупал. Кто нибудь что нибудь про него знает?
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	107. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Аноним (??) on 25-Апр-12, 06:33
	> Кстати, среди проектов Apache же есть отличный балансер. А нжинкс как бы вполне себе сервер+прокси а не только балансер... наверное поэтому никто и не прется от идеи юзать апачевское добро. Вы как предпочитаете, админить 1 софтину или несколько? Ответ очевиден!
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	151. "Релиз http-сервера nginx 1.2.0"	–1 +/–
	Сообщение от Алекс (??) on 25-Апр-12, 13:18
	>> Кстати, среди проектов Apache же есть отличный балансер. > А нжинкс как бы вполне себе сервер+прокси а не только балансер... наверное > поэтому никто и не прется от идеи юзать апачевское добро. Вы > как предпочитаете, админить 1 софтину или несколько? Ответ очевиден! не прутся, но альтернативы нет. говорят же - для одиночных проектов nginx без вариантов, а на массовом хостинге - апач ещё как нужен, хоть где-то ибо .htaccess nginx не умеет, а он сильно юзерам нужен.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	185. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Arti (??) on 26-Апр-12, 23:29
	>>> Кстати, среди проектов Apache же есть отличный балансер. >> А нжинкс как бы вполне себе сервер+прокси а не только балансер... наверное >> поэтому никто и не прется от идеи юзать апачевское добро. Вы >> как предпочитаете, админить 1 софтину или несколько? Ответ очевиден! > не прутся, но альтернативы нет. > говорят же - для одиночных проектов nginx без вариантов, а на массовом > хостинге - апач ещё как нужен, хоть где-то ибо .htaccess nginx > не умеет, а он сильно юзерам нужен. у меня есть видос где сысоев горит .htaccess не будет. и это правильно он должен быть лёгкий твой любимый полный сервак досят медленные соединнения и поставив nginx перед - проблема возможно решиться.
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	207. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Аноним (??) on 28-Апр-12, 01:32
	> хостинге - апач ещё как нужен, хоть где-то ибо .htaccess nginx > не умеет, а он сильно юзерам нужен. Особенно смешно выглядит когда Вася и Петя что-то не поделили а заодно падает или взламывается еще пяток крЮтых корпоративных сайтов которые виноваты только тем что их угораздило валяться в том же общественном туалете.
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

113. "Релиз http-сервера nginx 1.2.0"	+/–
Сообщение от Аноним (??) on 25-Апр-12, 10:17
Админю небольшой shared хостинг. Приходится использовать связку Apache+Nginx именно из-за htaccess. Городить огород с интерпретатором даже и в голову не приходило - получить рутовую дыру таким образом проще простого. Для проектных серверов да, проще использовать nginx only.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	186. "Релиз http-сервера nginx 1.2.0"	–1 +/–
	Сообщение от Arti (??) on 26-Апр-12, 23:31
	у тебя че за система на хосте? МАК если возмозно ну ли как там у линуксойдов похожее. апач выкинешь.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	208. "Релиз http-сервера nginx 1.2.0"	+/–
	Сообщение от Аноним (??) on 28-Апр-12, 01:33
	У вас там какой мак? Опийный чтоли? O_O
	Ответить | Правка | ^ к родителю #186 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема