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

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

"Nginx стал самым популярным http-сервером в Рунете"	+/–
Сообщение от opennews (ok) on 10-Окт-12, 13:47
По данным (https://www.openstat.ru/counter:meta/trends/report/crawlerse...) openstat.ru количество работающих под управлением nginx web-серверов  в России превысило количество серверов, использующих Apache, и составило 44,77% против 44,02% на 9 октября. В целом складывается картина доминирования Opensource на вебсерверах Рунета, ближайший конкурент - Microsoft IIS довольствуется долей в 6,91% и не показывает тенденцию к росту. В соответствии с октябрьским отчётом (http://news.netcraft.com/archives/2012/10/02/october-2012-we...) NetCraft, доля  nginx в общей выборке сайтов составляет 11,80% (apache - 58%, IIS - 16,28%), в выборке активных сайтов - 11.99% (apache - 55,43%, IIS - 12,36%). Примечательно, что при рассмотрении только HTTPS-серверов, доля nginx составляет только 2.3%, в то время как Apache занимает 41.6%, а IIS - 40.8%. URL: https://www.openstat.ru/counter:meta/trends/report/crawlerse... Новость: http://www.opennet.dev/opennews/art.shtml?num=35043
Ответить | Правка | Cообщить модератору

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

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

1. "Nginx стал самым популярным http-сервером в Рунете"	+3 +/–
Сообщение от rshadow (ok) on 10-Окт-12, 13:47
[facepalm] Связка nginx <=> Apache? Не, не слышал...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Nginx стал самым популярным http-сервером в Рунете"	+9 +/–
	Сообщение от koblin (ok) on 10-Окт-12, 14:08
	сейчас часто уже не так, а nginx => какой-нибудь wsgi
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	5. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от rshadow (ok) on 10-Окт-12, 14:47
	Это на передовой. А в тылах все так же глухо.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	25. "Nginx стал самым популярным http-сервером в Рунете"	–4 +/–
	Сообщение от Аноним (??) on 10-Окт-12, 19:21
	> Это на передовой. А в тылах все так же глухо. Глухо лишь пока школьник с мобилки не пофлудит коннекциями, положив с своего телефона огроменный сервак в одно рыло :). После чего апач очень быстро идет лесом, особенно если сайт подразумевает зарабатывание денег, как интернет-магазины например. А вот нжинкс так уже фиг завалишь. Так что "пионерский ddos" сразу перестает быть проблемой как класс.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	32. "Nginx стал самым популярным http-сервером в Рунете"	+4 +/–
	Сообщение от Аноним (??) on 10-Окт-12, 19:46
	> Глухо лишь пока школьник с мобилки не пофлудит коннекциями, положив с своего > телефона огроменный сервак в одно рыло :). После чего апач очень > быстро идет лесом, особенно если сайт подразумевает зарабатывание денег, как интернет-магазины > например. А вот нжинкс так уже фиг завалишь. Так что "пионерский > ddos" сразу перестает быть проблемой как класс. И апач, и джинкс при наличии кривых рук можно настроить так, что завалит любой дурак. А при наличии прямых рук - оба получаются довольно живучими.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	36. "Nginx стал самым популярным http-сервером в Рунете"	–2 +/–
	Сообщение от Аноним (??) on 10-Окт-12, 19:58
	> И апач, и джинкс при наличии кривых рук можно настроить так, что завалит любой дурак. > А при наличии прямых рук - оба получаются довольно живучими. Вот только нжинкс прекрасно работает по дефолту и спокойно относится к 10 000 малоактивных соединений. Они ему вообще до лампочки. А вот апач в дефолтовом виде сдохнет страшной смертью и/или будет вынужден послать большинство юзеров. Там есть менее галиымые воркеры, но они все экспериментальные и с кучей проблем. В общем в садЪ. Ничего личного, нжинкс просто работает лучше.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	46. "Nginx стал самым популярным http-сервером в Рунете"	–1 +/–
	Сообщение от Аноним (??) on 11-Окт-12, 00:08
	Для студента-виндоадмина, за копейки админящего "сервак" из списанного декстопа на убунте - может, и важно, как оно там из коробки. А для нормальных админов на нормальных задачах - _любой_ сервак на тюнить. И объем тюнинга куда больше зависит от задачи, чем от конкретного сервака.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	50. "Nginx стал самым популярным http-сервером в Рунете"	+1 +/–
	Сообщение от Аноним (??) on 11-Окт-12, 01:56
	> А для нормальных админов на нормальных задачах - _любой_ сервак на тюнить. Вау, сколько апломба. А я то думал что нормальные админы тюнят только когда это реально может дать приличную прибавку и когда это реально нужно. > И объем тюнинга куда больше зависит от задачи, чем от конкретного сервака. Да, и в ряде задач для нжинкса он нулевой или близкий к таковому. Просто потому что nginx прямо по дефолту - good enough. А вот апачу до этого как раком до китая. Дружный драп высоконагруженных сайтов на нжинкс тоже как-то прозрачно намекает на то где можно получить более вкусный результат.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	62. "Nginx стал самым популярным http-сервером в Рунете"	+1 +/–
	Сообщение от Michael Shigorin (ok) on 11-Окт-12, 11:53
	Смысл повторять 294 раза, не вникая в то, что 10k висяков до apache backend через nginx и не доберутся так вот прям все сразу? Это _разные_ софты с разными задачами.  И хорошо, что они оба есть.  Порой и в связке. :)
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	69. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 11-Окт-12, 13:11
	> что 10k висяков до apache backend через nginx и не доберутся Да уж, потому что если доберутся, на сервере случится термоядерный взрыв. То-есть, так и запишем: как фронтэнд апач по дефолту никаков. А как бэкэнд - лишь один из тучи вариантов. > Это _разные_ софты с разными задачами. Вполне типовое прикрытие попы этого неповоротливого утюга. Который однако же позиционируется опачами как именно сервак общего назначения. Как явно очерченный сервак приложений - у них томкэт на это дело есть. А по этому поводу опач втыкается повсеместно и без разбора. И потом нещадно тормозит при выполнении своих прямых обязанностей. > И хорошо, что они оба есть. Когда как. Когда заходишь на сайт, а там кучу статики вплоть до стометровых архивов и исошек грухят этим утюгом - это ну совсем не хорошо. А очень даже медленно и печально. > Порой и в связке. :) Это еще куда ни шло, однако апачевцы как-то так молчат в тряпочку о том что их сервер в качестве фронтэнда полный крап. За счет чего он пользуется совершенно незаслуженной популярностью в этом качестве. Его популярность на этой роли совершенно непропорциональна его умению качественно работать в таковой роли. И это вполне валидный повод его не жаловать. Гиря прикованная к ноге интернета.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	48. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от XoRe (ok) on 11-Окт-12, 00:29
	>> Это на передовой. А в тылах все так же глухо. > Глухо лишь пока школьник с мобилки не пофлудит коннекциями, положив с своего > телефона огроменный сервак в одно рыло :). После чего апач очень > быстро идет лесом, особенно если сайт подразумевает зарабатывание денег, как интернет-магазины > например. А вот нжинкс так уже фиг завалишь. Так что "пионерский > ddos" сразу перестает быть проблемой как класс. Предыдущий оратор как раз и говорил про frontend nginx, а backend - глухо.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	7. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от The Doctor (ok) on 10-Окт-12, 14:50
	WsgI? В рунете? У нас то точно 95% сайтов на php. :)
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	9. "Nginx стал самым популярным http-сервером в Рунете"	+6 +/–
	Сообщение от Клыкастый (ok) on 10-Окт-12, 14:54
	> WsgI? В рунете? У нас то точно 95% сайтов на php. :) nginx+php-fpm. прекрасная связка.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	11. "Nginx стал самым популярным http-сервером в Рунете"	+4 +/–
	Сообщение от Сергей (??) on 10-Окт-12, 16:15
	Именно так, и никакого Apache
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	14. "Nginx стал самым популярным http-сервером в Рунете"	+3 +/–
	Сообщение от xwild (ok) on 10-Окт-12, 17:09
	.htaccess только кто будет обрабатывать? В nginx rewrite делается прямо в конфиге сервера
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	18. "Nginx стал самым популярным http-сервером в Рунете"	+2 +/–
	Сообщение от Клыкастый (ok) on 10-Окт-12, 18:33
	> .htaccess только кто будет обрабатывать? сейчас .htaccess уже не кажется мне ни разумным, ни необходимым решением задач. > В nginx rewrite делается прямо в конфиге сервера а конфиг может быть составным. ну и с учётом того, что в nginx реврайт в принципе не нужен.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

Часть нити удалена модератором

	21. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Клыкастый (ok) on 10-Окт-12, 19:14
	> Вы бы позволили криворуким вебмастерам ваших клиентов, шаредами ни разу не занимался, посему не могу сказать. а что там совсем всё плохо?
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	37. "Nginx стал самым популярным http-сервером в Рунете"	+3 +/–
	Сообщение от Аноним (??) on 10-Окт-12, 20:01
	> а что там совсем всё плохо? Шаред по определению одна большая помойка. С одной стороны - некрофилы-админы, с другой - некрофилы-г@внари - пользователи. Да, шаред - это такая огромная клоака. Где  взлом странички Пупкина может подставлять и соседний вполне приличный сайт. В эпоху виртуалок и контейнеров экономить пару баксов может только совсем скупой дурак. И как и положено, он платит дважды.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	45. "Nginx стал самым популярным http-сервером в Рунете"	+2 +/–
	Сообщение от Аноним (??) on 10-Окт-12, 23:51
	Да, все очень плохо. Представь себе. что различные куски конфига твоего nginx'а одновременно правят несколько десятков пионеров, 3/4 которых до этого ни разу не имели дело с nginx'ом раньше. Как минимум половина хотя бы раз тупо скопипастит в свою секцию содержимое .htaccess'а из какого-нибудь шайтан-туториала. Скорее всего, конфигурация nginx'а будет невалидна 100% времени. Поставить апач в качестве апстрима гораздо безболезненнее, я уверяю.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	51. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 11-Окт-12, 01:58
	> Да, все очень плохо. Представь себе. что различные куски конфига твоего nginx'а > одновременно правят несколько десятков пионеров, 3/4 которых до этого ни разу > не имели дело с nginx'ом раньше. ... получаем эталонную помойку в виде шаред хостинга. С злыми пионер-админами за копейки, хамливым саппортом, который при минимальной нагрузке на сайт попросит вас "а ну, геть!" и так далее.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	52. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от анонимус (??) on 11-Окт-12, 02:04
	Да, это обратная сторона медали, которая практически неизбежна. С другой стороны, стоит ли расчитывать на высокое качество услуг за 800-2000 р. в год?
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	54. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 11-Окт-12, 02:13
	> ли расчитывать на высокое качество услуг за 800-2000 р. в год? Ну так я и говорю - шаред это примерно как общественный туалет, но только в IT :)
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	76. "Nginx стал самым популярным http-сервером в Рунете"	+1 +/–
	Сообщение от Аноним (??) on 11-Окт-12, 14:10
	> Да, это обратная сторона медали, которая практически неизбежна. С другой стороны, стоит > ли расчитывать на высокое качество услуг за 800-2000 р. в год? За 2к можно взять на год XEN-хостинг на 400мгц/256мб/4GB с VNC-консолью. И поднимай себе свои генты, нжынксы, увсги и фпм =)
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	92. "Nginx стал самым популярным http-сервером в Рунете"	+1 +/–
	Сообщение от Аноним (??) on 11-Окт-12, 23:31
	За 2к в год? Где?
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	94. "Nginx стал самым популярным http-сервером в Рунете"	+1 +/–
	Сообщение от Аноним (??) on 12-Окт-12, 02:55
	> За 2к в год? Где? Вот что-что а "пятибаксовых вдсок" в природе нынче как грязи.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	26. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 10-Окт-12, 19:22
	> .htaccess только кто будет обрабатывать? В nginx rewrite делается прямо в конфиге сервера Конь в пальто. К черту лишние доступы к файловой системе. Хотя если хочется воткнуть в свой вентилятор лом - вы в вашем праве. Только не жалуйтесь что он от этого сломался.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	31. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 10-Окт-12, 19:44
	> Конь в пальто. К черту лишние доступы к файловой системе. Хотя если хочется воткнуть в свой вентилятор лом - вы в вашем праве. Только не жалуйтесь что он от этого сломался. Вот поэтому сервак без htaccess идет лесом.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	38. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 10-Окт-12, 20:12
	> Вот поэтому сервак без htaccess идет лесом. У меня лесом пошел апач. Потому что ресурсов жрет непотребно. А с нжинксом мне до балды и пионерские ддосы, хабраслэшдот эффекты и что там еще. У него еще и кэширование в статику отличное есть. Так что можно осилить слэшдот-эффект на практически любом железе.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

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

	53. "Nginx стал самым популярным http-сервером в Рунете"	+1 +/–
	Сообщение от Аноним (??) on 11-Окт-12, 02:11
	> Вам просто недостаточно старательные пионэры попадались. Вот у вас и накопился маркетинговый > буллшит вместо бесценного жизненного опыта. Но, возможно, вам еще придется познать > суровые реалии жизни. Кроме маркетингового буллшита в пользу апача (который вы тут пытаетесь втереть), я кроме всего прочего имею наглость понимать чем "машина состояний" отличается от "форков" и "тредов". Я также в состоянии оценить ресурсоемкость того или иного решения. Да, а я в курсе парадигм построения серверов, проблем C10K и прочих веселостей. Поэтому маркетинговый буллшит, как вы правильно заподозрили не пройдет ;) Для меня как-то вполне очевидно что на равном объеме ресурсов из машины состояний можно выжать намного больше чем из форков/тредов в большинстве сценариев. Д P.S.: и между прочим, существование такого продукта как "apache traffic server" довольно прозрачно намекает на то что у тормозного утюга "апач" очень даже есть проблемы в ряде сценариев. Если бы их не было, данный продукт был бы просто лишним в портфолио опачевской фаундации.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	67. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от ymkin (??) on 11-Окт-12, 12:45
	Use the htscanner, Luke http://php.net/manual/en/book.htscanner.php http://pecl.php.net/package/htscanner
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	8. "Nginx стал самым популярным http-сервером в Рунете"	+2 +/–
	Сообщение от Клыкастый (ok) on 10-Окт-12, 14:53
	так за nginx можно и IIS упрятать. Может, на самом деле давно идёт рост IIS? а вообще nginx как фронтэнд к апачу даёт преимущества, но чистый nginx+php-fpm гораздо больший потенциал имеет. если бы админы не ленились уходить с .htaccess под локейшены, надобность в апаче вообще представляется иллюзорной.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	15. "Nginx стал самым популярным http-сервером в Рунете"	–2 +/–
	Сообщение от myhand (ok) on 10-Окт-12, 17:10
	> а вообще nginx как фронтэнд к апачу даёт преимущества, но чистый nginx+php-fpm гораздо больший потенциал имеет Просветите, пожалуйста, - в чем "больший потенциал". Али боитесь "доставить" сравнением полнофункционального, гибко конфигурируемого, модульного веб-сервера с обгрызком для поддержки быдлоязыка?
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	17. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Клыкастый (ok) on 10-Окт-12, 18:30
	> Просветите, пожалуйста, - в чем "больший потенциал". 1) http://php-fpm.org/about/#why 2) http://nginx.org/ru/#basic_http_features на отдаче статики апач не просто проигрывает, он вообще это делать толком не умеет по сравнению с. медленные клиенты это вообще убийство для апача. > Али боитесь "доставить" сравнением полнофункционального, гибко конфигурируемого, модульного веб-сервера с обгрызком для поддержки быдлоязыка? два вопроса: 1) что умеет апач и не умеет nginx? 2) чем отличается быдлоязык php от небыдлоязыка php?
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	41. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 10-Окт-12, 21:19
	> 1) http://php-fpm.org/about/#why Невнятно.  Причем там "апач" и в какой колонке он там вообще. > 2) http://nginx.org/ru/#basic_http_features А это-то как вообще в php-fpm относится? > на отдаче статики апач не просто проигрывает, он вообще это делать толком не умеет Подобные заявления - обычно признак получения "образования" копипастингом готовых хавту из бложеков... К примеру, что - детишкам уже не рассказывают, что у апача есть куча разных MPM?  В т.ч. и на раздачу статики ориентированные, на проксирование и т.п. Но это лирика.  Вы 1) либо не поняли вопроса (речь шла о сравнении апача и php-fpm в роли сервера приложений, причем тут nginx?), либо 2) кроме дежурных воплей фанбоя nginx - ничего и не знаете... > медленные клиенты это вообще убийство для апача. Медленные клиенты - убийство для любого вебсервера, не ориентированного на решение очень ограниченных задач (к примеру, та же раздача статики).  Вот почему любой мало-мальски крупный проект имеет минимум двухуровневую архитектру.  Причем фронтендом к апачу может быть и тот же самый апач (чаще с другим MPM, нежели бакенд). Видимо, таки вариант 2)... > 1) что умеет апач и не умеет nginx? Да те же различные MPM-модули.  Но вообще - посмотрите, сравнить полезно: https://modules.apache.org/ https://httpd.apache.org/ Знание - сила! :) PS: И не агитируйте за советскую власть больше ;)  Все вкурсе про достоинства (и недостатки, в отличие от вас) nginx.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	43. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Куяврик on 10-Окт-12, 22:40
	> Невнятно.  Причем там "апач" и в какой колонке он там вообще. прикидываешься тупым? > А это-то как вообще в php-fpm относится? nginx+php-fpm >> на отдаче статики апач не просто проигрывает, он вообще это делать толком не умеет > Подобные заявления - обычно признак получения "образования" копипастингом готовых хавту из бложеков... т.е. аргументов нет. прекрасно, прекрасно. > К примеру, что - детишкам уже не рассказывают, что у апача есть куча разных MPM? было бы глупо со стороны апача стоять ровно, пока его объезжают > Но это лирика.  Вы 1) либо не поняли вопроса (речь шла о сравнении апача и php-fpm в роли сервера приложений, причем тут nginx?) речь шла о связке. >  Вот почему любой мало-мальски крупный проект имеет минимум двухуровневую архитектру.  Причем фронтендом к апачу может быть и тот же самый апач (чаще с другим MPM, нежели бакенд). Видимо, таки вариант 2)... >> 1) что умеет апач и не умеет nginx? > Да те же различные MPM-модули.  Но вообще - посмотрите, сравнить полезно: > https://modules.apache.org/ > https://httpd.apache.org/ http://wiki.nginx.org/Modules и что? а какой модуль отучает апача тупить и жрать память? > PS: И не агитируйте за советскую власть больше ;) не учите жить помогите материально :) >  Все вкурсе про достоинства (и недостатки, в отличие от вас) nginx. Жаль, так и не удалось послушать начальника транспортного цеха. Да, апач пилят и лечат. Это хорошо и правильно. И?
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	44. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 10-Окт-12, 23:20
	> т.е. аргументов нет. прекрасно, прекрасно. Аргументы-то там есть, только их ведь еще воспринять надо... > речь шла о связке. Вот и я к тому...  Фанбои редко обращают внимание на что-либо, кроме ключевых слов (кстати, это и по поводу аргументов: нет знакомых слов - "нет аргументов"). Вас попросили сравнить php-fpm и апач в роли бакенда. > Видимо, таки вариант 2)... Вот-вот... > http://wiki.nginx.org/Modules и что? Да ничего.  Ответ на ваш вопрос.  mpm_prefork заверните, пожалуйста для nginx.  Ах, нету...  Что, и mod_qos нету?  Упс, mod_php - и того нету... > а какой модуль отучает апача тупить и жрать память? В первую очередь - прямые руки системного администратора.  "Намеки" вам дали.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	58. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Клыкастый (ok) on 11-Окт-12, 09:30
	>> т.е. аргументов нет. прекрасно, прекрасно. > Аргументы-то там есть, только их ведь еще воспринять надо... ну чтобы их воспринять их надо изложить. а с этим, я смотрю, проблемы. >> речь шла о связке. > Вот и я к тому...  Фанбои редко обращают внимание на что-либо, кроме ключевых слов самокритично > Вас попросили сравнить php-fpm и апач в роли бакенда. Вас попросили ответить за свои слова. Чем php отличается от php. > Да ничего.  Ответ на ваш вопрос.  mpm_prefork заверните, "где мои любимые костыли!?" > nginx.  Ах, нету...  Что, и mod_qos нету? а как в апаче c постримить mp4/flv? >  Упс, mod_php - и того нету... Совсем. И это хорошо. > В первую очередь - прямые руки системного администратора.  "Намеки" вам дали. То, что апач можно заставить работать почти как nginx, это понятно. Непонятно - зачем. Шаред и htaccess? Причём второе - вообще "от лени".
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	68. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 11-Окт-12, 12:57
	>> Да ничего.  Ответ на ваш вопрос.  mpm_prefork заверните, > "где мои любимые костыли!?" prefork - не костыль, а одна из моделей обработки запросов.  Он имеет и свои достоинства (посмотрели бы как реализован тот же php-fpm), а асинхронщина nginx - свои недостатки. > а как в апаче c постримить mp4/flv? А хорошо.  В гугле забанили? >>  Упс, mod_php - и того нету... > Совсем. И это хорошо. Тем не менее, в результате этого - nginx не может быть сервером приложений (конкретно, на языке PHP).  Требуются сторонние плюшки. > То, что апач можно заставить работать почти как nginx, это понятно. Непонятно > - зачем. Шаред и htaccess? ...  ну например: 1) удобство управления.  В системе просто несколько апачей, вместо кучи программулин с различным синтаксисом конфигов. 2) наличие необходимого функционала (примеры вам приводили выше)
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	71. "Nginx стал самым популярным http-сервером в Рунете"	+1 +/–
	Сообщение от Клыкастый (ok) on 11-Окт-12, 13:39
	> prefork - не костыль, а одна из моделей обработки запросов. ок, не костыль. попытка угнаться. > Он имеет и свои достоинства (посмотрели бы как реализован тот же php-fpm), не спорю. и php-fpm не считаю венцом творения. > а асинхронщина nginx - свои недостатки. теоретически - да. практически nginx при минимальном вмешательстве позволяет с блеском решать большинство типовых задач. с блеском - это значит отлично справляясь с нагрузкой. >> а как в апаче c постримить mp4/flv? > А хорошо. среди модулей не нашёл. > Тем не менее, в результате этого - nginx не может быть сервером приложений (конкретно, на языке PHP).  Требуются сторонние плюшки. например? > ...  ну например: > 1) удобство управления. у nginx? абсолютно симметрично. >  В системе просто несколько апачей, вместо кучи программулин с различным синтаксисом конфигов. куча программулин это nginx и php-fpm? загляните в /etc. вот где куча так куча. > 2) наличие необходимого функционала (примеры вам приводили выше) при отсутствии функционала в А и наличии в Б, используем Б - никаких проблем. Основной функционал у нгинкса в наличии. Модули есть, и они прибавляются. Популяризация приведёт к более быстрому появлению отсутствующего функционала.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	74. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 11-Окт-12, 14:01
	>> Он имеет и свои достоинства (посмотрели бы как реализован тот же php-fpm), > не спорю. и php-fpm не считаю венцом творения. Было бы совсем здорово, если бы вы поинтересовались *почему* он реализован именно так, а не иначе. >> а асинхронщина nginx - свои недостатки. > теоретически - да. Нет-с.  Вполне практически. > решать большинство типовых задач. с блеском "типовые задачи" nginx - раздача статики и проксирование.  Апач в подобной роли может быть хуже, иногда раза в 1.5-2.  Зато и умеет апач больше "типовых задач". >>> а как в апаче c постримить mp4/flv? >> А хорошо. > среди модулей не нашёл. А они есть, гугл в помощь.  Регистрация модулей - дело добровольное. >> Тем не менее, в результате этого - nginx не может быть сервером приложений (конкретно, на языке PHP).  Требуются сторонние плюшки. > например? Тот же php-fpm. >> ...  ну например: >> 1) удобство управления. > у nginx? абсолютно симметрично. Ага.  Как называется директива LoadModule в nginx? :) >>  В системе просто несколько апачей, вместо кучи программулин с различным синтаксисом конфигов. > куча программулин это nginx и php-fpm? Угу.  А то вам и еще какой-то "Б" понадобится, к примеру для python. > Основной функционал у нгинкса в наличии. Модули есть, и они прибавляются. Популяризация > приведёт к более быстрому появлению отсутствующего функционала. Ну-ну.  Как какой-нибудь друпал перепишут на nginx-совской асинхронщине - вот тогда и будете хвалиться про "появится". Не, я конечно, всеми конечностями "за" - но шансы такого счастья рассматриваю как более чем скромные.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	97. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 12-Окт-12, 04:24
	> Было бы совсем здорово, если бы вы поинтересовались *почему* он реализован именно так, а не иначе. Потому что апач фаундейшн сроду ориентирован на ынтырпрайз. Где еще десяток серваков за кучу денег - да подумаешь, мелочи какие. А вот когда это из своих баблосов надо выкроить - вот тут уже озадачишься оптимизацией. И нжинкс сразу покажется очень симпатичной штукой. > Нет-с.  Вполне практически. Вполне практически ей просто не надо мешать. >> решать большинство типовых задач. с блеском > "типовые задачи" nginx - раздача статики и проксирование.   А также фронтэнд для штук типа php-fpm или чего там еще. По куче протоколов. Что покрывает почти все сценарии опача. Ну да, шареды с .htaccess негодуют. Но меня проблемы этих общественных туалетов каменного века интересуют крайне слабо, например. > Апач в подобной роли может быть хуже, иногда раза в 1.5-2. А иногда и в 100500 раз, особенно по сожранной оперативке. И да, даже если допустить что всего в 2 раза - вот вы и переплачивайте за сервера в 2 раза. А я вижу некоторую разницу, особенно когда это из своего кармана. > Зато и умеет апач больше "типовых задач". Только некоторые из них он по дефолту делает на редкость отвратно. Например отгрузка статики префорком - это ффффуууу. > А они есть, гугл в помощь.  Регистрация модулей - дело добровольное. А сколько ресурсов опач при этом выжрет? Ну, нжинксу то как машине состояний не проблема почитывать файлики да в сокеты вываливать. Даже если там 100500 юзерей привалило. Лишь бы бандвиза хватило да диски выдержали. При этом грузить проц или жрать оперативку там как-то и нечему особо. >> например? > Тот же php-fpm. Зато это нормально работает потом. А не как апач, особенно с префорками. >> у nginx? абсолютно симметрично. > Ага.  Как называется директива LoadModule в nginx? :) А никак. И фиг бы с ним. > Угу.  А то вам и еще какой-то "Б" понадобится, к примеру для python. Ну и что? Это отдельные сервера приложений как раз. > Ну-ну.  Как какой-нибудь друпал перепишут на nginx-совской асинхронщине Готовых конфигов для друпала с нжинксом - хоть отбавляй. Асинхронщина получится сама по себе. Просто потому что нжинкс и fastcgi-сервер - разные процессы и работают независимо. Так что нжинкс будет отдавать динамику по мере ее готовности со стороны пыха. Не затыкаясь на этом, не держа никаких здоровенных воркеров в памяти по этому поводу и прочая.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	102. "Nginx стал самым популярным http-сервером в Рунете"	–1 +/–
	Сообщение от myhand (ok) on 12-Окт-12, 14:07
	>> Было бы совсем здорово, если бы вы поинтересовались *почему* он реализован именно так, а не иначе. > Потому что апач фаундейшн сроду ориентирован на ынтырпрайз. Ответ неверный.  Тому есть технические причины. > Где еще десяток серваков за кучу денег - да подумаешь, мелочи какие. По сравнению со стоимостью работы *людей* - да, железо почти всегда дешевле.  Это школьников за еду в раше нанять можно, а работа профессионалов стоит дорого. >> Нет-с.  Вполне практически. > Вполне практически ей просто не надо мешать. Ну вот перенесете поддержку языка php на асинхронщину, запустите друпал на ней - тогда и поговорим о "практике"... >>> решать большинство типовых задач. с блеском >> "типовые задачи" nginx - раздача статики и проксирование. > А также фронтэнд для штук типа php-fpm или чего там еще. Это и называется "проксирование", детка. >> Апач в подобной роли может быть хуже, иногда раза в 1.5-2. > А иногда и в 100500 раз, особенно по сожранной оперативке. В мульен.  Кто больше? > даже если допустить что всего в 2 раза - вот вы и переплачивайте за сервера в 2 раза. Зато экономлю на стоимости администрирования, на работе программистов и т.п.  Кроме того, далеко не для всякого сервера именно раздача статики будет узким местом.  Так что на практике - эти "2 раза" выражаются в 0 затрат, а то еще и экономии.  Так-то, бухгалтер :D >> Зато и умеет апач больше "типовых задач". > Только некоторые из них он по дефолту делает на редкость отвратно. Ну так настройте.  Программы настраивать требуется, дефолтов на всех не напасешся. > Например отгрузка статики префорком - это ффффуууу. Для отдачи статики больше подходят другие mpm.  Да и префорк справляется, если памяти не жалко. >> А они есть, гугл в помощь.  Регистрация модулей - дело добровольное. > А сколько ресурсов опач при этом выжрет? Немного.  Дополнительная разница - оверхед памяти при создании тредов.  Качественной разницы нет - все также будет масштабироваться. >>> например? >> Тот же php-fpm. > Зато это нормально работает потом. А не как апач, особенно с префорками. Ну так может вы объясните нам предметно в чем приемущества php-fpm по сравнению с обычным префорком?  Нет?  Так ведь и знал... Скушно с вами.  Матчасти толком не знаете, одни ключевые слова да лозунги. >>> у nginx? абсолютно симметрично. >> Ага.  Как называется директива LoadModule в nginx? :) > А никак. И фиг бы с ним. А мне, как системному администратору, эта плюшка нравится.  Без перекомпиляции и кучи дублирующих пакетов в дистрибутиве (сравните в Debian: nginx-light, nginx-full, etc) - можно настроить вебсервер для самых разных задач. >> Угу.  А то вам и еще какой-то "Б" понадобится, к примеру для python. > Ну и что? Это отдельные сервера приложений как раз. Ну да.  Зачем использовать готовый prefork - напишем еще один сервер и реализуем prefork заново... >> Ну-ну.  Как какой-нибудь друпал перепишут на nginx-совской асинхронщине > Готовых конфигов для друпала с нжинксом - хоть отбавляй. Не напомните когда к nginx поддержку PHP прикрутили?  AFAIK там только пока perl (и, худо-бедно - луа, недавно).  Все остальное в костылях типа php-fpm.  И внутри этих костылей - происходит все как и прежде.  "Асинхронщина" там может только сниться. > Асинхронщина получится сама по себе. "Чудесным образом" (ц)  Ох, школота...
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	116. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 14-Окт-12, 03:17
	>> Потому что апач фаундейшн сроду ориентирован на ынтырпрайз. > Ответ неверный.  Тому есть технические причины. Посмотрим как апачу и дальше понравится текущий тренд с их "причинческими технинами". >> Где еще десяток серваков за кучу денег - да подумаешь, мелочи какие. > По сравнению со стоимостью работы *людей* - да, железо почти всегда дешевле. А потом эти люди еще и удивляются когда их просят освободить кресло... >  Это школьников за еду в раше нанять можно, а работа профессионалов стоит дорого. А вам не приходило в голову что хороший продукт кроме всего прочего не должен требовать неделю прыгания вокруг него профессионала экстра класса? Как минимум в типовой ситуации. По поводу чего громкие заявления о цене работы людей и серверов - это стимул против апача а не за него. > Ну вот перенесете поддержку языка php на асинхронщину, запустите друпал на ней > - тогда и поговорим о "практике"... Так пых в php-fpm работает совершенно асинхронно нжинксу. Пока пых генерит страницу, нжинкс может сколько угодно делать все что сочтет нужным. Например, налить файла еще десятку-другому юзерей, или что там еще кому от него надо. Асинхронность нжинкса относительно друпала налицо. >> А также фронтэнд для штук типа php-fpm или чего там еще. > Это и называется "проксирование", детка. Ой, Капитан, я вас узнал :) >> А иногда и в 100500 раз, особенно по сожранной оперативке. > В мульен.  Кто больше? Как кто? Утили для бенчмарка. Если хочется демонстративный слив префорку устроить - берем отдачу мелочи толпени клиентов и бенчмаркаем. Тихо худеем с того во сколько раз продует префорк. >> даже если допустить что всего в 2 раза - вот вы и переплачивайте за сервера в 2 раза. > Зато экономлю на стоимости администрирования, на работе программистов и т.п. А кто сказал что остальные тратят дополнительные деньги на администраторов и программистов? Лично вы? И почему вам всегда надо подгонять условия под ответ чтобы опач победил? > Кроме того, далеко не для всякого сервера именно раздача статики будет узким местом. Не для всякого, но... это довольно часто становится очень назойливой проблемой сайтов с апачом. 1) Крупные файлы префорку плохо потому что воркеры надолго заняты, а много воркеров и надолго = надо дохрена ресурсов на серваке. 2) Мелкие файлы ему плохо потому что оверхед на старт процесса большой. 3) Много конекций ему плохо, потому что опять же ресурсы жрет. 4) Пионерский ддос делаемый на коленке с практически любого канала и девайса способного к HTTP запросам убивает это УГ наповал. У плохих админов - по ауту ресурсов на серванте, у опытных - юзерам просто воркеров не достается почти никогда. С точки зрения пользователя результат одинаков. А машины состояний таким манером вообще не валятся, потому что тратят на обслуживание соединения клиента не больше чем сам клиент. Вот и получается что идеальная ситуация - если сервак ничего не делает :). А чуть что начинает делать - то это префорку не так, то вон то. Удивительно отстойный воркер. И при том дефолтный. С грозными страшилками насчет всего остального. > Так что на практике - эти "2 раза" выражаются в 0 затрат, а то еще и экономии. > Так-то, бухгалтер :D У меня строго наоборот - затраты на серваки куда меньше чем могли бы быть. Каких-то дополнительных затрат не было. Наверное потому что у меня нет цели оправдать использование той или иной программы или подогнать решение под ответ. Поневоле станешь довольно хорошим бухом, если сам за банкет платишь. > Ну так настройте.  Программы настраивать требуется, дефолтов на всех не напасешся. А вот тут мы и вспоминаем что время - деньги. Вот нжинкс хорошо работает сразу. Особенно на отдаче статики. А грабли тормозного утюга разгребать - это уже к фанатам оного. Мне от сервака надо чтобы: 1) Это работало. 2) Желательно хорошо. 3) С минимальными затратами сил и средств. 4) И не грело мне мозг. Нжинкс с этим прекрасно справляется. Зачем мне пытаться сделать конфетку из г-на, если на полке лежит готовая конфета из шоколада? У меня нет принципиальной цели вкорячить именно апач. >> Например отгрузка статики префорком - это ффффуууу. > Для отдачи статики больше подходят другие mpm.   Да, но они почему-то не считаются стабильными, по дефолту сватается префорк, а насчет более вменяемых воркеров есть масса страшилок и оговорок. Вот и получается что самый нормальный воркер для статики - нжинкс. Он вполне эффективен даже в виде "все по дефолту", это его штатное состояние. И это не эксперименты и не бета-лаб а вполне себе годное к боевому применению средство, которое не надо тестировать на неизвестные проблемы. > Да и префорк справляется, если памяти не жалко. Смотря с чем справляется. С тем чтобы тормозить и жрать ресурсы и валиться от первого же бойкого пионера осилившего ab/http_load/loic/... - да, это оно умеет. Вот только плохо когда сервак с такими мерзкими свойствами - твой. >> А сколько ресурсов опач при этом выжрет? > Немного.  Дополнительная разница - оверхед памяти при создании тредов.  Качественной > разницы нет - все также будет масштабироваться. Да, я заметил. Апач, особенно с префорком - идеально масштабируется на сервак с бесконечной оперативкой и безлимитным количеством ядер. Есть только одна проблема: у меня такого сервака почему-то нет. >> Зато это нормально работает потом. А не как апач, особенно с префорками. > Ну так может вы объясните нам предметно в чем приемущества php-fpm по > сравнению с обычным префорком?  Нет?  Так ведь и знал... Потенциально поменьше памяти жрет - если апач вгружает себя, еще кучу барахла типа модулей и прочая, то тут только пых. Хотя именно тут фундаментальной разницы во многие разы быть не обязано, если основной объем ресурсов кушает сам скрипт. Но... 1) На практически любом сайте есть статика. Ее надо отдавать. Нжинкс это решает дешево и сердито. 2) Админить 2 серванта сложнее чем 1. А делать из апача приличную отгружалку статики - это вообще прерогатива фанатов марки. 3) Вообще-то хорошо б уметь динамику кешировать, если есть хоть малейшие опасения нарваться на вещи типа слэшдот эффекта или пионерских ддосов. У нжинкса опять туз в рукаве. А апач опять предоставляет выкручиваться как умеем. Т.е. еще какая-то внешняя приблуда, с отдельной конфигурежкой и граблями. Во счастье то. > Скушно с вами.  Матчасти толком не знаете, одни ключевые слова да лозунги. А лозунг тут простой - как фронт нжинкс просто на голову лучше. А бэк с php-fpm и прочими по *gi-протоколам - ничем таким не хуже особо. Стало быть общий счет 2:1 в его пользу. Он выигрывает. >> А никак. И фиг бы с ним. > А мне, как системному администратору, эта плюшка нравится.   А мне как системному администратору нравится когда нечто работает, делает это качественно и не валится от каждого пионерского пука насмерть. > Без перекомпиляции и кучи дублирующих пакетов в дистрибутиве (сравните в Debian: > nginx-light, nginx-full, etc) - можно настроить вебсервер для самых разных задач. Не, ну не может же такой переросток состоять из вообще одних только недостатков? Если поискать то в этой куче можно и достоинства найти. Правда как по мне - мне важнее чтобы оно работало, не жрало ресурсы бочками без реально оправданной чем-то необходимости и создавало бы минимум проблем. В частности не валилось бы в миг от любых внеплановых нашествий чего попало и прочая. > и реализуем prefork заново... Fastcgi - это не префорк. Он не стартует и не прибивает процессы на каждый пук, в отличие от. На каждый пук процессы стартовал простой CGI. Это было медленно и печально. И как и префорк, это дичайше жрало ресурсы нецелевым образом. Поэтому придумали FastCGI, который от этого маразма избавили. Ну и ряд похожих по смыслу *gi протоколов, нацеленных на именно нормальные постоянно запущенные сервера приложений а не телепание с всем этим ремотно вызываемым форкбомбингом. Кстати простой CGI по каким-то таким причинам и не входит в основную часть нжинкса. Это древний и дурной синхронный протокол "запрос - старт процесса - ответ - прибивание процесса". Потенциально сие может вызывать довольно длительный клинч, сильно против природы нжинкса. Делать апач из нжинкса как раз никто не собирается, это сугубо апачевская привилегия так работать. Потому то и фаст и иные быстрые *GI-протоколы, но не слоупочный прадедушка CGI ;) >>> Ну-ну.  Как какой-нибудь друпал перепишут на nginx-совской асинхронщине >> Готовых конфигов для друпала с нжинксом - хоть отбавляй. > Не напомните когда к nginx поддержку PHP прикрутили? К нему прикрутили поддержку fastcgi и прочих *GI протоколов. Если надо чтобы работало а не демонстративно пальчики погнуть на форумах - way to go. > AFAIK там только пока perl (и, худо-бедно - луа, недавно).   Ну для фанов апача понятное дело логичным вариантом кажется только всю гадость в процесс сервера впихнуть. А потом еще и нафоркать этого, да побольше. Вот только нжинкс подразумевает совсем иной подход. И правильно делает. > Все остальное в костылях типа php-fpm. Пардон, это не костыль а протокол для взаимодействия с серверами приложений как раз. И да, в отличие от похабства с префорком, фаст может вести себя намного культурнее. В частности, протокол fastcgi подразумевает то что сервер приложений обрабатывает одним процессом множество запросов без постоянного создания и убивания процессов. Что собственно и делает его FAST. > И внутри этих костылей - происходит все как и прежде. Костыли - это как раз форкинг на каждый пук. Ремотно управляемая форкбомба, кнопка подрыва которой дадена прямиком юзеру в лапки :) > "Асинхронщина" там может только сниться. Вот как раз фастцги без проблем для себя и своих участников пропихнет например ajax-запросы оптом к постоянно работающему серверу приложений. Т.к. процесс сервера приложений не обязан рестартовать - отпадает довольно дорогая по ресурсам инициализация-деинициализация. Т.е. в принципе процессов может быть 1 или по числу ядер. Потребление ими ресурсов известно и лимитировано. А вот апач с его префорком к такому подходу отнесется весьма отрицательно. Форкать сервер приложения на каждого юзеря - морда треснет. >> Асинхронщина получится сама по себе. > "Чудесным образом" (ц)  Ох, шкoлoта... Да, шкoлота явно не читала как работает fastcgi и потому еще не осознала что костыль - это форк на запрос. А фастцги - это как раз умно и культурно сделанный протокол для серверов приложений. Который в том числе асинхронный по своей природе, т.к. не создает и не прибивает никаких процессов на каждый пшик и ориентирован на именно перманентно работающий "сервер приложений" и "фронт". Без кретинизмов в виде форкания 1000 процессов в случае когда пришло 1000 юзеров.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	49. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от XoRe (ok) on 11-Окт-12, 01:12
	>> 1) http://php-fpm.org/about/#why > Невнятно.  Причем там "апач" и в какой колонке он там вообще. Невнятно может быть от недостатка знаний. Подружить apache и php-fpm - те ещё пляски с бубном. Поэтому, если хотите apache, можно забыть про php-fpm (или приготоситься к пляскам с настройками). >> на отдаче статики апач не просто проигрывает, он вообще это делать толком не умеет > Подобные заявления - обычно признак получения "образования" копипастингом готовых хавту > из бложеков... Или признак личного опыта. Сами попробуйте отдавать статику nginx'ом - разница чуствуется даже на глаз. > К примеру, что - детишкам уже не рассказывают, что у апача есть > куча разных MPM?  В т.ч. и на раздачу статики ориентированные, > на проксирование и т.п. Можно узнать, какой MPM умеет отдавать статику так же хорошо, как nginx? >> медленные клиенты это вообще убийство для апача. > Медленные клиенты - убийство для любого вебсервера, не ориентированного на решение очень > ограниченных задач (к примеру, та же раздача статики). Расскажите, чем плохи медленные клиенты для nginx? >> 1) что умеет апач и не умеет nginx? > Да те же различные MPM-модули.  Но вообще - посмотрите, сравнить полезно: Ну давайте сравним: http://ru.wikipedia.org/wiki/Apache#.D0.9C.D1.83.D0.BB.D1.8C... Из всех перечисленных, по быстродействию лучше всего будет worker. В некоторых дистрибутивах он ставится по умолчанию при установке апача. И он сливает nginx по скорости отдачи кучи файлов - это видно на статике. itk полезен тем, что можно запускать каждый сайт под своим юзером. Но он основан на prefork, а значит не дружит с большим кол-вом запросов. Его "улучшенный" вариант, perchild, забросили, так и не осилив. Ещё есть event, его я не пробовал, возможно он будет давать хорошее быстродействие. Вы пробовали его? Расскажите об ощущениях. Больше толковых MPM я не знаю. Если знаете интересный, расскажите, или дайте ссылку. А говорить "есть такие крутые MPM, вы просто не знаете" - это не аргумент. > https://modules.apache.org/ > https://httpd.apache.org/ Да, модулей под апач больше. Это + .htaccess позволяет ему держаться там, где это необходимо. В других местах ставят nginx.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	70. "Nginx стал самым популярным http-сервером в Рунете"	–1 +/–
	Сообщение от myhand (ok) on 11-Окт-12, 13:31
	> Поэтому, если хотите apache, можно забыть про php-fpm (или приготоситься к пляскам > с настройками). Я хотел того сравнения, что попросил (apache vs php-fpm в роли бакенда).  А не ужа с ежом и агитации за nginx. > Сами попробуйте отдавать статику nginx'ом - разница чуствуется даже на глаз. Предпочитаю также и цифирки использовать.  И увы, в 99% - возвращаю взад обычное проксирование на бакенд (с кешированием или без), а ерундой с раздачей статики проксей не занимаюсь... > Можно узнать, какой MPM умеет отдавать статику так же хорошо, как nginx? Я не писал что "так же хорошо".  Разница может быть, причем раза в полтора (c worker или event).  Для каких-то специфических случаев это может оказаться существенным, а в большинстве ситуаций - "на глаз" разницу с mpm-event вы не заметите. > Расскажите, чем плохи медленные клиенты для nginx? Тем же, чем и для всех.  Ресурсы тратятся. >>> 1) что умеет апач и не умеет nginx? >> Да те же различные MPM-модули.  Но вообще - посмотрите, сравнить полезно: > Ну давайте сравним: Так не с чем сравнивать-то.  У nginx - тупо одна модель обработки запросов.  У апача их несколько. > itk полезен тем, что можно запускать каждый сайт под своим юзером. Есть масса вариантов сделать то же самое куда эффективнее (modules.apache.org, удачи).  ITK - используют по безграмотности и/или недоразумению всякие панельки. > Но он основан на prefork, а значит не дружит с большим кол-вом запросов. Вас абманули.  prefork очень замечательно "дружит" с большим количеством запросов - если его не заставляют делать глупости (напр., работать с медленными клиентами).  А беда itk совсем в другом - после обработки реквеста чайлд-то прибивается. > Вы пробовали его? Расскажите об ощущениях. Пробовал.  Ощущения хорошие. > А говорить "есть такие крутые MPM, вы просто не знаете" - это > не аргумент. Аргумент состоял в том, что в апаче MPM - есть.  Только в результате этого он умеет решать более разнообразные задачи чем nginx, без сторонних костылей.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	75. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 11-Окт-12, 14:07
	> Вас абманули.  prefork очень замечательно "дружит" с большим количеством запросов - Вот это - обман. Вам даже пришлось оговорку по этому поводу сделать. Не "медленными" клиентами, а вообще в любом случае когда клиент может надолго занять воркер. При том серваку скорость клиента неподконтрольна. Т.е. если некто по GPRS сидит - это еще не повод обуть его на доступ к сайту. Хотя поклонники апача очень любят валить с больной головы на здоровую.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	78. "Nginx стал самым популярным http-сервером в Рунете"	–1 +/–
	Сообщение от myhand (ok) on 11-Окт-12, 14:28
	>> Вас абманули.  prefork очень замечательно "дружит" с большим количеством запросов - > Вот это - обман. Вам даже пришлось оговорку по этому поводу сделать. Это не оговорка.  Разные mpm предназначены для разных задач, разного типа нагрузок.  There is no one silver bullet! > При том серваку скорость клиента неподконтрольна. Уйди школота.  В треде 100500 раз объяснили как сделать эту скорость "подконтрольной". > Хотя поклонники апача очень любят валить с больной головы на здоровую. Ключевых слов нет, знакомой копипасты конфига nginx не показали - значит "поклонник апача".  Фанбои всегда такие забавные...
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	88. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 11-Окт-12, 20:06
	> Это не оговорка.  Разные mpm предназначены для разных задач, разного типа > нагрузок.  There is no one silver bullet! На входе то что у нжинкса по сути silver bullet как раз и есть. Мало ресурсов жрет, масштабируется по числу CPU (за счет чайлдовых процессов), если надо. Статику может бочками грузить не испытывая вообще никаких проблем даже если 10 000 GPRSников исошки пипеткой будут выкачивать (ну или пионеры эмулируют этой явление - "пионерский ддос" называется). >> При том серваку скорость клиента неподконтрольна. > Уйди шкoлoта.  В треде 100500 раз объяснили как сделать эту скорость "подконтрольной". Ух ты, вы научились вливать в GPRSников быстрее чем они качают? Если Вася качает по жпрс исошку, он вынужден занять воркер на дофига времени. Как максимум можно его прогнать, но тогда он будет не обслужен, стало быть FAIL. >> Хотя поклонники апача очень любят валить с больной головы на здоровую. > Ключевых слов нет, знакомой копипасты конфига nginx не показали - значит "поклонник > апача".  Фанбои всегда такие забавные... Ну да, а "apache traffic server" апачовой фаундацией сватается чисто для красоты? :)
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	91. "Nginx стал самым популярным http-сервером в Рунете"	–1 +/–
	Сообщение от myhand (ok) on 11-Окт-12, 20:54
	>> There is no one silver bullet! > На входе то что у нжинкса по сути silver bullet как раз Повторюсь: Ты не сомневайся, ты верь! > Ух ты, вы научились вливать в GPRSников быстрее чем они качают? > Если Вася качает по жпрс исошку, он вынужден занять воркер на дофига времени. > Как максимум можно его прогнать А, вы про это?...  Ну так зачем прогонять?  Пусть качает себе в отдельной ниточке.  Качественной разницы в потреблении памяти не будет, а количественная заинтересует еще меньше. $ ps -orss,user,command 1201 1202 1204   RSS COMMAND   736 nginx: master process /usr/sbin/nginx 2484 nginx: worker process 2408 nginx: worker process $ ps -orss,user,command 1246 1250   RSS USER     COMMAND 2240 root     /usr/lib/apache2/mpm-event/apache2 -d /etc/apache2-proxy -k start 2128 www-data /usr/lib/apache2/mpm-event/apache2 -d /etc/apache2-proxy -k start Кто больше? :) > Ну да, а "apache traffic server" апачовой фаундацией сватается чисто для красоты? :) В бородатые времена (когда людей было трохи и все prefork использовали) яхи сделали.  Самим влом стало поддерживать - вот и отдали сообществу.  Использует-ли его сейчас кто-то кроме них же - хз.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	98. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 12-Окт-12, 04:41
	> Повторюсь: Ты не сомневайся, ты верь! А я верю. Своим результатам запусков ab/siege/http_load и прочих подобных на одинаковых конфигурациях. >> Как максимум можно его прогнать > А, вы про это?...  Ну так зачем прогонять?  Пусть качает себе в отдельной ниточке. Не, извините, выкраивать целую отдельную нить - морда треснет. Машина состояний вообще ничего подобного таким не выделает. Просто пихает ему данные когда он может их получать. И забивает на него если не может. Куда более многообещаюшее поведение в случае множества медленных клиентов/множественных параллельных соединений. > Качественной разницы в потреблении памяти не будет, а количественная > заинтересует еще меньше. Пардон, а еще например старт процесса или треда - достаточно ресурсоемкие операции. В некоторых сценариях это тоже начинает икаться, когда оверхед от этих вызовов начинает перевешивать остальное. > Кто больше? :) А если с 10 000 малоактивных конекций? Авторы нжинкса даже дают оценку сколько памяти будет скушано. А чем порадует апач? >> Ну да, а "apache traffic server" апачовой фаундацией сватается чисто для красоты? :) > В бородатые времена (когда людей было трохи и все prefork использовали) Так апач и по сей день префорк сватает по дефолту и там висит куча страшилок о том что все остальное - глючное и экспериментальное. Вот была мне охота глюки ловить лишний раз. > яхи сделали.  Самим влом стало поддерживать - вот и отдали сообществу. >  Использует-ли его сейчас кто-то кроме них же - хз. 1) Как минимум я видел потуги сватать сие на форумах вместо нжинкса. Зачем - я не понял. 2) Не в обиду апачам, из-за их подхода весь веб засран апачами именно с префорком. Которые легко узнаются даже на глаз благодаря своей общей слоупочности. А нжинкс быстрый просто по дефолту. Да, если вы не заметили, дефолты - решают, а делать конфетку из г-на будут далеко не все администраторы.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	104. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 12-Окт-12, 15:38
	> Не, извините, выкраивать целую отдельную нить - морда треснет. Может треснет, а может и нет.  Если бы вы поинтересовались количественной стороной дела, а не "мордами" - может и был бы толк... > Машина состояний вообще ничего подобного таким не выделает. Не таким, так другим.  И так и эдак - ресурсы растут, пропорционально числу обслуживаемых в данный момент клиентов. > Куда более многообещаюшее поведение в случае множества медленных клиентов/множественных параллельных соединений. Это может быть интересно и перспективно для конкретных проектов с высокой нагрузкой.  Не ленящихся переписать движок сайта, или написать модуль для nginx под проект.  Или ориентированных на раздачу статики. Но когда nginx позиционируют как "универсальную замену" apache - это глупо. > Пардон, а еще например старт процесса или треда - достаточно ресурсоемкие операции. Не используйте всякие виндовс :)  И выучите в документации место, где написали про то как минимизировать необходимость сих "ресурсоемких операций"... > В некоторых сценариях это тоже начинает икаться, когда оверхед от этих > вызовов начинает перевешивать остальное. Может начинает доходить?  Да, *в некоторых ситуациях* - может и каждый лишний килобайт быть на счету.  Но зачем вам неприменно Хаббл арендовать, когда вы просто хотите на большое красное пятно Юпитера своими глазами полюбоваться?  Бинокля хватит ;) > А если с 10 000 малоактивных конекций? Авторы нжинкса даже дают оценку > сколько памяти будет скушано. А чем порадует апач? Если нормально сформулировать условия задачи - можно и для апача сделать оценку.  Причем не только "авторам"... > Так апач и по сей день префорк сватает по дефолту nginx "по дефолту" вообще не умеет проксировать.  Покажите мне дистрибутив, где он "по-дефолту" настроен для чего-то кроме простой отдачи статической странички.  И что? prefork хоть как-то работает в любой роли.  Разумное и безопасное умолчание для выбора mpm, хотя подходит больше для работы в роли бакенда. > висит куча страшилок О!  Вот в этом и основная проблема фанбоев.  Их источник знаний - хавту, бложеке и "страшилки". > А нжинкс быстрый просто по дефолту. А у меня на каждом сервере "по дефолту" он будет просто запросы терять.  Ибо worker_process - 1, а worker_connections - 512...  Маловато будет. > Да, если вы не заметили, дефолты Дефолтов на каждого школьника не напасешся.  А системные администраторы в курсе необходимости настройки ПО под задачи.  Вот почему и не кричат "nginx - г-но".
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	117. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 14-Окт-12, 04:07
	> Может треснет, а может и нет.  Если бы вы поинтересовались количественной > стороной дела, а не "мордами" - может и был бы толк... Меня "может" как-то не очень устраивает. Как ленивый админ я люблю работающие сервера и отсутствие у меня головняка. Даже в неидеальных ситуациях. >> Машина состояний вообще ничего подобного таким не выделает. > Не таким, так другим.  И так и эдак - ресурсы растут, > пропорционально числу обслуживаемых в данный момент клиентов. Да, только одно дело если это 2.5М на 10 000 малоактивных соединений и другое если это несколько гигз. Разница на несколько порядков в том сколько клиентов на даденой конфиге оно удержит, сущие мелочи, право :). Пионерия как раз успешно пользуется фактором усиления атаки, заваливая кучу здоровенных гробов чуть ли не с мобилок и нетбуков. Благодаря большой несимметрии по ресурсам на клиенте и сервере - можно даже так. Нжинкс на такое вообще не покупается - усиления атаки нет. >> Куда более многообещаюшее поведение в случае множества медленных >> клиентов/множественных параллельных соединений. > Это может быть интересно и перспективно для конкретных проектов с высокой нагрузкой. А также для нелюбителей тормозных сайтов, тех кто планирует обслуживать более нескольких юзерей, тех кто хочет спокойно спать а не слушать жалобы что сайт умер от пионерддоса с мобилки и прочая. >  Не ленящихся переписать движок сайта, или написать модуль для nginx > под проект.  Или ориентированных на раздачу статики. Можно и не переписывать. Работать будет. Просто свойствами того же фастцги или модулей нжинкса можно воспользоваться более оптимально по ресурсам, если это стало надо. > Но когда nginx позиционируют как "универсальную замену" apache - это глупо. Так поэтому то fastcgi и прочая и не являются костылем, как вы пытались это представить. Это как раз интерфейс к серверу приложений. Нормально вполне сделанный, имхо. Без дебилизма с форками на каждый пшик. >> Пардон, а еще например старт процесса или треда - достаточно ресурсоемкие операции. > Не используйте всякие виндовс :)   Так и не использую. Да, в unix-like fork() менее тяжелый вызов чем создание процесса в виндах. Но все-таки достаточно увесистый. Избавление от оного - очень даже воздается скоростью работы. > И выучите в документации место, где написали про то как минимизировать > необходимость сих "ресурсоемких операций"... Да... в nginx их число очень хорошо минимизировано. Прямо на уровне парадигмы сервера :). В фастцги - примерно аналогично, такой трындец не пройдет просто на уровне парадигмы протокола. > когда вы просто хотите на большое красное пятно Юпитера своими > глазами полюбоваться?  Бинокля хватит ;) Если это про опач то там рассуждают так: делать хорошую оптику в бинокле - это дорого! А давайте мы лучше возьмем китайский театральный бинокль с пластиковыми линзами, но зато запустим чувака с ним на орбиту Юпитера! Энтерпрайзы же - они богатые, на ракету скинутся. Зато на изготовлении линз бинокля вон сколько сэкономим. > Если нормально сформулировать условия задачи - можно и для апача сделать оценку. >  Причем не только "авторам"... Ну вот на сайте нжинкса для именно этой цифры дана оценка. С удовольствием послушаю сколько у вас при этом опач жрет. Особенно если с префорком :) И да, куча малоактивных соединений - это как раз вполне нормально для современных сайтов с AJAX во все поля и прочая. >> Так апач и по сей день префорк сватает по дефолту > nginx "по дефолту" вообще не умеет проксировать.  Покажите мне дистрибутив, где > он "по-дефолту" настроен для чего-то кроме простой отдачи статической странички.  И что? Простите, он поддерживает протоколы взаимодействия с бэкэндом сервера приложений. Ну и хватит с него. Пихать дрянь в процесс сервера и потом форкать в 100500 экземплярах такое красивое - прерогатива апача. Чтоб оно как раз как можно красивее дохло как только на сайт зайдет чуть побольше народа или вообще 1 пионер с бенчмаркалкой. > prefork хоть как-то работает в любой роли.  Разумное и безопасное умолчание > для выбора mpm, хотя подходит больше для работы в роли бакенда. А как по мне - отстойное и небезопасное. С точки зрения работоспособности и стабильности сервака в реальном мире. Не отличающемся особой дружественностью как известно. >> висит куча страшилок > О!  Вот в этом и основная проблема фанбоев.  Их источник знаний - хавту, > бложеке и "страшилки". Э не, не так. Только фанбои занимаются поиском жемчужин в куче гэ, на себе бетатестирую насколько вон та мегаэкспериментальная фича (не)глючит. А остальным надо чтоб работало. Без страшилок и оговорок. > А у меня на каждом сервере "по дефолту" он будет просто запросы > терять.  Ибо worker_process - 1, а worker_connections - 512...  Маловато будет. Если к более-менее дефолтному апачу с префорком делать 512 соединений - там не то что потеря запросов будет, там будет полный ахтунг. В зависимости от крутоты конфига ахтунг может варьироваться, но на половине серваков такого хватит чтобы вообще издохнуть. У админа не умудренного опытом - спасибо если ssh хотя-бы залогинится при этом, чтобы хотя-бы увидеть WTF. Это кстати заставляет апачистов иной раз заниматься всякими смешными непотребными извращениями типа борьбы с многопоточными качалками и прочими ветряными мельницами. Example: для многих модных ныне виртуалок/вдсок/... 512 процессов будет более чем за глаза чтобы там издохло все живое. А нжинкс там вообще никаких проблем не вызовет при таком раскладе. >> Да, если вы не заметили, дефолты > Дефолтов на каждого школьника не напасешся.  А системные администраторы в курсе > необходимости настройки ПО под задачи.  Вот почему и не кричат "nginx - г-но". Потому что он прилично работает с минимальными плясками с бубном. И неубиваем практически "сам по себе". По крайней мере, я видел ряд вполне успешных "ресурсных" пионерских атак на апача, вполне эффективно валившие довольно мощные серваки, при том что атакующему атака вообще не стоила можно считать что ничего. А вот чтобы кто-то так смог нжинкс уронить - не, не видел :)
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	120. "Nginx стал самым популярным http-сервером в Рунете"	–1 +/–
	Сообщение от myhand (ok) on 14-Окт-12, 15:03
	>>> Машина состояний вообще ничего подобного таким не выделает. >> Не таким, так другим.  И так и эдак - ресурсы растут, >> пропорционально числу обслуживаемых в данный момент клиентов. > > Да, только одно дело если это 2.5М на 10 000 малоактивных соединений и другое если это несколько гигз. Где несколько гиг, в вашей фантазии?  Вон выше вам вывод ps показали.  Кто больше памяти занимает и насколько - цифирки сложить сумеете? >> А у меня на каждом сервере "по дефолту" он будет просто запросы >> терять.  Ибо worker_process - 1, а worker_connections - 512...  Маловато будет. > Если к более-менее дефолтному апачу с префорком делать 512 соединений - там > не то что потеря запросов будет, там будет полный ахтунг. Не знаю что такое "более-менее" дефолт.  Вы привели пример - я привел вам пример.  Единственный разумный ответ - умолчания не предназначены для удовлетворения потребностей каждого. >> Дефолтов на каждого школьника не напасешся.  А системные администраторы в курсе >> необходимости настройки ПО под задачи.  Вот почему и не кричат "nginx - г-но". > Потому что он прилично работает с минимальными плясками с бубном. "Я нашел копипасту!!!!".  О, еще один! :) Вся минимальная "пляска с бубном" - настроить проксирование.  Бедный, тебе действительно показать конфиг апача, который умеет точно это? PS: На остальную тягомотину отвечать было просто лень.  Стопицотый анонимный гуру задолбал окончательно :(
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	128. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 16-Окт-12, 22:26
	> Где несколько гиг, в вашей фантазии?  Вон выше вам вывод ps показали. > Кто больше памяти занимает и насколько - цифирки сложить сумеете? 1) Показали явно не дефолтовый префорк. А бетатестить что-то для апача - это вы сами как-нибудь. 2) Я не вижу где там 10 000 соединений. А они были? А то опач с префорком тоже в режиме нифиганелелания мало жрет, если стартовых воркеров мало. >> Если к более-менее дефолтному апачу с префорком делать 512 соединений - там >> не то что потеря запросов будет, там будет полный ахтунг. > Не знаю что такое "более-менее" дефолт.   Это то что рекомендуют в документации и то что используется по умолчанию, если не указать чего-то иное явно. В общем то что и окажется у большинства админов на реальных сайтах. > Вы привели пример - я привел вам пример.  Единственный разумный ответ - умолчания > не предназначены для удовлетворения потребностей каждого. Да, у апача умолчания вообще не понятно для чего предназначены. Явно не для меня и моих задач. Поэтому я и обхожу его сторонкой в последнее время. > "Я нашел копипасту!!!!".  О, еще один! :) К чему тут эта порция батхерта? > Вся минимальная "пляска с бубном" - настроить проксирование. > Бедный, тебе действительно показать конфиг апача, который умеет точно это? Нафиг нужно. Нжинкс не только не нуждается в защите своего окорока всякими костылями, но еще и очень удобно в статику кеширует. Зачем мне при таких условиях с опачем связываться? > задолбал окончательно :( Как впрочем и фаны тормозного утюга.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	131. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 16-Окт-12, 22:59
	> 1) Показали явно не дефолтовый префорк. Я ясно написал что показал, зачем и почему.  Это только вы тут воюете с ветряными мельницами - и считаете что кто-то тут вам будет сравнивать потребление памяти префорком и nginx. > 2) Я не вижу где там 10 000 соединений. А они были? > А то опач с префорком тоже в режиме нифиганелелания мало жрет, > если стартовых воркеров мало. Работающий небольшой веб-проект (~30k уников).  Достаточно случайно выбранный. > Это то что рекомендуют в документации Пальцем ткните пожалуйста. > В общем то что и окажется у большинства админов на реальных сайтах. Админы тут явно были непричем...  Вы кого-то с кем-то опять путаете. > Да, у апача умолчания вообще не понятно для чего предназначены. Вообще-то - понятно.  Кстати (ВНЕЗАПНО!), это как раз и написано в документации. > Нафиг нужно. Нжинкс не только не нуждается в защите своего окорока всякими > костылями, но еще и очень удобно в статику кеширует. Зачем мне > при таких условиях с опачем связываться? Затем, чтобы узнать что и апач в этой роли очень неплохо работает.  Знание - сила, знаете-ли...
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	79. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Клыкастый (ok) on 11-Окт-12, 14:38
	> Я не писал что "так же хорошо".  Разница может быть, причем раза в полтора (c worker или event).  Для каких-то специфических случаев это может оказаться существенным, а в большинстве ситуаций - "на глаз" разницу с mpm-event вы не заметите. в полтора раза - это (на вскидку) 20 серверов вместо 30. собственно за это его и любим. > Так не с чем сравнивать-то.  У nginx - тупо одна модель обработки запросов.  У апача их несколько. > Аргумент состоял в том, что в апаче MPM - есть.  Только в результате этого он умеет решать более разнообразные задачи чем nginx, без сторонних костылей. т.е в данном случае всё сводится универсальный комбайн VS набор острозаточенных специализированных инструментов.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	80. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 11-Окт-12, 15:29
	>> Я не писал что "так же хорошо".  Разница может быть, причем раза в полтора (c worker или event).  Для каких-то специфических случаев это может оказаться существенным, а в большинстве ситуаций - "на глаз" разницу с mpm-event вы не заметите. > > в полтора раза - это (на вскидку) 20 серверов вместо 30. собственно за это его и любим. "В полтора раза" - это по скорости, в самых синтетических тестах.  В реальности - не для каждого сайта раздача статики будет узким местом вообще, так что разница заметна еще меньше. > т.е в данном случае всё сводится универсальный комбайн VS набор острозаточенных специализированных инструментов. Скорее, два разных "комбайна".  На основе одного - есть куча готовых и относительно простых решений самых разных задач.  На основе другого - можно строить порой более эффективные решения, но потрудиться при этом приходится на порядки больше, проекту нужны "несреднестатистические" администраторы и программисты. Редкий PHP-кодер осилит перенос движка на nginx-овский perl (или lua) или написание специализированного модуля nginx.  Его максимум - замена шила на мыло; например - проксирования к апачу на проксирование к php-fpm.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	81. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Клыкастый (ok) on 11-Окт-12, 15:39
	> "В полтора раза" - это по скорости, в самых синтетических тестах.   я не знаю чем вы тестили. мне попадались проекты, которые на апаче не только не летали, но требовали безобразного количества ресурсов. лечение переводом на nginx имело магический эффект. > Скорее, два разных "комбайна".  На основе одного - есть куча готовых > и относительно простых решений самых разных задач.  На основе другого > - можно строить порой более эффективные решения, да не порой. можно. просто - можно. и никаких сверспособностей это не требует. правда есть одна засада. вот если проект на данных мощностях упёрся в потолок и на нгинксе, вот тогда... > проекту нужны "несреднестатистические" администраторы и программисты. ...проекту нужны "несреднестатистические" администраторы и программисты. > Редкий PHP-кодер осилит перенос движка на nginx-овский perl (или lua) или написание > специализированного модуля nginx. редкий это слабо сказано. я бы мог подрассказать от чего некоторых отучать пришлось в php/mysql. какой к чертям перл. какой модуль... > например - проксирования к апачу на проксирование к php-fpm. прекрасно работающая связка :) вплоть до того, что сайтики на локалхостиках типа систем мониторинга и планирования давно уж ставлю на этой связке.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	82. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 11-Окт-12, 15:56
	>> "В полтора раза" - это по скорости, в самых синтетических тестах. > я не знаю чем вы тестили. Руками.  siege, даже ab - для статики за глаза хватит. > мне попадались проекты, которые на апаче > не только не летали, но требовали безобразного количества ресурсов. лечение переводом > на nginx имело магический эффект. Не пробовали настроить апач?  В частности, установить перед ним прокси хотя бы из того же апача.  Думаю, получили бы ровно тот же эффект.  Копипасты, видать, готовой не нашлось...  Печально. Так что здесь проблема была не в отсутствии nginx, а в отсутствии нормального администратора.  Самое печальное, что эта проблема и сохранилась - ведь, судя по треду, смысла своих действий вы не понимаете напроч... > да не порой. можно. просто - можно. Ты не сомневайся, ты верь! (с) > редкий это слабо сказано. я бы мог подрассказать от чего некоторых отучать > пришлось в php/mysql. какой к чертям перл. какой модуль... А говорите "можно"... >> например - проксирования к апачу на проксирование к php-fpm. > прекрасно работающая связка :) Да работать-то она - работает.  А вот чем лучше php-fpm на месте апача - вы так и не удосужились нам смертным объяснить.  Несмотря на настойчивые просьбы....
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	85. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от анон on 11-Окт-12, 19:26
	>А вот чем лучше php-fpm на месте апача - вы так и не удосужились нам смертным объяснить.  Несмотря на настойчивые просьбы.... Не объяснит :) Первое правило демагога: не отвечай на неудобный вопрос, просто игнорируй.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	87. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 11-Окт-12, 19:36
	> Не объяснит :) Ну я попробую: опач держит в своем процессе кроме пыха еще навалом всякого барахла. За счет чего вполне может быть жирнее по памяти чем php-fpm где кроме собственно пыхпыха ничего и нет.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	89. "Nginx стал самым популярным http-сервером в Рунете"	–1 +/–
	Сообщение от myhand (ok) on 11-Окт-12, 20:18
	> Ну я попробую: опач держит в своем процессе кроме пыха еще навалом > всякого барахла. За счет чего вполне может быть жирнее по памяти > чем php-fpm где кроме собственно пыхпыха ничего и нет. Кроме религиозных соображений - что вам мешает выкинуть это брахло?  Напоминаю, что LoadModule (в отличие от) - у апача в наличии...  Но попытка ответа - принимается.  Аргумент разумный, хоть количественных цифирек и нема. А принципиальные отличия имеются?
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	96. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 12-Окт-12, 03:22
	> Кроме религиозных соображений - что вам мешает выкинуть это брахло? Дык и выкинул. Нжинкс ресурсов кушает какие-то крохи. Php-fpm - ровно столько сколько сколько надо, без 100500 модулей на все случаи жизни. У меня нет цели принципиально пробить все стены своим лбом и сделать конфетку из г-на. >  Напоминаю, что LoadModule (в отличие от) - у апача в наличии...   Ну вот вы и развлекайтесь вгрузкой/выгрузкой модулей опача, если оно вам за каким-то надо. А у меня нет цели принципиально сожрать именно вот этот кактус а не какой-то иной. То что с него оказывается можно колючки сбрить, если постараться - ну, круто. Только я не фанат поедания кактусов. > Но попытка ответа - принимается.  Аргумент разумный, хоть количественных цифирек и нема. А что - количественных? Вы времена отклика сайтов меряли? А если под нагрузкой? Нжинкс то без проблем статику палит как из пулемета покуда у сети и/или диска ресурсы еще есть. А вот например дефолтовый (и наиболее безграбельный) префорк у апача в этом плане довольно печален. > А принципиальные отличия имеются? Скорость загрузки сайта, например и обслуживаемая на энном количестве ресурсов нагрузка. Особенно если речь о статике или кешировании в статику.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	100. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 12-Окт-12, 13:34
	>> Кроме религиозных соображений - что вам мешает выкинуть это брахло? > Дык и выкинул. Не вижу.  Вместо того, чтобы сперва измерить потребление ресурсов - вы просто тупо сменили апач на php-fpm.  А был-ли мальч^W"брахло"?  Ты не сомневайся, ты верь! Ну нашли вы готовую копипасту - отчего писать кипятком что php-fpm лучше, если даже элементарно сравнить их вы не пытались? >>  Напоминаю, что LoadModule (в отличие от) - у апача в наличии... > Ну вот вы и развлекайтесь вгрузкой/выгрузкой модулей опача Штатная часть работы системного администратора - прочитать документацию, разобраться и сконфигурировать ПО.  От смены на php-fpm она никуда не денется. > А у меня нет цели принципиально сожрать именно вот > этот кактус а не какой-то иной. Могу вам только предложить не есть кактусов вовсе.  Не понимаю в какой степени ваше "остроумие" относится к обещанному сравнению php-fpm и apache? >> Но попытка ответа - принимается.  Аргумент разумный, хоть количественных цифирек и нема. > А что - количественных? Вы времена отклика сайтов меряли? Количественных: тот же размер памяти.  Да, время отклика тоже можно помярять, почему нет.  Ну и где цифирки? > Нжинкс то без проблем статику палит как из пулемета покуда > у сети и/или диска ресурсы еще есть. Фанбой опять за свое...  Детки, ну забудьте вы свой nginx - речь шла о сравнении php-fpm и apache. >> А принципиальные отличия имеются? > Скорость загрузки сайта, например и обслуживаемая на энном количестве ресурсов нагрузка. > Особенно если речь о статике или кешировании в статику. php-fpm не умеет статику отдавать.   Вообще.  Вас опять заклинило на восторги по поводу nginx.  ЗАБУДЬТЕ ПРО НЕГО.  ВООБЩЕ. Принципиальным отличием я бы назвал, к примеру, более эффективную модель обработки соединений в php-fpm.  Она там есть?  Пока вижу обычный prefork.
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	101. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Michael Shigorin (ok) on 12-Окт-12, 13:47
	Коллеги, а слабо сделать страничку в http://wiki.opennet.ru/Категория:Сравнение и разрисовать табличку известных сильных и слабых мест конкретно apache2 и nginx? :) Чтоб был полезный в качестве ссылки и дорабатываемый при изменениях обстановки материал, а не ведро напалма. Понимаю, что это сложнее -- но потому взрослым людям и предлагаю.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	105. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 12-Окт-12, 15:43
	> Коллеги, а слабо сделать страничку в http://wiki.opennet.ru/Категория:Сравнение и разрисовать > табличку известных сильных и слабых мест конкретно apache2 и nginx? :) Вы действительно думаете, что после этого прекратятся вопли "апач отстой" от владельцев vps-сок, которые поставили nginx по хавту и рады результату? > Понимаю, что это сложнее -- но потому взрослым людям и предлагаю. Намек понял, "затыкаюсь".
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	107. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Michael Shigorin (ok) on 12-Окт-12, 15:52
	> Вы действительно думаете, что после этого прекратятся вопли "апач отстой" Нет, конечно -- просто будет хоть какая-то возможность обратить их в конструктивное русло: "а давайте-ка по пунктам и если есть что поправить по существу, пишите". :) > Намек понял, "затыкаюсь". Да нет же, что Вы. :(
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	109. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 13-Окт-12, 02:41
	> Нет, конечно -- просто будет хоть какая-то возможность обратить их в конструктивное > русло: "а давайте-ка по пунктам и если есть что поправить по существу, пишите". :) А смысла в сравнении болида Формула-1 и уазика? :) И что вообще можно "возразить", к примеру, если человек просто не понимает от чего "стало летать" у него после установки nginx перед апачем?  И что супер-дупер архитектура nginx в 99.9999% случаях ровно никакого отношения к этому делу не поимела :)
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	86. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 11-Окт-12, 19:34
	> Руками.  siege, даже ab - для статики за глаза хватит. Оно и заметно - если заменить апачевского утюга на нжинкс, сайт просто преображается: после установки статика выстреливается как из базуки. Даже бенчмарков нафиг не надо - на быстром соединении разница вполне очевидна на глаз.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	90. "Nginx стал самым популярным http-сервером в Рунете"	–1 +/–
	Сообщение от myhand (ok) on 11-Окт-12, 20:20
	Уймитесь, вьюнош :)  Восторженные выделения ваших слюнных желез скоро долетят до клавиатур присутствующих :D
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	95. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 12-Окт-12, 03:04
	> Уймитесь, вьюнош :)  Восторженные выделения ваших слюнных желез скоро долетят до > клавиатур присутствующих :D А вы время отклика сайта тестировали? А то с апачем и префорком при приличной нагрузке оно довольно конское. Т.е. юзер в неудачных случаях будет долго ждать пока для него освободится воркер. У машин состояний такой проблемы элементарно нет.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	99. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Клыкастый (ok) on 12-Окт-12, 12:12
	> Не пробовали настроить апач?  В частности, установить перед ним прокси хотя  бы из того же апача. Пробовали из того же nginx. эффект был. Но замена апача полностью эффект дала несравнимый. >  Думаю, получили бы ровно тот же эффект. Вы не думайте, верьте. >  Копипасты, видать, готовой не нашлось...  Печально. угу. проблема с копипастами. > Так что здесь проблема была не в отсутствии nginx, а в отсутствии нормального администратора. Если цель была во чтобы то ни стало делать всё на апаче - да. Если проблема в решении конкретной задачи - нет. >   Самое печальное, что эта проблема и сохранилась - ведь, судя по треду, смысла своих действий вы не понимаете напроч... ну теперь-то всё решительно поменялось. Теперь я знаю, что апач надо проксить апачем, nginx не нужен. >>> например - проксирования к апачу на проксирование к php-fpm. >> прекрасно работающая связка :) > Да работать-то она - работает.  А вот чем лучше php-fpm на месте апача - вы так и не удосужились нам смертным объяснить. нет-нет сначала вы про "недоязык" php по сравнению с php.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	103. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 12-Окт-12, 14:57
	>> Не пробовали настроить апач?  В частности, установить перед ним прокси хотя  бы из того же апача. > Пробовали из того же nginx. эффект был. Т.е., по сути заданного вопроса - не пробовали, не проверяли.  Жаль. >>  Думаю, получили бы ровно тот же эффект. > Вы не думайте, верьте. Я верю собственным глазам.  nginx оставил там где надо - а в основном роль фронтенда играет апач.  И настраивать проще, и собирать десяток пакетов nginx с разными модулями - не надо... >> Так что здесь проблема была не в отсутствии nginx, а в отсутствии нормального администратора. > Если цель была во чтобы то ни стало делать всё на апаче - да. Самая разумная цель - максимум эффекта при минимуме трудозатрат.  Изменив буквально все - вы вряд-ли в эту максиму уложились. > ну теперь-то всё решительно поменялось. Теперь я знаю, что апач надо проксить апачем Вы выучили новый лозунг, что ровно никак не изменило ваши знания.  Поздравляю, но "решительных изменений" не вижу. > нет-нет сначала вы про "недоязык" php по сравнению с php. Сравнивать там не с чем.  "Недоязык" PHP полностью совпадает с "языком PHP".  Критики PHP навалом, но если это единственный язык, с которым вы знакомы - что-то объяснять еще более бесполезно.  Фанбои PHP похлеще фанбоев nginx будут ;) Если обидела эта характеристика любимого языка программирования - прошу прощения за эмоциональную реплику.  Не зацикливайтесь на ней, переходите к ответу на вопрос.
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	106. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Клыкастый (ok) on 12-Окт-12, 15:45
	> Т.е., по сути заданного вопроса - не пробовали, не проверяли.  Жаль. фронтэнд - nginx, отдача статики. бэкэнд апач. > Я верю собственным глазам. симметрично. >  nginx оставил там где надо апач оставил там где надо. > в основном роль фронтенда играет апач. в основном роль фронтэнд - nginx. > собирать десяток пакетов nginx с разными модулями - не надо... штатно ставится nginx с нужными опциями. точно так же - как апач. > Самая разумная цель - максимум эффекта при минимуме трудозатрат.  Изменив буквально > все - вы вряд-ли в эту максиму уложились. давайте посчитаем трудозатраты. ставим nginx. ставим php-fpm. раскидываем конфиг. ставим апач. ставим php и mod_php. раскидываем конфиги. что не так? >> ну теперь-то всё решительно поменялось. Теперь я знаю, что апач надо проксить апачем > Вы выучили новый лозунг, это была ирония. > Сравнивать там не с чем.  "Недоязык" PHP полностью совпадает с "языком PHP". ну т.е. вы выплеснуле в запале, серьёзно относиться не нужно было. > Если обидела эта характеристика любимого языка программирования ну с какой стати мне на вас обижаться?
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	108. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 13-Окт-12, 02:38
	>> Т.е., по сути заданного вопроса - не пробовали, не проверяли.  Жаль. > фронтэнд - nginx, отдача статики. бэкэнд апач. Ну вот.  А вам говорят, что заменив фронтенд на апач - вы разницы не увидите. >> собирать десяток пакетов nginx с разными модулями - не надо... > штатно ставится nginx с нужными опциями. точно так же - как апач. К сожалению - не "точно так же".  Примеры я приводил - в дебиан сборок nginx аж три (али даже 4).  Увы, и этого оказывается мало - нужны бывают и иные комбинации модулей. Так что по гибкости включения нужного функционала - увы.  Жирный минус. > давайте посчитаем трудозатраты. > (1) ставим nginx. ставим php-fpm. раскидываем конфиг. > (2) ставим апач. ставим php и mod_php. раскидываем конфиги. > что не так? Не так то, что вы описывали ситуацию перехода на nginx.  Значит было (2), а вместо простой установки фронтенда на том же апаче (добавили конфиг сервера + скрипт для запуска - это даже автоматизировано в debian) - вы запилили целых два совершенно новых сервиса (1). >> Вы выучили новый лозунг, > это была ирония. Так какая, нафиг, разница? (с) >> Сравнивать там не с чем.  "Недоязык" PHP полностью совпадает с "языком PHP". > ну т.е. вы выплеснуле в запале, серьёзно относиться не нужно было. Да как хотите.  Это вне темы, в любом случае.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	114. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Клыкастый (ok) on 13-Окт-12, 21:22
	>>> Т.е., по сути заданного вопроса - не пробовали, не проверяли.  Жаль. >> фронтэнд - nginx, отдача статики. бэкэнд апач. > Ну вот.  А вам говорят, что заменив фронтенд на апач - вы разницы не увидите. А по памяти? апач её отлично кушает один, а предлагается два апача. >>> собирать десяток пакетов nginx с разными модулями - не надо... >> штатно ставится nginx с нужными опциями. точно так же - как апач. > К сожалению - не "точно так же".  Примеры я приводил - в дебиан это не проблема nginx. собственно когда тут в соседних темах и тредах я говорил о гибкости sb - вот иллюстрация. > сборок nginx аж три (али даже 4).  Увы, и этого оказывается мало - нужны бывают и иные комбинации модулей. это всего лишь опции сборки. > Так что по гибкости включения нужного функционала - увы.  Жирный минус. дебиану. > Не так то, что вы описывали ситуацию перехода на nginx. ну как бы лоханулся, описал на "с нуля". но вопроса это не снимает, чисто видоизменяет: что выбрать. > было (2), а вместо простой установки фронтенда на том же апаче > (добавили конфиг сервера + скрипт для запуска - это даже автоматизировано > в debian) - вы запилили целых два совершенно новых сервиса (1). ...и выпилили один старый. ну в случае перехода - вы правы, телодвижений явно больше. хотя в нашем случае игра явно стоила свеч.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	115. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 13-Окт-12, 23:47
	>>>> Т.е., по сути заданного вопроса - не пробовали, не проверяли.  Жаль. >>> фронтэнд - nginx, отдача статики. бэкэнд апач. >> Ну вот.  А вам говорят, что заменив фронтенд на апач - вы разницы не увидите. > А по памяти? апач её отлично кушает один, а предлагается два апача. Второй из которых кушает не сильно больше nginx.  Вон даже цифирки показывал.  Не сумели сложить? :) > это не проблема nginx. собственно когда тут в соседних темах и тредах > я говорил о гибкости sb - вот иллюстрация. Простите, а чья?  Нет, я-то понимаю, что nginx не ориентирован на модель "взял готовый пакет, включил нужные модули, настроил не особо прицеливаясь выбранный mpm - и забыл". Думать нада: над кодом, над архитектурой проекта, какие модули выбрать и прикрутить, какие где лимиты вбить, какие таймауты где выставить.  То-то потом, через пару дней, неделю, месяц - хомячки с установленными nginx-ами по хавту прибегают на форумы и начинают плакаться, что у них "сайты не работают".   >> сборок nginx аж три (али даже 4).  Увы, и этого оказывается мало - нужны бывают и иные комбинации модулей. > это всего лишь опции сборки. Которые, увы, не позволяют собрать универсальный пакет. >> Так что по гибкости включения нужного функционала - увы.  Жирный минус. > дебиану. А ничего, что все ведущие коммерческие дистрибутивы - бинарные?  А "source-based" - так и остались уделом локалхост-админов, увы. Да что хорошего в этом конкретном случае они дают?  Вы что, предлагаете на каждом тазике ставить компиляторы и собирать софт?  Люди все-равно сборку делают централизованно - и вся ваша "гибкость" оказывается бессмысленной.  Собрать-ли из ebuild пакет, из спека - какая, нафиг, разница? > ...и выпилили один старый. ну в случае перехода - вы правы, телодвижений > явно больше. хотя в нашем случае игра явно стоила свеч. ты верь! PS: "чем бы дитя не тешилось..."
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	123. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Клыкастый (ok) on 15-Окт-12, 11:04
	> Второй из которых кушает не сильно больше nginx.  Вон даже цифирки > показывал.  Не сумели сложить? :) где? > Простите, а чья? бинарных пакетов. >  Нет, я-то понимаю, что nginx не ориентирован на  модель "взял готовый пакет, включил нужные модули, настроил не особо прицеливаясь выбранный mpm - и забыл". да я тоже не ориентирован на эту модель. указал что с чем собирать при сборке и всё. > Думать нада: над кодом, над архитектурой проекта, какие модули выбрать и прикрутить, > какие где лимиты вбить, какие таймауты где выставить. anyway. >  То-то потом, через пару дней, неделю, месяц - хомячки с установленными nginx-ами по > хавту прибегают на форумы и начинают плакаться, что у них "сайты не работают". у вас есть сведения что я прибегал? или мне предлагается ответить за всех хомячков? а после комбинации в два апача хомячки не прибегают? >> это всего лишь опции сборки. > Которые, увы, не позволяют собрать универсальный пакет. жирный минус пакетной системе. > А ничего, что все ведущие коммерческие дистрибутивы - бинарные? Что значит "ничего"? Если вы хотите узнать моё мнение о бинарных дистрибутивах, то я его уже говорил: да, это плохо. Удобнее в чём-то, но в принципе очень плохо. Негибко и далеко от опенсорца. С другой стороны это нормально. На рынке всегда побеждали "адаптированные посредственности". >   А "source-based" - так и остались уделом локалхост-админов, увы. хомячков всегда больше. > Да что хорошего в этом конкретном случае они дают?  Вы что, предлагаете на каждом тазике ставить компиляторы и собирать софт? Вы так говорите как будто в этом что-то страшное. > Люди все-равно сборку делают централизованно - и вся ваша "гибкость" оказывается бессмысленной. Профит от sb даже в этом случае: гибко собрали пакет с тем, с чем нужно. >  Собрать-ли из ebuild пакет, из спека - какая, нафиг, разница? Действительно. А то что пару абзацев выше с этим геморрой уже забыто. > ты верь да я померял > PS: "чем бы дитя не тешилось..." лишь бы бинари ставило.
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	124. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 15-Окт-12, 13:10
	>> Второй из которых кушает не сильно больше nginx.  Вон даже цифирки >> показывал.  Не сумели сложить? :) > где? Здесь, блин.  #91. >> Простите, а чья? > бинарных пакетов. Вы не читаете *весь* ответ целиком, прежде чем "комментировать", да?  C source-based дистрибутивами - то же самое.  Почему - написали. >>  Нет, я-то понимаю, что nginx не ориентирован на  модель "взял готовый пакет, включил нужные модули, настроил не особо прицеливаясь выбранный mpm - и забыл". > да я тоже не ориентирован на эту модель. указал что с чем > собирать при сборке и всё. И не сомневался.  Только по-хавту так делать и можно.  Скопипастил и рад по уши. >> Думать нада: над кодом, над архитектурой проекта, какие модули выбрать и прикрутить, >> какие где лимиты вбить, какие таймауты где выставить. > anyway. В очень разной степени. >>  То-то потом, через пару дней, неделю, месяц - хомячки с установленными nginx-ами по >> хавту прибегают на форумы и начинают плакаться, что у них "сайты не работают". > у вас есть сведения что я прибегал? У меня нет сведений, что вы как-то отличаетесь от подобных субъектов.  Дальнейшее только подтверждает мои предположения... > а после комбинации в два апача хомячки не прибегают? Готовых хавту я пока не видел, как того оным требуется (на русском языке, в 100500 раз растиражированных, чтобы при поиске нашли, и т.д.).  А самостоятельно слепить элементарный конфиг апача (как и nginx, впрочем) - они не в состоянии.  Вот почему не пребегают... >>> это всего лишь опции сборки. >> Которые, увы, не позволяют собрать универсальный пакет. > жирный минус пакетной системе. Собирать-то по-любому приходится.  Прочитайте в следующий раз ответ *полность*, попробуйте сперва подумать. >> А ничего, что все ведущие коммерческие дистрибутивы - бинарные? > Что значит "ничего"? Если вы хотите узнать моё мнение о бинарных дистрибутивах, > то я его уже говорил: да, это плохо. Хорошо, плохо...   Реальность в том, что source-based используются только админами локалхоста.  Вами, к примеру. > На рынке всегда побеждали "адаптированные посредственности". С такой логикой - и nginx получается для "адаптированных посредственностей".  И еще "плохо".  Логическую цепочку осилите сами? >> Да что хорошего в этом конкретном случае они дают?  Вы что, предлагаете на каждом тазике ставить компиляторы и собирать софт? > Вы так говорите как будто в этом что-то страшное. Больше глупое.  А будет у вас не два сервера, а 1k - да, страшное.  Подрастете - может поймете... >> Люди все-равно сборку делают централизованно - и вся ваша "гибкость" оказывается бессмысленной. > Профит от sb даже в этом случае: гибко собрали пакет с тем, с чем нужно. (терпение лопнуло)  Вы rpm-спек в глаза вообще видели?  Берете, редактируете - и тихо "собрали пакет с тем, чем нужно"... >>  Собрать-ли из ebuild пакет, из спека - какая, нафиг, разница? > Действительно. А то что пару абзацев выше с этим геморрой уже забыто. Геморой с *необходимостью* сборки никуда не делся.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	125. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Клыкастый (ok) on 16-Окт-12, 09:38
	> Здесь, блин.  #91. нагрузка какая на сервер? ну у нас другая статистика была. > И не сомневался.  Только по-хавту так делать и можно.  Скопипастил и рад по уши. кубическая сила. что копипастить-то? галки в сборке портов? конфиги nginx? там всё ясно понятно + локейшны на конкретный проект как правило собственные. > В очень разной степени. примеры? > У меня нет сведений, что вы как-то отличаетесь от подобных субъектов.   > Дальнейшее только подтверждает мои предположения... тогда прекратим? >> а после комбинации в два апача хомячки не прибегают? > Готовых хавту я пока не видел, несомненно это потому, что высокоэффективные решения доступны только элите. >> жирный минус пакетной системе. > Собирать-то по-любому приходится.  Прочитайте в следующий раз ответ *полность*, попробуйте сперва подумать. не, давайте подумать попробуете *ВЫ*. информация простая и незамысловатая. вы мне говорите что у вас есть проблемы со сборкой с нужными опциями. я вам говорю что в sb нет проблем со сборкой с нужными опциями. > Хорошо, плохо...   Реальность в том, что source-based используются только админами  локалхоста.  Вами, к примеру. и 30% серверов в рунете. >> На рынке всегда побеждали "адаптированные посредственности". > С такой логикой - и nginx получается для "адаптированных посредственностей". притянуто за уши. > И еще "плохо".  Логическую цепочку осилите сами? легко. таквова она - логика. GIGO. расшифровать? > Больше глупое.  А будет у вас не два сервера, а 1k > - да, страшное.  Подрастете - может поймете... около 200 в течении 4 лет и? > (терпение лопнуло)  Вы rpm-спек в глаза вообще видели?  Берете, редактируете > - и тихо "собрали пакет с тем, чем нужно"... вот такая она двойная мораль. выставить галки в сборке портов это сложно, а редактировать rpm - нормально. фанбои - такие фанбои. > Геморой с *необходимостью* сборки никуда не делся. сборка является геморроем исключительно у фанбоев бинарных пакетов. причём редактирование rpm-ов у них это не геморрой. а галки выставить - геморрой.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	126. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 16-Окт-12, 18:43
	>> Здесь, блин.  #91. > нагрузка какая на сервер? Приблизительно одинаковая. > ну у нас другая статистика была. Вы не знали о существовании mpm-event.  Откуда "другая статистика", да еще с ним? >> И не сомневался.  Только по-хавту так делать и можно.  Скопипастил и рад по уши. > кубическая сила. что копипастить-то? Хомячки копипастят строку ./configure и конфигурационный файл nginx.  Конфиг php-fpm, если настраивают его.  Короче, все что наколбасил им радостный блоггер. >> В очень разной степени. > примеры? Были уже в треде примеры. > тогда прекратим? Как хотите.  Все равно, от дельного сравнения php-fpm с апачем (о чем вас просили) - вы давно перешли к посредственной апологетике nginx. >>> а после комбинации в два апача хомячки не прибегают? >> Готовых хавту я пока не видел, > несомненно это потому, что высокоэффективные решения доступны только элите. Отнюдь.  Просто только "элита" (вашими же словами) - беспокоится не только результатами полубессмысленных пузомерок а-ля Phoronix ("nginx рвет всех на отдаче аднаво статического файла!111"), а реальными причинами эффективности той или иной схемы (напр., создания фронтенда). "Вау-эффекта" нет, а вот прекрасная документация есть.  И, хорошо представляя себе принципы - сделать свое решение по ней может любой администратор. Или это была опять "ирония"?  Тогда астраумие у вас на троечку... > не, давайте подумать попробуете *ВЫ*. информация простая и незамысловатая. вы мне говорите > что у вас есть проблемы со сборкой с нужными опциями. я вам говорю что в sb нет проблем со сборкой с нужными опциями. Проблема не с пересборкой.  Проблема с самой необходимость пересборки.  Что в лоб - что по лбу... В апаче я могу собрать сервер *один* раз, а дальше подключать модули без необходимости.  Вы предлагаете это делать 100500 раз.  Это понятно?  *Как* собирать, т.е. собирать при этом deb-пакет или написать ваш любимый слакбилд, или тупо делать ./configure && make - большой роли не играет.  Ну, только для фанбоев конкретных дистрибутивов. >> Хорошо, плохо...   Реальность в том, что source-based используются только админами  локалхоста.  Вами, к примеру. > и 30% серверов в рунете. Откуда дровишки?  Десять лет работаю; даже на очень старых хостингах с фрей - все используют нормальное пакетирование.  Никто в здравом уме не собирает софт на 100500 разных серверов по-отдельности.  Если этого не делать - много от sb остается? >>> На рынке всегда побеждали "адаптированные посредственности". >> С такой логикой - и nginx получается для "адаптированных посредственностей". > притянуто за уши. Ну как же.  См. название: "nginx стал самым популярным..." Стало быть "побеждает"?  Значит ...  Продолжать уроки прикладной логики? > GIGO. расшифровать? Не, не надо.  Все правильно и самокритично изволили заметить - "разруха в головах..." (с). >> Больше глупое.  А будет у вас не два сервера, а 1k >> - да, страшное.  Подрастете - может поймете... > около 200 в течении 4 лет и? Ну вот, маловато :)  Да еще и VPS-сины поди за "сервер" учли :D А сколько из этих 200 продолжаете сопровождать? >> (терпение лопнуло)  Вы rpm-спек в глаза вообще видели?  Берете, редактируете >> - и тихо "собрали пакет с тем, чем нужно"... > вот такая она двойная мораль. выставить галки в сборке портов это сложно, > а редактировать rpm - нормально. Спек редактируется один раз (а чаще просто ключи rpmbuild используются, что и есть приблизительный эквивалент ваших "галок") - и пакеты раскидываются на 1k хостов.  Если вы точно также раскидываете бинарные пакеты *bsd - в чем разница?  А если вы на 1k хостов по-отдельности галки выставляете... > фанбои - такие фанбои. Вот именно.  Как и в случае с nginx - вы закрываете глаза на всем известные недостатки sb дистрибутивов.  Гибкость имеет свою цену, ей легко злоупотребить.  Вот почему такие дистрибутивы используют на практике реже. >> Геморой с *необходимостью* сборки никуда не делся. > сборка является геморроем исключительно у фанбоев бинарных пакетов. причём редактирование > rpm-ов у них это не геморрой. а галки выставить - геморрой. Геморой - не "галки", а необходимость дальнейшего сопровождения зоопарка серверов, где софт собран с безумным числом комбинаций этих "галок".
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	127. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Клыкастый (ok) on 16-Окт-12, 22:01
	>>> Здесь, блин.  #91. >> нагрузка какая на сервер? > Приблизительно одинаковая. с кем? >> ну у нас другая статистика была. > Вы не знали о существовании mpm-event.  Откуда "другая статистика", да еще  с ним? не совсем так. на одном проекте стоял апач с mpm-itk. "другая статистика" была в сравнении nginx+php-fpm vs чистый апач vs апач бэкэндом nginx фронтэндом. > Хомячки копипастят строку ./configure установка из тарбола? здравствуй, каменный век. не, вы уж тогда рассказывайте про скриншоты опций при сборке портов - будет правдоподобнее. > и конфигурационный файл nginx. не надо лгать, там нечего копипастить. в дефолтном конфиге есть всё. >  Конфиг php-fpm, если настраивают его. та же петрушка. хотя частенько инклюдил фрагменты конфигов с проектов того же типа и направления. > Как хотите.  Все равно, от дельного сравнения php-fpm с апачем (о > чем вас просили) - вы давно перешли к посредственной апологетике nginx. специально для фанбоев мне лениво собирать стенд. уже год занимаюсь более другим направлением и посему терзать с десяток тазиков заточеных совсем под другое смысла не вижу. ну как человек разбирающийся вы всё лично проверили и мнение имеете. хотя видя ваши сентенции относительно sb и сборки могу предположить, что вы классический "apt-get"-чик( не поймите буквально, yum туда тоже входит), который считает что сборка из srpm это удобно, а сборка из портов это адЪ. > Отнюдь.  Просто только "элита" (вашими же словами) - беспокоится не только > результатами полубессмысленных пузомерок а-ля Phoronix ("nginx рвет всех на отдаче аднаво > статического файла!111"), а реальными причинами эффективности той или иной схемы (напр., > создания фронтенда). ну я опять повторю, что проекты, дохшие на апаче nginx+php-fpm жили и не тужили. где nginx по определённым причинам был неуместен, там жил апач. ровно на двух проектах - один на дефолтном (от него только WebDAV был нужен и полтора коннекта в сутки) и один на itk. Остальные переведены на nginx+php-fpm. Причина, по которой нужно было городить стадо апачей вы обосновываете странными сентенциями, завязанными на особенности дебиановской пакетной системы. У нас была фряха и порты и установка nginx/php-fpm ничем не сложнее горотьбы из стада апачей. > Или это была опять "ирония"?  Тогда астраумие у вас на троечку... Я смотрю вы сертифицированный специалист по оценке остроумия. > Проблема не с пересборкой.  Проблема с самой необходимость пересборки.  Что > в лоб - что по лбу... для sb дистров это штатная вещь. ставится ли всё из портов или собираются пакеты и потом ставятся бинарными пакетами - эта опция 1) штатная 2) простая и обыденная 3) обязательная опция. Если у вас лично есть предубеждение против неё это ваше личное горе. Тем паче что ковырять сборку rpm/deb похоже вы мазохизмом не считаете, хотя как раз это более ресурсоёмкая операция. > В апаче я могу собрать сервер *один* раз собирайте. > Вы предлагаете это делать 100500 раз. если вы собрали один раз, будете собирать по числу обновлений. но походу у вас при сборке отрубают палец и надо экономить. в sb сборка штатная операция и пальцы не режут. > *Как* собирать, т.е. собирать при этом deb-пакет или написать ваш любимый слакбилд, или тупо делать ./configure && make - большой роли не играет. смешно. но я чуть ниже к этому вопросу вернусь. >  Ну, только для фанбоев конкретных дистрибутивов. аптгетчиков так и точно. >> и 30% серверов в рунете. > Откуда дровишки?  Десять лет работаю; даже на очень старых хостингах с > фрей - все используют нормальное пакетирование.  Никто в здравом уме не собирает софт на 100500 разных серверов по-отдельности. portmaster <ключеги> <имя_софта> если я правильно понял, у апт-гетчиков отсутсвие ключика -PP приводит к инфаркту, так? >  Если этого не делать - много от sb остается? походу тут та же проблема что с апачем. если у вас изначальная предустановка держаться за апач - замена на nginx выглядит лишним геморроем. если у вас предустановка использовать бинарный пакет - сборка на месте выглядит лишним геморроем. ну и если людей с другими предустановками объявить идиотами всё вообще выглядит замечательно. > Ну как же.  См. название: "nginx стал самым популярным..." и? > Стало быть "побеждает"?  Значит ...  Продолжать уроки прикладной логики? ах простите, я вас перебил. продолжайте конечно. - в мире популярнее апач, значит... - разница в популярности апача и нгинкса в России обуславливается... у меня есть непротиворечивое объяснение всем данным явлениям, но вашему самолюбию оно сильно не понравится. >   Все правильно и самокритично изволили заметить - "разруха в головах..." (с). да, стоит учесть что это было сказано относительно ваших волшебных упражнений с тезисами относительно популярности nginx/apache в России/в мире. > Ну вот, маловато :)  Да еще и VPS-сины поди за "сервер" учли :D да их было ровно два, под дебианом с нагрузкой в полтора коннекта в сутки. "чистые фряшники" от них плевались мне было пофиг. > А сколько из этих 200 продолжаете сопровождать? уже год ни одного. Но команда поддерживает те проекты что не проданы и собственно вполне успешно. и новые, насколько мне известно - по той же схеме. > Спек редактируется один раз (а чаще просто ключи rpmbuild используются, что и > есть приблизительный эквивалент ваших "галок") ну да. а роллтон приблизительный эквивалент обеда. но вот apt-geeeeeet... это же совсем, совсем другое дело. > - и пакеты раскидываются на 1k хостов.  Если вы точно также раскидываете бинарные пакеты *bsd - в чем разница? я не знаю что вы называете раскидыванием пакетов. есть порты и штатный способ установки, как бинарных пакетов так и исходников. как в ручном так и в автоматическом режиме. как с дефолтными опциями так и с заданными. на 1k тазиков отправляется команда поставить то-то с тем-то. это всего лишь разные ключики portmaster. Ну ваш yum/apt-get приблизительный аналог. ну то есть пофиг как оно ставится. > Вот именно.  Как и в случае с nginx - вы закрываете глаза на всем известные недостатки sb дистрибутивов. во прикол. т.е. вы мне плачетесь что у вас в бебиане собрать nginx с нужными опциями это проблема. я вам говорю что в sb  это штатно, легко и прозрачно. вы мне возражаете что ручная правка спеков это здорово и также легко и тут же говорите что это известный недостаток sb. количество взаимоисключающих пунктов зашкаливает. у меня есть три объяснения: - вы нездоровы. - вы пристрастны. - у нас разные оценки слова "легко". третье может быть следствием второго или наоборот. >   Гибкость имеет свою цену, ей легко злоупотребить.  Вот почему такие дистрибутивы используют на практике реже. вот тут я понимаю о чём вы. но считаю, что ограничениями злоупотребляют чаще. > Геморой - не "галки", а необходимость дальнейшего сопровождения зоопарка серверов, где софт собран с безумным числом комбинаций этих "галок". раскройте тезис. в чём геморрой. portmaster обновляет софт с учётом опций. я намеренно не акцентирую внимание на том, что "безумное число" это простая спекуляция и количество вариантов - ровно по числу "софтозадач". и намеренно не раскрываю ставится софт из пакетов или из исходников, потому что это абсолютно индифферентно.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	132. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 16-Окт-12, 23:55
	>> Приблизительно одинаковая. > с кем? Друг с другом. >>> ну у нас другая статистика была. >> Вы не знали о существовании mpm-event.  Откуда "другая статистика", да еще  с ним? > не совсем так. на одном проекте стоял апач с mpm-itk. Сравнили ужа с ежом...   :D > "другая статистика" была в сравнении nginx+php-fpm vs чистый апач vs апач бэкэндом > nginx фронтэндом. Ну да.  Т.е. просто добавить фронтенд к "чистому апача" (из того же "чистого апача") - не догадались.  Либо не попробовали. >> Хомячки копипастят строку ./configure > установка из тарбола? здравствуй, каменный век. не, вы уж тогда рассказывайте Что вижу - то пою. > скриншоты опций при сборке портов - будет правдоподобнее. Про порты - и на *bsd уже не всякий знает.  Не говоря уже о linux.   >> и конфигурационный файл nginx. > не надо лгать, там нечего копипастить. в дефолтном конфиге есть всё. Ну как?  Проксирование даже настроить, к примеру.  В каком это дистрибутиве в "дефолтном конфиге" есть такое? - Обычно только статическую страничку кажет. >> Как хотите.  Все равно, от дельного сравнения php-fpm с апачем (о >> чем вас просили) - вы давно перешли к посредственной апологетике nginx. > > специально для фанбоев мне лениво собирать стенд. Да аллах с ним, со стендом.  Вы хоть теоретически приемущества php-fpm поясните.  Пока - глухо.  Запросы обрабатывает - точь в точь как префорк.  Накопали разве что (покуда мифическое) приемущество в экономии памяти, благодаря исключению "лишнего".  А вот с цифирой - туго. А я полагаю, что "лишнего" будет поболее в жирном PHP с кучей бесполезных модулей.  Именно этот "жир" - основной потребитель памяти у апача в роли бакенда.  Ровно никуда он не денется. > ну я опять повторю, что проекты, дохшие на апаче Вам персонально - раз десять уже объяснили отчего они "дохли".  Ваше решение проблемы - не единственное.  То, что вы этого так и не поняли - показатель того, что основная проблема осталась (администратор). > Причина, по которой нужно было городить стадо апачей вы обосновываете странными сентенциями, завязанными на особенности дебиановской пакетной системы. Бедненький, все уже оно забыло: #108 (ответ на вашу же реплику о "трудозатратах").  Где там "особенности пакетной системы" вообще? >> Проблема не с пересборкой.  Проблема с самой необходимость пересборки.  Что >> в лоб - что по лбу... > для sb дистров это штатная вещь. Что в лоб, что по лбу...  Да плевать - штатная она или нет. >> Вы предлагаете это делать 100500 раз. > если вы собрали один раз, будете собирать по числу обновлений. Я не хочу это делать.  Хочу выбрать "галочки" один раз и забыть (написать спек, заполнить debian/ - не важно).  У апача так можно, для nginx - нет.  Теперь доступно? >>> и 30% серверов в рунете. >> Откуда дровишки?  Десять лет работаю; даже на очень старых хостингах с >> фрей - все используют нормальное пакетирование.  Никто в здравом уме не собирает софт на 100500 разных серверов по-отдельности. > portmaster <ключеги> <имя_софта> > если я правильно понял, у апт-гетчиков отсутсвие ключика -PP приводит к инфаркту,  так? Нет.  К шоку приводит то, что существуют еще "таланты", которые собирают софт на каждом из 200 (?) серверов.  Вместо того, чтобы делать это централизованно. > если у вас предустановка использовать бинарный пакет - сборка на месте > выглядит лишним геморроем. ну и если людей с другими предустановками объявить > идиотами всё вообще выглядит замечательно. Нет.  Геморой - прогрессирующий от этого счастья бардак с разнообразнейшими конфигурационными настройками ПО, отсутствия нормальной процедуры ввода обновлений.  Да и попусту - бессмысленная трата ресурсов. >> Ну как же.  См. название: "nginx стал самым популярным..." > и? Вот: >> Стало быть "побеждает"?  Значит ... ... nginx - "адаптированные посредственности".  Т.к. у вас побеждают только такие. > - в мире популярнее апач, значит... > - разница в популярности апача и нгинкса в России обуславливается... Думаю, вы осилите "навыводить" из собственных посылок логических умозаключений самостоятельно. В качестве Д/З.  Просто не воспринимайте получившиеся выводы сурьезно - ведь в исходной посылке (побеждают - посредственности) вы могли и наврать... > у меня есть непротиворечивое объяснение всем данным явлениям знаю, но не скажу (ц) ... >> А сколько из этих 200 продолжаете сопровождать? > уже год ни одного. Но команда поддерживает Ну...  Удачи им.  А вы осторожней будьте в темных подъездах и т.п. > у меня есть три объяснения: А у меня - ровно одно.   Вы не думаете над тем, что вам пишут. >>   Гибкость имеет свою цену, ей легко злоупотребить.  Вот почему такие дистрибутивы используют на практике реже. > вот тут я понимаю о чём вы. но считаю, что ограничениями злоупотребляют чаще. Это как? >> Геморой - не "галки", а необходимость дальнейшего сопровождения зоопарка серверов, где софт собран с безумным числом комбинаций этих "галок". > раскройте тезис. в чём геморрой. portmaster обновляет софт с учётом опций. Геморой - в том, что разнообразие проблем пропорционально числу сочетаний этих опций.  Оное, в частности, растет в геометрической прогрессии.  А с ней - соответствующий рост документации, рост затрат на тестирование этого зоопарка (или наплевательство на оное в той или иной мере)...   И т.д.
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	134. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Клыкастый (ok) on 17-Окт-12, 01:00
	>> не совсем так. на одном проекте стоял апач с mpm-itk. > Сравнили ужа с ежом...   :D к тому, что аллергии собственно на апач нет. > Ну да.  Т.е. просто добавить фронтенд к "чистому апача" (из того же "чистого апача") - не догадались.  Либо не попробовали. а зачем? имхо указанная связка как минимум не хуже. > Про порты - и на *bsd уже не всякий знает. да шо вы говорите! есть мнение, что множество тех, кто считает что у sb есть недостатки и тех, кто уже не знает что такое порты сииильно пересекается. > Ну как?  Проксирование даже настроить, к примеру.  В каком это > дистрибутиве в "дефолтном конфиге" есть такое? во всех вменяемых. cat /usr/local/etc/nginx/nginx.conf-dist > Да аллах с ним, со стендом.  Вы хоть теоретически приемущества php-fpm поясните.  Пока - глухо. зачем? чёрного кобеля не отмоешь добела. > А я полагаю, что "лишнего" будет поболее в жирном PHP с кучей бесполезных модулей. кто вас заставляет грузить бесполезные модули? ах да, волшебные пакетные системы. >> ну я опять повторю, что проекты, дохшие на апаче > Вам персонально - раз десять уже объяснили отчего они "дохли".  Ваше решение проблемы - не единственное. Не единственное, и не спорю. Но вы же клоните к тому что "неправильное". >   То, что вы этого так и не поняли - показатель того, что основная проблема осталась (администратор). как тонко вы понимаете вопрос. > Бедненький, все уже оно забыло: #108 (ответ на вашу же реплику о  "трудозатратах").  Где там "особенности пакетной системы" вообще? забыло, напоминаю: >>> Увы, и этого оказывается мало - нужны бывают и иные комбинации модулей. > Что в лоб, что по лбу...  Да плевать - штатная она или нет. ну вот, теперь расплевалось. >>> Вы предлагаете это делать 100500 раз. >> если вы собрали один раз, будете собирать по числу обновлений. > Я не хочу это делать.  Хочу выбрать "галочки" один раз и забыть (написать спек, заполнить debian/ - не важно).  У апача  так можно, для nginx - нет.  Теперь доступно? порты видело? хоть раз? > Нет.  К шоку приводит то, что существуют еще "таланты", которые собирают софт на каждом из 200 (?) серверов. бедняжко в шоке. какая разница на скольки серверах выполняется portmaster? какая разница есть там ключик -PP или нет? >  Вместо того, чтобы делать это централизованно. можно и централизовано. механизм ровно один и тот же. > Нет.  Геморой - прогрессирующий от этого счастья бардак с разнообразнейшими конфигурационными настройками ПО, для читающих тред вменяемых людей перевожу: если у вас на шести серверах php собран с sqlite, а на шести с mysql по разные проекты, сиречь на серваках группы 1 валяется sqlite*.so в модулях php, а на серверах 2 группы валяется mysql*.so, это бардак. >  отсутствия нормальной процедуры ввода обновлений.   а то что это ровно в такой же конфигурации обновляется - отсутствие нормальной процедуры обновлений. всё решительно меняется, если в системе обнаружен apt-get. > ... nginx - "адаптированные посредственности".  Т.к. у вас побеждают только такие. >> - в мире популярнее апач, значит... оно не осилило. >> - разница в популярности апача и нгинкса в России обуславливается... оно застеснялось. > Ну...  Удачи им.  А вы осторожней будьте в темных подъездах  и т.п. фанбоев апача стало так много? > А у меня - ровно одно.   Вы не думаете над тем, что вам пишут. если пишут и не думают - к чему напрягаться? > Геморой - в том, что разнообразие проблем пропорционально числу сочетаний этих опций.  Оное, в частности, растет в геометрической прогрессии.   беда у вас в Средиземье, эльфы.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	135. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 17-Окт-12, 02:08
	>> Ну да.  Т.е. просто добавить фронтенд к "чистому апача" (из того же "чистого апача") - не догадались.  Либо не попробовали. > а зачем? имхо указанная связка как минимум не хуже. Так зато и не сильно (если вообще) лучше.  Вот что до вас хотят донести.  А если учесть еще телодвижения, связанные с переходом - стоит-ли овчинка? >> Про порты - и на *bsd уже не всякий знает. > да шо вы говорите! шо приходилось неоднократно видеть. >> Ну как?  Проксирование даже настроить, к примеру.  В каком это >> дистрибутиве в "дефолтном конфиге" есть такое? > во всех вменяемых. > cat /usr/local/etc/nginx/nginx.conf-dist Закомментировано.  И это в лучшем случае. >> А я полагаю, что "лишнего" будет поболее в жирном PHP с кучей бесполезных модулей. > кто вас заставляет грузить бесполезные модули? Тот же, кто и вас - "лишние" модули апача. > Не единственное, и не спорю. Но вы же клоните к тому что "неправильное". Нет.  Не всегда самое оптимальное, особенно если включить затраты труда на переход, дальнейшее администрирование, работу программистов и т.п. > порты видело? хоть раз? Видело, писало.  Судя по всему, еще когда некоторые здесь присутствующие - под стол пешком ходили.  Или около того ;) >>  Вместо того, чтобы делать это централизованно. > можно и централизовано. механизм ровно один и тот же. Эффект зато может быть разный. > для читающих тред вменяемых людей перевожу: если у вас на шести серверах > php собран с sqlite, а на шести с mysql по разные > проекты, сиречь на серваках группы 1 валяется sqlite*.so в модулях php, > а на серверах 2 группы валяется mysql*.so, это бардак. Это еще не бардак - только цветочки.   Чтобы получить бардак - возьмите пять модулей и посочетайте их по два, по три, по четыре...  Итого? С подсчетом-то хоть справитесь? >>  отсутствия нормальной процедуры ввода обновлений. > а то что это ровно в такой же конфигурации обновляется - отсутствие > нормальной процедуры обновлений. Не понял.  Я про то, что чем больше у вас вариантов сборки ПО - тем призрачней возможность сперва обкатать обновление *каждого* варианта на тестовом стенде, а уж потом пустить в бой.  Так понятно? >> Геморой - в том, что разнообразие проблем пропорционально числу сочетаний этих опций.  Оное, в частности, растет в геометрической прогрессии. > беда у вас в Средиземье, эльфы. Эльфы непричем.  Математика.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	136. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Клыкастый (ok) on 17-Окт-12, 12:40
	нет никаких значимых телодвижений для перехода. Вот что до вас хотят донести. > шо приходилось неоднократно видеть. всё сходится - freebsd никто не использует, неиспользование портов вижу регулярно. жги и далее. >> cat /usr/local/etc/nginx/nginx.conf-dist > Закомментировано. Правда? ай-ай-ай. Ну это всё меняет, конечно.   > Тот же, кто и вас - "лишние" модули апача. т.е. никто. т.е. проблем нет, фанбой испугался собственных рассказов. я ж о том и толкую. >> Не единственное, и не спорю. Но вы же клоните к тому что "неправильное". > Нет.  Не всегда самое оптимальное, особенно если включить затраты труда на переход, нет никаких особых затрат труда на переход, вот о чём речь. ну кроме тех, которые волшебным образом возникают у вас с бинарным дистром и хвалёным пакетным менеджером. и тех, которые вы так тщательно придумываете. > дальнейшее администрирование, ну это да. для аптгетчиков это сложно. закомменченые конфиги и прочий ад. > работу программистов есть такой фактор. и да, он может быть ограничивающим переход с a на b. но есть основания считать что в вашем случае это просто абстрактные опасения. > и т.п. тут должен быть развёрнутый блок на тему эльфийской религии. >> порты видело? хоть раз? > Видело, писало. видимо, усилия были фантастическими и привели к травме. > Эффект зато может быть разный. это да. кривулька не встала потому что не собралась и кривулька встала, но выяснилось это в бою - разные эффекты. > по четыре...  Итого? С подсчетом-то хоть справитесь? > Я про то, что чем больше у вас вариантов сборки ПО - тем призрачней возможность сперва обкатать обновление *каждого* варианта  на тестовом стенде, а уж потом пустить в бой. с бинарями всё решительно не так, конечно. обкатка в каждом варианте подгрузки не требуется, ибо это Пакет, он пришёл из Репозитария, освящён всеми эльфийскими богами. >   Так понятно? уже давно > Эльфы непричем.  Математика. беда у вас, эльфы, с вашей математикой.
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	137. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 17-Окт-12, 13:54
	> нет никаких значимых телодвижений для перехода. Их вам перечислили.  Вы даже головой покивали - да, да, действий больше... Обратно забыло?  Чудо, а тест Тьюринга-то ты пройти способно? :D >> шо приходилось неоднократно видеть. > всё сходится - freebsd никто не использует И это тоже.  Я не писал, что "никто" - но популярности не наблюдается.  А уж тем более - роста.  И это в РФ и Украине.  А уж у буржуев - тем более... >> Закомментировано. > Правда? ай-ай-ай. Ну это всё меняет, конечно. Нужно знать что откомментировать.  А что - нет.  Этот процесс и называется конфигурацией. >> Тот же, кто и вас - "лишние" модули апача. > т.е. никто. т.е. проблем нет Т.е. ровно никаких приемуществ php-fpm перед апачем - не имеет.  Рад, что мы согласны. > нет никаких особых затрат труда на переход выше. >> Эффект зато может быть разный. > это да. кривулька не встала потому что не собралась и кривулька встала, > но выяснилось это в бою - разные эффекты. И одинаково характерные как раз для sb. >> по четыре...  Итого? С подсчетом-то хоть справитесь? > с бинарями всё решительно не так, конечно. обкатка в каждом варианте подгрузки > не требуется, ибо это Пакет, он пришёл из Репозитария, освящён всеми > эльфийскими богами. Это у вас вся надежда на "эльфов" да "богов" - а в жизни разумные люди практикуют присказку "на бога надейся, да сам не плошай".  Вот зачем тестирование, математика и прочие вумные вещи. "С бинарями" все, конечно, тоже может быть "так".  Но бардак устроить значительно сложнее.  Тут ведь не только модули PHP разные устанавливаются (что обычно делается в бинарных дистрибутивах - установкой разных пакетов) - можно и опции компилятора "покрутить" (оптимизировать, епт), и патчики разные наложить, и еще какие разные ./configure опции устроить (тот же nginx - в дебиан смастерили 3 готовых пакета, а вы могете скомбинировать хоть 33). PS: Жальш.  С простейшей арифметикой - так и не справились.
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	138. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Клыкастый (ok) on 17-Окт-12, 15:04
	>> нет никаких значимых телодвижений для перехода. > Их вам перечислили. ключевое слово "значимых" > Нужно знать что откомментировать.  А что - нет.  Этот процесс и называется конфигурацией. какой шустрый троллик. вывернулся так, что уже вроде как объясняет. > Т.е. ровно никаких приемуществ php-fpm перед апачем - не имеет.  Рад, что мы согласны. ровно никаких преимуществ апач не имеет перед php-fpm. более того экибаны из двух апачей сооружать охотников мало, а обоснования в виде "так мне меньше напрягать пакетный менеджер", "просто нету хауту" немного нелепы. всё это супротив хорошо документированной остро заточеной связки nginx+php-fpm. >> нет никаких особых затрат труда на переход > выше. хоть выше, хоть ниже. да, при переводе с апача существующих проектов телодвижения есть. совершенно простые в рамках нормальных админских функций. да, есть условия, по которым перевод может быть сложнее, нежелателен или нерентабелен. не скажу, что 2% - не знаю, не мерял. но у нас было и так, я уже писал. > И одинаково характерные как раз для sb. да, версию о святых эльфийских бинарниках мы уже слышали. и и том, как легко редактируются конфиги rpm для сборки, при этом не теряя чудодейственной эльфийской энергии - тоже. > Это у вас вся надежда на "эльфов" да "богов" у нас всё буднично. собрал - потестил - в бой. это у вас вера в то, что каноникал присылает строго торт. > "С бинарями" все, конечно, тоже может быть "так". чу! я слышал предсмертный рёв медведя с севера... > Но бардак устроить значительно сложнее. > PS: Жальш.  С простейшей арифметикой - так и не справились. Я слаб в эльфийской арифметике. Даже, видимо, в простейшей. Я не знаю в каких единицах измеряется "значительно сложнее", а при прочтении напрямую понимаю что "так же или хуже". > можно и опции компилятора "покрутить" (оптимизировать, епт), и патчики разные наложить, > и еще какие разные ./configure опции устроить *facepalm* вам никто и нигде не запрещает крутить опции ./configure. но мне сложно поверить что вы не видите разницы в удобстве между вот этим ковырянием и установкой штатно из портов. что хрень, которую вы налабали в уютном бинарном дистрике требует документирования, потому как с какими опциями вы эту кривульку собирали вы можете не вспомнить, не смочь посмотреть (простым способом или вообще) по итоговому бинарю или пакету и потом ещё это надо будет повторить. вместо готовой "документации" в /var/db/ports, и оно же готовый шаблон для "повторить номер", например, для другой архитектуры. не смешите. >  (тот же nginx -  в дебиан смастерили 3 готовых пакета я так понимаю этот экстремальный идиотизм вызывает в вашей эльфийской душе гордость? >  а вы могете скомбинировать хоть 33). да. и с одной стороны это будет всё тот же самый nginx (и во всех 33 конфигурациях обновляющийся одной командой: после тестирования или без оного), с другой стороны я получу 33 заточенных под конкретные задачи инструмента. у вас три кувалды на всё про всё. смотрите дети, это nginx. не перепутайте с nginx или, упаси Аллах! - с nginx. это, естественно, у эльфов гибкость и отсутствие  бардака. и виноват в этом бардаке nginx и лично Сысоев, но никак не негибкая система пакетов - нет.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	139. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Клыкастый (ok) on 17-Окт-12, 15:07
	:) тут было битое сообщение
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	140. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 17-Окт-12, 18:43
	> ключевое слово "значимых" Уже то, что необходимо осваивать (не путайте это с копипастом готовых конфигов для решения) аж два новых сервиса (вместо 0) - для вменяемого человека должно быть значимым.  Но вы уже давно ходите по кругу... >> Нужно знать что откомментировать.  А что - нет.  Этот процесс и называется конфигурацией. > вывернулся так, что уже вроде как объясняет. Закомментированные фрагменты не работают.  Это хоть для вас понятно? >> Т.е. ровно никаких приемуществ php-fpm перед апачем - не имеет.  Рад, что мы согласны. > ровно никаких преимуществ апач не имеет перед php-fpm. В целом, соглашусь с такой расплывчатой формулировкой.  Хотя, приемущества в администрировании вида "работает - не трожь!" вам указали. > более того экибаны из двух апачей сооружать охотников мало Да не меняйте вы с бухты-барахты апач в роле бакенда на php-fpm.  Ставьте свой nginx любимый в роли части этой "Икэбаны".  Таки в чем повод делать лишнюю работу? > всё это супротив хорошо документированной остро заточеной связки nginx+php-fpm. Чем она "хорошо документирована", если вы не знаете отличий php-fpm от префорка?  Тех самых, из-за которых "связка" столь "остро заточена".  Замените в ней php-fpm на апач - чем будет хуже? > у нас всё буднично. собрал - потестил - в бой. это у > вас вера в то, что каноникал присылает строго торт. Совсем закоротило телепатический модуль? >> PS: Жальш.  С простейшей арифметикой - так и не справились. > Я слаб в эльфийской арифметике. Даже, видимо, в простейшей. Я не знаю > в каких единицах измеряется "значительно сложнее" Вам поставили вполне конкретную задачу.  Посчитать число сочетаний, сложить.  Просто целые числы, комбинаторика. PS: Дальше утомился.  Эльфы еще какие-то...  Вы что, кроме детских сказок ничего не читаете?
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	141. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Клыкастый (ok) on 18-Окт-12, 15:41
	> Уже то, что необходимо осваивать (не путайте это с копипастом готовых конфигов для решения) аж два новых сервиса (вместо 0) - для вменяемого человека должно быть значимым. решение проблемы требует усилий. направлены они на сооружение экибан с апачами или другие решения - не принципиально. >   Но вы уже давно ходите по кругу... да. приходится вам объяснять одно и тоже. > Закомментированные фрагменты не работают.  Это хоть для вас понятно? Правда не работают? Ну кто бы мог подумать. > В целом, соглашусь с такой расплывчатой формулировкой.  Хотя, приемущества в администрировании вида "работает - не трожь!" вам указали. это - не преимущество. >> более того экибаны из двух апачей сооружать охотников мало > Да не меняйте вы с бухты-барахты апач в роле бакенда на php-fpm. да не с бухты-барахты. ну не тянул апач без подпорок нагрузку ну хоть тресни. поставили фронтэндом nginx - стало лучше, но недостаточно хорошо. убрали апач вообще - стало отлично. теперь получается, что некто в интернетах, который остро тупит и шаблонно "возражает" на тему sb желает оправданий и объяснений. забавненько. > Ставьте свой nginx любимый в роли части этой "Икэбаны".   пробовали. балласт мешает. > Таки в чем повод делать лишнюю работу? вы про сборку rpm методами "дедушка, я собираю из тарбола, как и ты"? >> всё это супротив хорошо документированной остро заточеной связки nginx+php-fpm. > Чем она "хорошо документирована", если вы не знаете отличий php-fpm от префорка? ну я же хаутушек натягал. а по вашей икэбане их нет. >  Тех самых, из-за которых "связка" столь "остро заточена".  Замените в ней php-fpm на апач - чем будет хуже? результатом. > Вам поставили вполне конкретную задачу.  Посчитать число сочетаний, сложить. Хреново, когда постановщик задачи задачу не понимает в принципе. > PS: Дальше утомился. просто слился чао.
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	142. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 18-Окт-12, 18:54
	> решение проблемы требует усилий. направлены они на сооружение экибан с апачами или > другие решения - не принципиально. Как раз принципиально, что вы просто делаете очередную шаблонную икэбану по хавту, а в чем источник проблемы - так и не разобрались. >> В целом, соглашусь с такой расплывчатой формулировкой.  Хотя, приемущества в администрировании вида "работает - не трожь!" вам указали. > это - не преимущество. Не знал.  Всегда считал мерилом своей работы - стабильно работающие системы.  А не постоянное бегание вокруг них с целью изобразить бурную деятельность... >>> более того экибаны из двух апачей сооружать охотников мало >> Да не меняйте вы с бухты-барахты апач в роле бакенда на php-fpm. > да не с бухты-барахты. ну не тянул апач без подпорок нагрузку ну > хоть тресни. поставили фронтэндом nginx - стало лучше, но недостаточно хорошо. > убрали апач вообще - стало отлично. А вот параллельно этому часом - какие-нибудь акселераторы в php не пробовали?  Кеширование, еще что-то.  Так с ваших слов - php-fpm работает значительно лучше апача.  А почему - затрудняетесь ответить. "Отлично" против "недостаточно хорошо" - все-таки выглядит слишком уж большой разницей, если вы просто заменили один бакенд на другой, работающий точь-в-точь по такому же принципу. А PHP-то хоть модулем работал с mpm-prefork? > забавненько. Многие люди в чудеса не верят.  Жаль, вас это удивляет. >> Ставьте свой nginx любимый в роли части этой "Икэбаны". > пробовали. балласт мешает. Так чем именно, цифирки будут? >>> всё это супротив хорошо документированной остро заточеной связки nginx+php-fpm. >> Чем она "хорошо документирована", если вы не знаете отличий php-fpm от префорка? > ну я же хаутушек натягал. а по вашей икэбане их нет. Про mpm-prefork есть просто штатная документация.  Так что действительно - выглядит что вы "хаутушек натягали" и не более... >>  Тех самых, из-за которых "связка" столь "остро заточена".  Замените в ней php-fpm на апач - чем будет хуже? > результатом. На техническом языке можете описать приемущества php-fpm перед апачем с префорком?  А то от вас есть заверения: продукт xyz лучше zyx.  И ссылка на мифические "наши результаты" (хз как полученные и что сравнивающие). >> Вам поставили вполне конкретную задачу.  Посчитать число сочетаний, сложить. > Хреново, когда постановщик задачи задачу не понимает в принципе. Ну да, конечно.  Но комбинаторика для других - таки не пустой звук ;)  Напрягли бы хоть разок лобные доли - а то атрофируются напрочь.
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	143. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Клыкастый (ok) on 21-Окт-12, 20:40
	>> Хреново, когда постановщик задачи задачу не понимает в принципе. > Ну да, конечно.  Но комбинаторика для других - таки не пустой звук ;) Мы сразу перейдём к комбинаторике, как только вы осознаете, что "количество комбинаций" это количество задач. И если количество задач одинаковое - то одинаковы и усилия по документации различий и апдейтам. > Напрягли бы хоть разок лобные доли - а то атрофируются напрочь. Почитайте про синдром лобной доли, роли лобных долей и не несите чушь. > На техническом языке можете описать приемущества php-fpm перед апачем с префорком?   Сходство архитектур не значит одинаковая реализация. > И ссылка на мифические "наши результаты" (хз как полученные и что сравнивающие). Уверяю вас, ваши результаты для меня не менее мифические. >> пробовали. балласт мешает. > Так чем именно, цифирки будут? от меня? нет. циферок не записывали, ибо целью было решить проблему, а не что-то кому-то доказать. ну и даже если бы они были - ведь никогда не поздно заявить что циферки некорректны или даже сфабрикованы, верно? > Про mpm-prefork есть просто штатная документация.   по nginx тоже, весьма богатая. и прекрасно комментированные конфиги. по php-fpm чуть хуже, но тоже есть. > Так что действительно - выглядит что вы "хаутушек натягали" и не более... Ну это вам как угодно. > Как раз принципиально, что вы просто делаете очередную шаблонную икэбану по хавту, > а в чем источник проблемы - так и не разобрались. Опять-таки - как вам угодно. >>> В целом, соглашусь с такой расплывчатой формулировкой.  Хотя, приемущества в администрировании вида "работает - не трожь!" вам указали. >> это - не преимущество. > Не знал.  Всегда считал мерилом своей работы - стабильно работающие системы. "Стабильно работающая" и "не трогай" это ортогональные понятия. Я бы сказал "не(до)понимаешь - не трогай без необходимости". >  А не постоянное бегание вокруг них с целью изобразить бурную деятельность... Утрирование - верное оружие демагога. > А вот параллельно этому часом - какие-нибудь акселераторы/кэширование в php не пробовали? да. apc, memcached. >  Так с ваших слов - php-fpm работает значительно лучше апача.  А почему - затрудняетесь ответить. предназначеный только для фронтэнда nginx + предназначеный только для бэкэнда php-fpm оказался лучше nginx + универсальный комбайн apache выгнутый в расклад prefork. что в принципе ожидаемо, если не нарезать в "острозаточеных" совсем жёстких ошибок. > "Отлично" против "недостаточно хорошо" - все-таки выглядит слишком уж большой разницей,  если вы просто заменили один бакенд на другой, работающий точь-в-точь по такому же принципу. принцип может быть один, реализации разные.   > А PHP-то хоть модулем работал с mpm-prefork? в смысле? работал ли модулем mod_php?
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	145. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 29-Окт-12, 14:05
	>>> Хреново, когда постановщик задачи задачу не понимает в принципе. >> Ну да, конечно.  Но комбинаторика для других - таки не пустой звук ;) > Мы сразу перейдём к комбинаторике ... Вот-вот...  Дерзайте, задачку вам дали. >> На техническом языке можете описать приемущества php-fpm перед апачем с префорком? > Сходство архитектур не значит одинаковая реализация. И?  Сказать в чем разница - по-прежнему "не шмогла"... >>> пробовали. балласт мешает. >> Так чем именно, цифирки будут? > от меня? нет. циферок не записывали Так и знал ведь... > ибо целью было решить проблему Угу, причем момент "подумать" над решением - отсутствовал как класс напроч.  Иначе бы вас заинтересовали и цифирки, и аккуратный лог изменений конфигурации (дабы за эффект "отказа от апача" не принять еще какие-то попутные изменения). Вот и получился обычный бездумный копипаст. >> А вот параллельно этому часом - какие-нибудь акселераторы/кэширование в php не пробовали? > да. apc, memcached. Ну вот (см. замечание выше про "решить проблему").  Здесь и причина изменений, а не в отказе от апача в пользу php-fpm. >>  Так с ваших слов - php-fpm работает значительно лучше апача.  А почему - затрудняетесь ответить. > предназначеный только для фронтэнда nginx + предназначеный только для бэкэнда php-fpm оказался > лучше nginx + универсальный комбайн apache выгнутый в расклад prefork. что в принципе ожидаемо Что можно ожидать от "рассуждений" на уровне маркетинговых лозунгов? :)  Добавим к "комбайну apache" эпитеты "гибко настраиваемый под задачу", "стабильный и отлаженный код" и т.п. - и "рассуждения" позволят совершенно элементарно ожидать ровно обратное тому, что вы описали... В сухом остатке: почему php-fpm столь хорош и так ли оно на самом деле вообще - вы не знаете. > принцип может быть один, реализации разные. И в чем конкретно разница? >> А PHP-то хоть модулем работал с mpm-prefork? > в смысле? работал ли модулем mod_php? Что странного?  Кто вас знает - как там с префорком вы PHP запускали...  Может через fcgi, может просто cgi :D  Про то, что вы кеширование прикручивали параллельно другим изменениям - упомянуть "забыли".
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	83. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от XoRe (ok) on 11-Окт-12, 18:19
	Вот сравнение отдачи статики nginx и apache, сделанное на моем сервере. Обращался сам к себе на 127.0.0.1 и 192.168.1.2 (все шло через loopback): http://pastebin.com/XaUD3DCJ Т.е. статику nginx отдает лучше. Особенно, кучу мелких файлов. У nginx своя модель обработки запросов, которая оказалась удачнее, чем prefork/worker. Благодаря ей, nginx может держать тысячи медленных клиентов, не пожирая ресурсов. Т.е. проксирует он тоже лучше. Не понимаю, почему вы считаете несколько MPM большим прорывом. Они построены на двух моделях: - несколько fork'ов - несколько thread'ов Спасение апача может быть только в event, который недавно перестал быть экспериментальным. Но и то - если нельзя перейти на nginx. Считать, что prefork дружит с большой нагрузкой ... Мне кажется, вы с nginx не работали.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	84. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 11-Окт-12, 19:14
	> Вот сравнение отдачи статики nginx и apache, сделанное на моем сервере. > Обращался сам к себе на 127.0.0.1 и 192.168.1.2 (все шло через loopback): > http://pastebin.com/XaUD3DCJ > Т.е. статику nginx отдает лучше. > Особенно, кучу мелких файлов. Никто и не писал что хуже.  Вот *насколько* лучше - обратите, пожалуйста, внимание.  Именно о таких "синтетических тестах" я и писал выше. Ваше сравнение, конечно, покуда не имеет никакого смысла - можно только гадать о настройках апача/nginx. > У nginx своя модель обработки запросов, которая оказалась удачнее, чем prefork/worker. > Благодаря ей, nginx может держать тысячи медленных клиентов, не пожирая ресурсов. > Т.е. проксирует он тоже лучше. Если вытереть восторженные слюни и поинтересоваться предметом - "лучше" она только на специфичных задачах.  И там кой-где mpm-event в затылок дышит... А "совсем лучше" - она там, где асинхронщину используют на всю катушку в приложении.  Но это уже не уровень рядового фанбоя ;) > Не понимаю, почему вы считаете несколько MPM большим прорывом. Потому что они позволяют решать больше разных задач без лишних костылей (тот же php-fpm). > Они построены на двух моделях: > - несколько fork'ов > - несколько thread'ов Науке такие "модели" не известны... > Считать, что prefork дружит с большой нагрузкой ... Верю своим глазам :D Ну, вы же не будете отрицать что php-fpm "дружит с большой нагрузкой"?  В чем их принципиальная разница (ну, кроме разного синтаксиса конфигурации mpm-perfork и php-fpm)? > Мне кажется, вы с nginx не работали. Когда кажется - креститься надо.   Работал, работаю и буду продолжать работать.  Там где это оправдано.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	110. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от XoRe (ok) on 13-Окт-12, 02:56
	> Никто и не писал что хуже.  Вот *насколько* лучше - обратите, > пожалуйста, внимание.  Именно о таких "синтетических тестах" я и писал > выше. Почему синтетический? Вполне приближенный к боевому. Имитация большой нагрузки на статику - закачка кучи мелких файлов. > Ваше сравнение, конечно, покуда не имеет никакого смысла - можно только гадать > о настройках апача/nginx. Приведите свое сравнение. Интересно, в каких случаях apache обгоняет nginx. > Если вытереть восторженные слюни и поинтересоваться предметом - "лучше" она только на > специфичных задачах.  И там кой-где mpm-event в затылок дышит... Ваши доводы тоже сводятся к "ну nginx мало где лучше, да и не сильно лучше, да и лучше ли". Можете конкретику привести, на каких задачах nginx сливает apache? Я свою конкретику привел - много одновременных запросов, отдача кучи статики. В том числе, медленным клиентам. > А "совсем лучше" - она там, где асинхронщину используют на всю катушку > в приложении.  Но это уже не уровень рядового фанбоя ;) А где тут фанбои? Я писал программы на C, использующие блокирующие/неблокирующие сокеты. Nginx изначально написан на использование select/epoll/... Можно, конечно, говорить, что он ограничен в способах обработки соединений. Но остальные способы медленнее. А более быстрых ещё поискать. > Потому что они позволяют решать больше разных задач без лишних костылей (тот > же php-fpm). php-fpm - костыль?) > Ну, вы же не будете отрицать что php-fpm "дружит с большой нагрузкой"? >  В чем их принципиальная разница (ну, кроме разного синтаксиса конфигурации > mpm-perfork и php-fpm)? На этом дискуссию можно закрывать. Оставлю небольшой ликбез. Интерфейс FastCGI — дальнейшее развитие технологии CGI. По сравнению с CGI является более производительным и безопасным. http://ru.wikipedia.org/wiki/FastCGI php-fpm - PHP-FPM (FastCGI Process Manager) - PHP реализация FastCGI http://ru.wikipedia.org/wiki/PHP-FPM Разница между mpm-prefork и php-fpm в том, что prefork - MPM, основанная на предварительном создании отдельных процессов, не использующая механизм threads. А php-fpm - фича последних версий php, позволяющая запускать spawner php в режиме демона. Изкоробки, с кучей настроек и т.д.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	112. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 13-Окт-12, 11:58
	> Почему синтетический? Вполне приближенный к боевому. > Имитация большой нагрузки на статику - закачка кучи мелких файлов. Потому что в "боевых условиях" - статика не часто является узким местом.  Сто раз уже писали здесь, еще повторить, чтобы дошло? >> Ваше сравнение, конечно, покуда не имеет никакого смысла - можно только гадать >> о настройках апача/nginx. > Приведите свое сравнение. "Сперва добейся".  Убил... > Можете конкретику привести, на каких задачах nginx сливает apache? Зачем мне доказывать ваш-же безумный тезис? > А где тут фанбои? В зеркало посмотрите ;)  Буду только рад, если в этом отношении ошибся относительно вас.  Но пока шансов мало... > Я писал программы на C, использующие блокирующие/неблокирующие сокеты. В курсовой? ;) > Можно, конечно, говорить, что он ограничен в способах обработки соединений. > Но остальные способы медленнее. "Можно" - говорить любую глупость.  А "нужно" говорить, что модуль nginx или тот же perl-скрипт под него - сумеет написать правильно не всякий программист. >> Потому что они позволяют решать больше разных задач без лишних костылей (тот >> же php-fpm). > php-fpm - костыль?) Да, детка.  Это просто апач с mpm-prefork.  "Без лишнего", как тут заявил один анонимный товарищ.  Что конкретно лишнее и сколько его, почему оно лишнее - он не уточнил... >> Ну, вы же не будете отрицать что php-fpm "дружит с большой нагрузкой"? >>  В чем их принципиальная разница (ну, кроме разного синтаксиса конфигурации >> mpm-perfork и php-fpm)? > На этом дискуссию можно закрывать. > Оставлю небольшой ликбез. > Интерфейс FastCGI — дальнейшее развитие технологии CGI. И что это говорит про разницу в модели обработки запросов сервером fastcgi и апачем с mpm-prefork? :)  Не, ну приятно что вы себе ликбез организовали - но на вопрос пока так и не ответили...   А эдак "различий" можно мульен накопать, начиная с разных авторов в changelog... > http://ru.wikipedia.org/wiki/PHP-FPM Не читай русскую википедию - козленочком станешь! ;) > Разница между mpm-prefork и php-fpm в том, что prefork - MPM, основанная > на предварительном создании отдельных процессов, не использующая механизм threads. Че?  И где в php-fpm нити?  А ниче что в его документации об этом ни полслова, зато постоянно идет речь о дочерних *процессах*?  А ниче что в Debian (и в большенстве разумных дистрибутивов) собирается не thread-safe PHP? > А php-fpm - фича последних версий php, позволяющая запускать spawner php в режиме демона. Совсем какая-то каша.  Ваша же ссылка: -->8-- PHP-FPM (FastCGI Process Manager) - PHP реализация FastCGI [1] Включён в состав PHP 5.3.3.[2] -->8-- Совсем грустные знания, разочаровали вы... PS: Де-факто - mpm-prefork это чуть больше чем "MPM, основанная на предварительном создании отдельных процессов".  На самом деле, он допускает и вариант статического числа процессов, и создание их "по требованию" для обработки очередного запроса.  Все как в php-fpm, правда там-то адаптивный режим работы прикрутили нормально совсем недавно.  Такие дела...
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	129. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 16-Окт-12, 22:31
	> пожалуйста, внимание.  Именно о таких "синтетических тестах" я и писал выше. Нормальный тест вполне. Отдача пнгхи в 10К размером. Чего в этом синтетического? Обратите внимание на времена отклика. Нжинкс 50% запросов отстрелил за 4 миллисекунды, как пулемет. А апач лишний раз показал себя тормозным утюгом.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	133. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 17-Окт-12, 00:07
	>> пожалуйста, внимание.  Именно о таких "синтетических тестах" я и писал выше. > Нормальный тест вполне. Отдача пнгхи в 10К размером. Чего в этом синтетического? Покажите веб-проект, который занимается одной такой глобальной задачей. > Обратите внимание на времена отклика. Нжинкс 50% запросов отстрелил за 4 миллисекунды, > как пулемет. А апач лишний раз показал себя тормозным утюгом. Настройте апач адекватно задаче сперва.  Как - сто раз в треде объясняли. nginx тупо не умеет работать в роли PHP-бакенда.  И?
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	63. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Michael Shigorin (ok) on 11-Окт-12, 11:57
	> Али боитесь "доставить" сравнением полнофункционального, гибко конфигурируемого, > модульного веб-сервера с обгрызком для поддержки быдлоязыка? Вот уж от кого бы не ожидал... Уважаемые казаки и дорогие разбойники -- может, всё-таки не стоит разводить детский сад?  Предлагаю избирательно зачистить разведённое выше, если согласны изложить по-человечески. Спасибо.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	72. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 11-Окт-12, 13:39
	> Уважаемые казаки и дорогие разбойники -- может, всё-таки не стоит разводить детский сад? Не люблю фанбоев.  Самая большая социальная засада хороших OSS проектов. > Предлагаю избирательно зачистить разведённое выше, если согласны изложить по-человечески. Хозяин-барин.  Что конкретно вы хотите, чтобы я переизложил по-человечески?
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	111. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от XoRe (ok) on 13-Окт-12, 02:58
	> Не люблю фанбоев.  Самая большая социальная засада хороших OSS проектов. Фанбои - нормальное состояние, когда всем очевидны плюсы какого-то решения. Вы же не видите кучи фанбоев IIS или lighttpd?)
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	113. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 13-Окт-12, 12:14
	>> Не люблю фанбоев.  Самая большая социальная засада хороших OSS проектов. > Фанбои - нормальное состояние, когда всем очевидны плюсы какого-то решения. Да я не спорю что "нормальное".  Моя точка зрения в том, что это *плохое* явление. There is no one silver bullet! > Вы же не видите кучи фанбоев IIS или lighttpd?) IIS - OSS проект? lighttpd достаточно популярен вне пост-СССР, и с nginx там куда меньше носятся...  А "здесь" - мало его фанбоев, скорее, по историческим причинам.  Недостаточно было копипасты хомячкам в свое время, вот и все... :)
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

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

	121. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 14-Окт-12, 15:05
	> Он проксирует ответ, буферизуя его целиком. Поэтому если ответ большой - он памяти > дофига сожрет. Это было давно, насколько я помню.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	122. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Artyshock (??) on 14-Окт-12, 19:14
	И стех самых "давно" он не развивается.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	130. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 16-Окт-12, 22:35
	> Это было давно, насколько я помню. И с тех пор это никто не чинил. Были какие-то мысли чтобы починить в 1.5 но на это забили и вообще - парням в голову ударила моча^W крутые концепции, как обычно. Что-то типа ragel state machines и прочая. И они очертя голову бросились писать лайти 2.0. Однако запала хватило не на долго и в результате они оказались в позе охотника погнавшегося за 2-я зайцами. В общем продолбали студни свой шанс. Теперь номером 3 будет нжинкс. Который чего доброго кого-нибудь выпнет с пьедестала.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	27. "Nginx стал самым популярным http-сервером в Рунете"	+2 +/–
	Сообщение от Аноним (??) on 10-Окт-12, 19:25
	> так за nginx можно и IIS упрятать. Мсье знает толк в извращениях :). Знаешь, IIS по моим наблюдениям используют обычно совсем долбанутые мышевозилы, пускающие в вебе пузыри. Такие про нжинкс обычно просто не знают. Да и культурный шок у них будет от того что там возякать мышкой не получается.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	28. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Клыкастый (ok) on 10-Окт-12, 19:27
	>> так за nginx можно и IIS упрятать. > Мсье знает толк в извращениях :). Знаешь, IIS по моим наблюдениям используют > обычно совсем долбанутые мышевозилы, пускающие в вебе пузыри. посмотри количество IIS  _в мире_. ты смелый ;)
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	30. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 10-Окт-12, 19:36
	> посмотри количество IIS  _в мире_. ты смелый ;) А я виноват что если сайт работает через пень колоду, открывается с 2-3 раза и тормозит - это надежно детектирует IIS. Особенно этим грешат корпорастивные сайты всяких асусов и гигабайтов, деланные в начале 2000-х годов и там и оставшиеся по сей день. На диалапе клинч этого барахла может и не был очень заметен, а вот на быстром эзернете разница весьма ощутима и такой сайт откровенно бесит своей слоупочностью по сравнению с нормальными. Особенно с нжинксом. Нжинкс вообще термоядерная штука: если например опач заменить на нжинкс, время отгрузки статичного жыпега падает настолько что разница видна просто на глаз.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	65. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Michael Shigorin (ok) on 11-Окт-12, 12:02
	> А я виноват что если сайт работает через пень колоду, открывается с > 2-3 раза и тормозит - это надежно детектирует IIS. Справедливости ради: - IIS нет особого смысла совать за nginx, он и так обрабатывает пулом нитей IIRC; - тот же stackoverflow.com живёт на IIS, насколько мне известно -- ну удобней так Джоэлу, и на том спасибо. И это не противоречит процитированному само по себе. :)
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	73. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 11-Окт-12, 14:01
	> - IIS нет особого смысла совать за nginx, он и так обрабатывает пулом нитей IIRC; Если это "тред на запрос" то тред конечно весит поменьше процесса, но фундаментальные грабли с тем что прилично весящая сущность на заметное время узурпируется кем-то - никуда не деваются. У машин состояний таких проблем нет. Еще я уж не знаю, может у винды проблемы с тредами или там что еще, но почему-то если сайт на IIS - грузится он обычно очень медленно а зачастую еще и не с первой попытки. Повальная беда сайтов на IIS. > - тот же stackoverflow.com живёт на IIS, насколько мне известно -- ну > удобней так Джоэлу, и на том спасибо. Ну видел я этот сайт. Ну, сайт. Какой-то унылый и топорный. Пардон, ливстрит самый обычный - не в пример приятнее для пользователя и фичастее. Только на IIS его будет вкорячивать разве что полный мазохист. Кто такой Джоэл и почему меня должно волновать его удобство - для меня загадка. Меня прежде всего мое удобство интересует. > И это не противоречит процитированному само по себе. :) Ну я допускаю что при очень прямых руках и из IIS сносный веб сервер может выйти, но таких примеров около нуля.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	77. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Michael Shigorin (ok) on 11-Окт-12, 14:18
	>> он и так обрабатывает пулом нитей IIRC; > Если это "тред на запрос" Если правильно помню, то нет. >> - тот же stackoverflow.com живёт на IIS, насколько мне известно > Ну видел я этот сайт. Ну, сайт. Какой-то унылый и топорный. Тяжёлый случай.  Вообще-то один из наиболее полезных для разработчика нынче (а рядом отрос ещё кустик, включая serverfault.com для админов). > Пардон, ливстрит самый обычный Привёл пример не движка, а ресурса.  Ну, не бананы, а яблоки. > Кто такой Джоэл Что, и классику вроде http://www.joelonsoftware.com/articles/APIWar.html не читали?  Во дела... > и почему меня должно волновать его удобство - для меня загадка. Вообще-то это как раз его взволновало печальное положение дел с советами и code snippet'ами, за что и спасибо.  Дядька-то не зря из редмонда _смотался_. :)
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	93. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 12-Окт-12, 02:50
	> Если правильно помню, то нет. Вообще я что-то такое припоминаю. По поводу чего меня еще и удивляло что оно умудряется так тормозить. >> Ну видел я этот сайт. Ну, сайт. Какой-то унылый и топорный. > Тяжёлый случай.  Вообще-то один из наиболее полезных для разработчика нынче (а > рядом отрос ещё кустик, включая serverfault.com для админов). Тяжелый случай - это когда некто пытается рассказать что в прироже есть 1 полезный для программеров ресурс. Мне вот в последнее время был как-то наиболее полезен http://linux.die.net/ на котором хоть и временами староватая, но в целом вполне приличная документация на сисколы линукса. Хоть оно и в совсем ином формате. >> Пардон, ливстрит самый обычный > Привёл пример не движка, а ресурса.  Ну, не бананы, а яблоки. Ну, ресурс. Я не понимаю что в нем такого от чего вы так претесь. Ну сайт. Ну сделан в духе ливстритовских вопросов-ответов. Только паршивее выглядит. Пусть кому надо - те и пользуются. А мне и так хорошо. >> Кто такой Джоэл > Что, и классику вроде http://www.joelonsoftware.com/articles/APIWar.html не читали? Во дела... А я то все время думал что классика - это Кнут там например, etc. А этот перец плюется но кактус кушает? Ну, бывает. >> и почему меня должно волновать его удобство - для меня загадка. > Вообще-то это как раз его взволновало печальное положение дел с советами и > code snippet'ами, за что и спасибо.  Дядька-то не зря из редмонда _смотался_. :) Смотался? Молодец. А дурных привычек типа IIS похоже так и не избавился. Ну то-есть, он покритиковав апи тем не менее, зависит от MS и их произвола на своем же сайте. Что как бы забавно, да.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	24. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 10-Окт-12, 19:19
	> [facepalm] Связка nginx <=> Apache? Не, не слышал... Нафиг нужно. Админить 1 сервак проще чем два. И да, с учетом поддержки кучи протоколов - бэкэндом может выступать сразу php через fcgi. Ну или что там у вас, через кучу *gi-протоколов. Апач в этой схеме лишний балласт.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Nginx стал самым популярным http-сервером в Рунете"	+2 +/–
Сообщение от Аноним (??) on 10-Окт-12, 14:02
Патриотизм...:)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Nginx стал самым популярным http-сервером в Рунете"	+1 +/–
Сообщение от Мутуз on 10-Окт-12, 14:41
Про tomcat забыли упомянуть
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	40. "Nginx стал самым популярным http-сервером в Рунете"	+1 +/–
	Сообщение от Аноним (??) on 10-Окт-12, 20:22
	> Про tomcat забыли упомянуть А смысл? Его там на экране радаров надо с микроскопом рассматривать.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Nginx стал самым популярным http-сервером в Рунете"	+/–
Сообщение от Дед анон on 10-Окт-12, 14:50
Ну что сказать. Я рад что отечественный продукт так востребован! Теперь осталось чтоб эта статистика начала распространяться и на остальной мир.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Nginx стал самым популярным http-сервером в Рунете"	–6 +/–
Сообщение от Аноним (??) on 10-Окт-12, 16:00
>Примечательно, что при рассмотрении только HTTPS-серверов, доля nginx составляет только 2.3%, в то время как Apache занимает 41.6%, а IIS - 40.8%. когда нужна безопасность все еще многие выбирают МС?)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	29. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 10-Окт-12, 19:32
	> безопасность > МС Взаимоисключающие параграфы. Этим господам у которых до недавних пор можно было ремотно всю систему разнести, долбанув по закрытым udp-портам и попав сразу в кернелмод явно не стоит вякать про какую-то там безопасность. У *никсообразных таких детских болезней сетевого стека как-то не наблюдается. Можно было бы побухтеть про неуловимого джо, который с своими 6% будет проигнорирован, но у буржуев его больше, так что какая-нибудь автоматика в два счета продолбит и глазом не моргнет.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	33. "Nginx стал самым популярным http-сервером в Рунете"	+3 +/–
	Сообщение от Аноним (??) on 10-Окт-12, 19:48
	> когда нужна безопасность все еще многие выбирают МС?) Ага. Как критерий при подборе персонала: "Как вы относитесь к МС? - Положительно. - Пошел вон"
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

12. "Nginx стал самым популярным http-сервером в Рунете"	+1 +/–
Сообщение от Дед анон on 10-Окт-12, 16:27
>когда нужна безопасность все еще многие выбирают МС?) Фанат MS?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	66. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Michael Shigorin (ok) on 11-Окт-12, 12:05
	>>когда нужна безопасность все еще многие выбирают МС?) > Фанат MS? Хуже: http://habrahabr.ru/blogs/marketing/78536/
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

16. "Nginx стал самым популярным http-сервером в Рунете"	+/–
Сообщение от Аноним (??) on 10-Окт-12, 18:23
А страница "502 Bad Gateway" стала самой популярной страницей в Рунете?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	19. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Клыкастый (ok) on 10-Окт-12, 18:37
	> А страница "502 Bad Gateway" стала самой популярной страницей в Рунете? Это безошибочный детектор ситуации "набрали быдлокодеров, уволили админа". при наличии либо грамотного программиста либо грамотного админа всё прекрасно.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	23. "Nginx стал самым популярным http-сервером в Рунете"	+1 +/–
	Сообщение от Аноним (??) on 10-Окт-12, 19:17
	> А страница "502 Bad Gateway" стала самой популярной страницей в Рунете? Так фокус в том что это нжинкс сообщает: я живой, а вот та пакость которая за мной - с позором издохла.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	35. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 10-Окт-12, 19:50
	> А страница "502 Bad Gateway" стала самой популярной страницей в Рунете? Спасибо apache backend за это!
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	59. "Nginx стал самым популярным http-сервером в Рунете"	–1 +/–
	Сообщение от AHoH on 11-Окт-12, 10:47
	А не php-fpm? С ним то проблем в разы больше чем с опачевским модулем
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	60. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 11-Окт-12, 11:06
	> А не php-fpm? С ним то проблем в разы больше чем с опачевским модулем Что-то не заметил с ним проблем. В чем они заключаются?
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	144. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Клыкастый (ok) on 21-Окт-12, 20:46
	> А не php-fpm? С ним то проблем в разы больше чем с опачевским модулем в "классике" это несогласование таймаутов на фронтэнде и выполнения скрипта на бэкэнде. строго говоря бэкэнд тут не при чём. тут должен согласовываться таймаут и если он сильно велик, за жабры надо брать программиста с пристрастным выяснением "почему так долго". я это к тому, что собственно бэкэнд (какой бы он ни был) слегка не при чём.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	146. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от myhand (ok) on 29-Окт-12, 14:18
	> я это к тому, что собственно бэкэнд (какой бы он ни был) > слегка не при чём. Я тут недавно вам (или другому фанбою?) писал про то, что в php-fpm довольно долго был pm=static.  Рассказать почему от одного этого бывает проблем "в разы больше" при безграмотной конфигурации бакенда (привет копипастерам!)?
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

22. "Nginx стал самым популярным http-сервером в Рунете"	+/–
Сообщение от Аноним (??) on 10-Окт-12, 19:16
> Microsoft IIS довольствуется долей в 6,91% Куда и дорога. Настроить нжинкс в 20 раз проще. Это тот случай когда отредактировать 1 конфиг, который к тому же на 80% нагуглен - проще чем битый час тыкаться мышкой в разлапистой и геморройной конструкции.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

56. "Nginx стал самым популярным http-сервером в Рунете"	+4 +/–
Сообщение от Аноним (??) on 11-Окт-12, 03:42
"количество работающих под управлением nginx web-серверов в России превысило количество серверов, использующих Apache, и составило 44,77% против 44,02%" А здесь нет ничего удивительного, Россия - единственная реально цивилизованная страна на сегодняшний день, да ещё и с огромными нарастающими темпами развития во всех сферах и отраслях. Сейчас от Apache в пользу Nginx отказываются все. Сегодня Россия, завтра подтянутся и страны третьего мира: США, ЕвроСоюз и другие отсталые "деревенщины".
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	57. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 11-Окт-12, 08:37
	>Россия - единственная реально цивилизованная страна на сегодняшний день, да ещё и с огромными нарастающими темпами развития во всех сферах и отраслях. Не читайте советских газет! (С)
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	61. "Nginx стал самым популярным http-сервером в Рунете"	+/–
	Сообщение от Аноним (??) on 11-Окт-12, 11:08
	> и страны третьего мира: США, ЕвроСоюз и другие отсталые "деревенщины". Ну так ex-USSR - это все-таки страна инженеров а не дебилов сушащих кошку в микроволновке. Вон высоконагруженные сайты поневоле валят. Просто потому что вбубухивать баблосы в сервера может и подзадолбать.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

64. "Nginx стал самым популярным http-сервером в Рунете"	+/–
Сообщение от Макс Лапшин on 11-Окт-12, 12:00
Запускаем такой скрипт на сайте с апачом: https://gist.github.com/3870871  и тем самым иммитируем эффект прихода сотни пользователей с мобилок. Если человек выставляет апач в интернет, значит он остался в начале 2000-х и плюёт на трафик с мобильных устройств.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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