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

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

"Http-сервер nginx обслуживает более половины хостов рунета"	+/–
Сообщение от opennews (??) on 04-Июн-11, 23:26
В соответствии с июньской статистикой (http://stat.webnames.ru/?show=http&what=&date=1306872000) распределения популярности http-серверов, опубликованной сервисом WebNames.ru, nginx (http://www.sysoev.ru/nginx/) обслуживает более половины хостов рунета. Доля Apache составляет 37.47%, nginx - 51.11%, IIS - 5.54%, иных серверов - 5.87%. Следует заметить, что в большинстве конфигураций nginx используется в качестве фронтэнда к Apache, т.е. присутствие Apache значительно шире, чем указано. Статистика основана на результате опроса более 4 млн доменов в зоне RU. <center><a href="http://stat.webnames.ru/?show=http&what=fullstats">&... src="https://www.opennet.ru/opennews/pics_base/30783_1307215340.jp... style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></a></center> URL: http://stat.webnames.ru/?show=http&what=fullstats Новость: https://www.opennet.ru/opennews/art.shtml?num=30783
Ответить | Правка | Cообщить модератору

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

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

1. "Http-сервер nginx обслуживает более половины хостов рунета"	+15 +/–
Сообщение от Аноним (??) on 04-Июн-11, 23:26
Ну а что, хороший шустрый и функциональный сервак. Может даже без апача работать. На отдаче статики делает апач с разгромным счетом.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Http-сервер nginx обслуживает более половины хостов рунета"	+1 +/–
Сообщение от c0rax (ok) on 05-Июн-11, 00:53
>Ну а что, хороший шустрый и функциональный сервак. >Может даже без апача работать. >На отдаче статики делает апач с разгромным счетом +1 сам уже давным давно перешел на связку nginx + php-fpm Равных ему по скорости, и по потреблению ресурсов ИМХО нет..!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	16. "Http-сервер nginx обслуживает более половины хостов рунета"	+1 +/–
	Сообщение от Hety (??) on 05-Июн-11, 14:36
	Аналогично. Удобно, быстро, мало жрет. Если отсутствует необходимость в большинстве продвинутых фич апача - то вообще равных нет.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	32. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Andrew Kolchoogin on 05-Июн-11, 22:52
	> Если отсутствует необходимость в большинстве продвинутых фич апача Уважаемые коллеги, у меня к вам большая ко всем просьба: перечислите мне "продвинутые фичи Apache", которых нет в nginx. Лично _меня_ беспокоит одно: отсутствие аналога mod_dav_svn для nginx. Может быть, я плохо искал, если оно находится Google'ом -- не сочтите за труд дать поисковый запрос. Что ещё есть в Apache такого, чего нет в nginx? Я ответить на этот вопрос затрудняюсь.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	45. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Codir on 06-Июн-11, 11:59
	Да элементарно - CGI!!! Автор был настолько упорот и настырен, что людям пришлось делать ДВА вебсервера: второй - апач, как раз для обслуживания ЦГИ! Смех, да и только...
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	56. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Andrew Kolchoogin on 06-Июн-11, 14:08
	?! spawn_fcgi?
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	57. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от AlexAT (ok) on 06-Июн-11, 14:09
	> spawn_fcgi? CGI != FCGI
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	59. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Andrew Kolchoogin on 06-Июн-11, 14:18
	>> spawn_fcgi? > CGI != FCGI А, понял. Пример для Перла: http://wiki.nginx.org/SimpleCGI Я понимаю здесь Сысоева: гораздо проще написать враппер на Перле на 2К, чем ввязываться в написание двухмодового сервера (FSM+Prefork). Это проблема -- использовать враппер? Только без троллинга, пожалуйста. ;)
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	88. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 07-Июн-11, 18:40
	> чем ввязываться в написание двухмодового сервера (FSM+Prefork). Ну так Сысоев в свом деле шарит: он не собирается делать фичи которые затормозят FSM-модель сервера. И правильно делает! Именно поэтому его сервак и жжот напалмом, легко выдерживая нагрузку которая превратит апача в пинаемый клиентами труп.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	62. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 06-Июн-11, 14:55
	> Да элементарно - CGI!!! CGI маздай. Уродский и тормозной протокол эпохи каменного века. Еще большее гумно мамонта чем сам апач с его форками. Если вам нравится форкать процессы - запустите форкбомбу! Зачем ждать пока шк0л0л0 устроят вам ее своими ab2/http_load/siege'ами? :)
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	55. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Alexander Sheiko on 06-Июн-11, 13:03
	> Что ещё есть в Apache такого, чего нет в nginx? В nginx нет нормального листинга каталогов (иконки, инклудинг HEADER, README в вывод листинга). Неофициальные моды для этого из портов FreeBSD - крайне кривы. Кроме того - нет опции "user pupkin zolupkin etc" как перечень разрешённых юзеров в файле паролей. Из-за этого приходится для разного допуска плодить кучу файлов паролей с одинаковыми юзерами.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	58. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Andrew Kolchoogin on 06-Июн-11, 14:14
	>> Что ещё есть в Apache такого, чего нет в nginx? > В nginx нет нормального листинга каталогов (иконки, инклудинг HEADER, README в вывод > листинга). Неофициальные моды для этого из портов FreeBSD - крайне кривы. Это mod_autoindex в Apache? > Кроме того - нет опции "user pupkin zolupkin etc" как перечень > разрешённых юзеров в файле паролей. Из-за этого приходится для разного допуска > плодить кучу файлов паролей с одинаковыми юзерами. Не догнал. HTTP Basic Auth говорит либо Allow, либо Deny, Что значит "для разного допуска"?
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	61. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Alexander Sheiko on 06-Июн-11, 14:34
	> Это mod_autoindex в Apache? Да. В нём много отлаженных годами возможностей. > Не догнал. HTTP Basic Auth говорит либо Allow, либо Deny, Что значит > "для разного допуска"? В nginx используется такая функция: auth_basic "Restricted Access"; auth_basic_user_file /usr/local/etc/nginx/htpasswd; При этом ВСЕ, кто перечислен в файле htpasswd, после ввода пароля получают доступ к каталогу / файлу. В Apache же есть такой синтаксис: AuthType Basic AuthUserFile /usr/local/etc/apache2/htpasswd AuthName "Restricted Access" require user pupkin zolupkin При этом в файле htpasswd может быть сколько угодно пользователей, но  доступ к каталогу / файлу будут иметь ТОЛЬКО юзеры pupkin и zolupkin. В виду невозможности задать имя конкретных юзеров в nginx, для доступа к каждому каталогу / файлу приходится создавать отдельный файл паролей и дублировать в нём одинаковых пользователей, что очень неудобно (менять пароли, иметь кучу файлов паролей и т. п.).
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	75. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 07-Июн-11, 17:11
	> Да. В нём много отлаженных годами возможностей. Спасибо вам за этот модуль, господа ретарды. Через него так удобно сливать внутренние сущности, которые вы не планировали изначально светить всему миру - от бакапов сайта до побочных фотографий которые одмин сдуру выложил под свои нужды ;) > При этом ВСЕ, кто перечислен в файле htpasswd, после ввода пароля получают > доступ к каталогу / файлу. Что вроде бы логично. Файл указывает кому и что льзя. Это хорошо. > При этом в файле htpasswd может быть сколько угодно пользователей, но   > доступ к каталогу / файлу будут иметь ТОЛЬКО юзеры pupkin и > zolupkin. Замечательно, ага! Авторизация размазана по 2 местам. Это же так приятно - в мозгу эффективный ACL самому комбинировать. Из двух файлов. И это совсем не провоцирует ошибки. > В виду невозможности задать имя конкретных юзеров в nginx, для доступа к > каждому каталогу / файлу приходится создавать отдельный файл паролей и дублировать > в нём одинаковых пользователей, что очень неудобно (менять пароли, иметь кучу > файлов паролей и т. п.). Зато можно сразу посмотреть - у кого к ресурсу доступ. В *одном* файле а не в пяти разных местах. Это и баг и фича. Фича - потому что так проще оценивать у кого доступ. Баг потому что то что вы указали, да. Тем не менее, уважающий себя *никсоид должен уметь скроить за 2 минуты команду которая во всех файлах заменит пароль одним чихом, нарисуйся у него такая нужда. Так что это очень небольшая и незначительная "бага", вообще не достойная упоминания.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	80. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от zazik (ok) on 07-Июн-11, 18:06
	> Спасибо вам за этот модуль, господа ретарды. Через него так удобно сливать > внутренние сущности, которые вы не планировали изначально светить всему миру - > от бакапов сайта до побочных фотографий которые одмин сдуру выложил под > свои нужды ;) Тщательнее надо быть. Security by obscurity никому не помогало.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	85. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 07-Июн-11, 18:26
	> Тщательнее надо быть. Security by obscurity никому не помогало. А теперь идите и расскажите это всем тем лохам, у которых опачи радостно индексят диры мне на радость :). Практика показала: лохов много, интересных файлов у них - тоже. Вот так при помощи клавиш со стрелками и кнопки bkspace на клаве можно внезапно "расхакать" немало кульных серваков :D. А все потому что админы поставили свое удобство выше безопасности и включили этот модуль на свой зад.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	92. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от zazik (ok) on 07-Июн-11, 23:46
	>> Тщательнее надо быть. Security by obscurity никому не помогало. > А теперь идите и расскажите это всем тем лохам, у которых опачи > радостно индексят диры мне на радость :). Практика показала: лохов много, > интересных файлов у них - тоже. Вот так при помощи клавиш > со стрелками и кнопки bkspace на клаве можно внезапно "расхакать" немало > кульных серваков :D. А все потому что админы поставили свое удобство > выше безопасности и включили этот модуль на свой зад. А теперь расскажите про страшную дыру в Линукс под названием "пароль по умолчанию 12345 на вывешенном наружу веб-интерфейсе в раутерах %company_name%".
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	84. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Alexander Sheiko on 07-Июн-11, 18:21
	> Спасибо вам за этот модуль, господа ретарды. Через него так удобно сливать внутренние сущности, которые вы не планировали изначально светить всему миру - от бакапов сайта до побочных фотографий которые одмин сдуру выложил под свои нужды ;) Nginx тоже прекрасно выводит листинг каталогов. Только без иконок и включения в вывод заданных файлов. Т.е. - "светит" он в той же степени. > Это и баг и фича. Фича - потому что так проще оценивать у кого доступ. Баг потому что то что вы указали, да. Должна быть возможность выбора под конкретные задачи. > Тем не менее, уважающий себя *никсоид должен уметь скроить за 2 минуты команду которая во всех файлах заменит пароль одним чихом, нарисуйся у него такая нужда Ни кто никому ничего не должен. В данном случае - это костыли.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	89. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 07-Июн-11, 18:45
	> Nginx тоже прекрасно выводит листинг каталогов. Только без иконок и включения в > вывод заданных файлов. Т.е. - "светит" он в той же степени. У него по дефолту этот модуль сроду неактивен. Ни разу еще не удалось ничего умыкнуть с нжинкса таким макаром. А вот с апачей - сколько влезет. Чисто статистческое наблюдение: на жнинксе с потугой залистть диру почти гарантированно пошлют. А на апачах 50/50 где-то. > Должна быть возможность выбора под конкретные задачи. Вообще не вижу проблем: ну если надо много и часто - написали себе скриптик вида change_pass <user> <newpassword> за 2 минуты и забыли о проблеме. Тоже мне проблему нашли.   > Ни кто никому ничего не должен. В данном случае - это костыли. Обычная системная автоматизация и упрощение жизни. Прописка прав в 2 местах - тоже костыли, при том если первое ведет лишь к небольшому неудобству, второе ведет к возможности облажаться в персиссиях с невкусным результатом (кому-то недосыпят или пересыпят прав, что как-то не есть хорошо - хорошо когда все права сразу на виду).
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	93. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от zazik (ok) on 07-Июн-11, 23:51
	> Обычная системная автоматизация и упрощение жизни. Прописка прав в 2 местах - > тоже костыли, при том если первое ведет лишь к небольшому неудобству, > второе ведет к возможности облажаться в персиссиях с невкусным результатом (кому-то > недосыпят или пересыпят прав, что как-то не есть хорошо - хорошо > когда все права сразу на виду). То есть, все "миллионы лет" эволюции *nix-систем зря? Ведь там тоже логин и пароль хранятся в одном месте, а права на объекты выдаются только с помощью логина(uid'а/gid'а, если быть точным)? Да-да-да, надо было держать master.passwd в каждом каталоге, как же они не догадались! А чтобы сменить пароль пользователю нужно всего лишь написать простой скрипт, который обойдёт весь диск и обновит master.passwd в каждом каталоге. Гениально!
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	71. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от MVK (??) on 07-Июн-11, 14:08
	> Уважаемые коллеги, у меня к вам большая ко всем просьба: перечислите мне > "продвинутые фичи Apache", которых нет в nginx. - поддержка AJP
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	34. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Anonymouss on 06-Июн-11, 04:27
	> Равных ему по скорости, и по потреблению ресурсов ИМХО нет..! lighttpd быстрее
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	40. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 06-Июн-11, 10:51
	Сильно зависит от. В многоядерной конфигурации у нжинкса больше шансов быть шустрее, распихав по воркеру на ядро.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	64. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 06-Июн-11, 17:06
	> lighttpd быстрее Проверено, lighttpd процентов на 20% медленнее при отдаче статики и проксировании на одноядерном CPU, на многоядерных системах nginx в разы может обгонять lighttpd. Почитайте презентацию процесса миграции WordPress на nginx, там достаточно подробно на реальной нагрузке сравнивались разные http-серверы.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	65. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Anonymouss on 06-Июн-11, 18:42
	> презентацию процесса миграции WordPress А ссылку?
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	76. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 07-Июн-11, 17:12
	> Проверено, lighttpd процентов на 20% медленнее при отдаче статики и проксировании на > одноядерном CPU, А как/чем проверялось, если не секрет? Всегда хотел сравнить их но никогда не доходили руки до запуска на одинаковой конфигурации.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

3. "Http-сервер nginx обслуживает более половины хостов рунета"	–2 +/–
Сообщение от Вредоносный on 05-Июн-11, 04:58
Показательно! В зоне ру невероятное количество сайтов, для которых крайне важна именно отдача статики! Ну ничего, лет через 20 или 30 научимся и динамические сайты делать! Я уверен!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Http-сервер nginx обслуживает более половины хостов рунета"	–6 +/–
	Сообщение от Аноним (??) on 05-Июн-11, 05:06
	Я тоже уверен что лет через 20 или 30 даже такой дурак как ты научится с помощью кеширования делать из динамики - статику. Хотя ... пожалуй я оптимист по отношению к тебе :)
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	8. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от dyn (??) on 05-Июн-11, 07:14
	> делать из динамики - статику Ога. В соцсетях.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	17. "Http-сервер nginx обслуживает более половины хостов рунета"	+1 +/–
	Сообщение от Andrew Kolchoogin on 05-Июн-11, 14:53
	Нет, я, действительно, не понимаю, зачем "для динамики" Apache. Вот взять, к примеру, меня. У меня есть phpBB, WordPress и MediaWiki. Но вот Apache как-то нет. ЧЯДНТ?
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	26. "Http-сервер nginx обслуживает более половины хостов рунета"	–2 +/–
	Сообщение от Аноним (??) on 05-Июн-11, 20:37
	> Нет, я, действительно, не понимаю, зачем "для динамики" Apache. Наверное потому что ленивые и тупые не могут освоить прикольные фичи нжинкса, типа кеширования. А кеширование - это такая крутая штука, когда вы можете спокойно выдержать хабра/слэшдот/чтотамещеэффект на откопанном пентиум 3 из пыльной кладовки. Не делая дорогущую ферму на ксеонах, которая потребовалась бы чтобы все это же в реальном времени генерить опачами на каждый запрос, каждому юзеру. А зачем 5000 раз в секунду генерить одно и то же? :)
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	30. "Http-сервер nginx обслуживает более половины хостов рунета"	+4 +/–
	Сообщение от umbr (ok) on 05-Июн-11, 22:46
	>...на откопанном пентиум 3 из пыльной кладовки. Это не укладывается в концепцию энтерпрайза, где под каждую фичу покупается дорогущая ферма на ксенонах.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	39. "Http-сервер nginx обслуживает более половины хостов рунета"	+1 +/–
	Сообщение от 1 (??) on 06-Июн-11, 10:31
	бгг, ксеноны противоречат ПДД :)
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	52. "Http-сервер nginx обслуживает более половины хостов рунета"	+1 +/–
	Сообщение от Hety (??) on 06-Июн-11, 12:30
	Это не укладывается в концепцию откатов с дорогущих ферм.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	37. "Http-сервер nginx обслуживает более половины хостов рунета"	+1 +/–
	Сообщение от хз on 06-Июн-11, 10:00
	За тем, что бы было на что порш каен купить
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	70. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 07-Июн-11, 04:55
	> За тем, что бы было на что порш каен купить Вам даже на зарплату учителя русского языка видимо не хватило. Не то что на порш. :P
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	67. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от zazik (ok) on 06-Июн-11, 21:04
	>> делать из динамики - статику > Ога. В соцсетях. Да.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	19. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 05-Июн-11, 16:33
	> Ну ничего, лет через 20 или 30 научимся и динамические сайты делать! Да, да. А картинки, шрифты, стили, музыка и т.д. все через астрал передаваться будет.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	25. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 05-Июн-11, 20:34
	> Ну ничего, лет через 20 или 30 научимся и динамические сайты делать! Я уверен! Вы еще не видели как нжинкс кеширует динамику. Там где вы умрете под 50 одновременными юзерами с вашим опачом, нжинкс легко вытянет 5000, если мозг задействовать. А у опача и близко нет такого удобного управления кешированием...
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	33. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от zoonman (ok) on 06-Июн-11, 00:26
	Ну ка расскажите мне про то, как вы будете кэшировать к примеру список новых комментариев к тем статьям, которые читал конкретный пользователь, когда у вас хотя бы с десяток юзеров на сайте за последнюю минуту и каждый из них может написать новый комментарий в любой момент? В таком случае нужно event-based cache management применять. Т.е. сбрасывать/обновлять весь релевантный кэш (а его еще надо найти, а еще хранить индивидуально под каждого пользователя свой). Кэширование нужно применять там, где в нем есть смысл. Например скэшировать 100 картинок со страницы и быстро отдать их. Но лучше отправить верстальщика на учебу, где он освоит спрайты и вместо 100 картинок будет 1. И о чудо, сервер перестанет загибаться от нагрузки потому, что вместо 1000 запросов к серверу будет 10.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	41. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 06-Июн-11, 11:01
	> минуту и каждый из них может написать новый комментарий в любой момент? Ну не увидит юзер коменты за последнюю секунду. Трагедия, однако :). А как кешировать? Да как обычно. А при написании комента попутно можно инвалидировать кеш, если уж по уму все делать. Правда это оверкилл: непоказ коментов за последнюю секунду большой проблемой не является, если ориантироваться на практику а не эстетствовать :P > Кэширование нужно применять там, где в нем есть смысл. Ну вот когда вас опубликуют на сдешдоте/хабре/чем там еще - узнаете где в нем есть смысл :) > Например скэшировать 100 картинок со страницы и быстро отдать их. Чего? Кого? Зачем? Кешируют обычно результат работы скриптов, чтобы не дергать на всю толпень юзеров постоянно серверные скрипты. А то если вам 5000 одновременных юзеров придет - вы немного задолбаетесь на них php или что там у вас в 5000 экземплярах дергать. А в статику закешить - и пусть отдается себе. Ну будет страница с коментами 1-секундной давности. Ужас! > И о чудо, сервер перестанет загибаться от нагрузки потому, что вместо 1000 запросов к серверу будет 10. О чудо, любой школотенок с ab может прийти к вам с своего вшивого диалапа 1000й "юзеров". Параллельных потоков. Когда опач форканет 1000 процессов и пых попробует выполнить скрипт в 1000 копий - сервер радостно и быстро сдохнет. Классический метод уронить дефолтовый апач :). Ему много лет и он до сих пор работает. Поскольку затраты ресурсов на стороне клиента много меньше затрат сервера на их обслуживание.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	44. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от zoonman (ok) on 06-Июн-11, 11:58
	> Ну не увидит юзер коменты за последнюю секунду. Трагедия, однако :). А А если у вас магазин? Товар допустим купили, а человек делает свой заказ и получает отказ перед самым носом потому, что этот товар только что купили. А если бы увидел актуальные данные, возможно выбрал бы другой товар. А так у него будет негативная ассоциация. >  А при написании комента попутно можно > инвалидировать кеш, если уж по уму все делать. Про это я выше написал. > Ну вот когда вас опубликуют на сдешдоте/хабре/чем там еще - узнаете где > в нем есть смысл :) Знаем. Насчет школоты есть соответствующие ограничения. Ни один разумный админ не будет оставлять апач по умолчанию. Динамика должна оставаться динамикой. Она для этого была создана.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	46. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Codir on 06-Июн-11, 12:04
	Не распаляйтесь на школоло - им законы физики вообще нипочём! :) "Ну не увидит юзер коменты за последнюю секунду. " - разве не виден ламерский подход? Кэш - это всё забавно, но "динамика" названа динамикой не потому, что другого слова не нашлось, а потому, что это ПРОТИВОПОЛОЖНОСТЬ статике. Но не всем это дано понять...
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	86. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 07-Июн-11, 18:31
	> не всем это дано понять... Ой, а вот через секунду после того как мне ваш сервак страницу отдал, там новый юзер откоментил. А чойта эта ваша динамика не генерит мне страницу заново и не показывает его? Как максимум что-то такое делается на аяксе, только это не противоречит использованию нжинкса и тормознутость в основном определится архитектурой серверной стороны приложения, насколько оно эффективно обрабатывает множественные параллельные запросы. При этом кстати можно быстро выстрелить тяжелые части статикой из кеша, а остальное подтянуть аяксом по мере готовности и ненапряжно для юзера. Опач с его форками на каждое соединение опять не у дел - при постоянном висении тысяч юзеров он с его толпами процессов просто умрет.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	77. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 07-Июн-11, 17:36
	> А если у вас магазин? Товар допустим купили, а человек делает свой > заказ и получает отказ перед самым носом потому, что этот товар > только что купили. Как ни странно, наиболее вменяемые магазины делают именно так: собирается корзина. Из товаров которые предположительно есть. На окончательном этапе сборки заказа чекается есть ли товар по факту на складе. Если да - заказ создан. Нет - отлуп. Дело тут в том, что даже если вы слазили в базу и сгенерили мне страничку по актуальному состоянию товаров, пока я вдуплял чего бы мне заказать, этот товар вполне могли уже купить. Вот только страничка об этом ... не знает. Более того, пока я клал в корзину 10 наименований, из них 2 вполне могли раскупить. Апдейтить мне в реалтайме страницу или постоянно проверять не протухли ли даннык корзины - никакая БД не выдержит при мало-мальски популярном магазине. Поэтому это делается 1 раз - при окончательном создании заказа. Это нормально и всех устраивает. > А если бы увидел актуальные данные, возможно выбрал > бы другой товар. А так у него будет негативная ассоциация. Она у него и так может возникнуть. Вот показывает юзеру страница что есть товар. Ну, на момент генерации и запроса в базу - был. Юзер минуту смотрел на нее и выбирал. Выбрал. А за эту минуту бац и кто-то взял и раскупил как раз то что он выбрал. Совершенно штатная ситуация для популярного магазина. Юзер обламывается. Ну и в чем выигрыш то? Возможность такой ситуации все-равно осталась. >>  А при написании комента попутно можно >> инвалидировать кеш, если уж по уму все делать. > Про это я выше написал. Про магазин? Так в вашем варианте юзер тоже может обломаться: вы же не можете юзеру постоянно генерячить новые версии страниц и вдувать ему новую версию страницы на любое изменение базы. Ну то-есть теоретически это можно, но практически такую жесть никакой сервер не выдержит + излишне сложно. Обычно юзеров именно посылают на окончательном оформлении заказа. Это нормально, привычно, реалистично. С идеей кеширования особо не воюет. И более того - это может сделать только зареганый юзер. Который если будет наглеть сильно дергая сервер, просто лишится своего аккаунта и более дергать эту операцию не сможет. > Насчет школоты есть соответствующие ограничения. Ни один разумный админ не будет оставлять > апач по умолчанию. А ограничения знаете ли ведут к другой проблеме. Если я залимитирую число процессов/тредов опача, в случае когда вредитель занял собой все процессы/треды, легитимные юзеры вообще хрен дождутся своей очерели. Словят таймаут в браузере и отвалят восвояси. Не сильно лучше варианта лютой смерти сервака от форка кучи процессов. > Динамика должна оставаться динамикой. Она для этого была создана. Динамика должна быть таковой только там где это оправдано. Пример с товарами - не катит: список товаров устарел сразу же после выдачи, а постоянно актуализовывать полное состояние ваших складов на всех юзеров - никаких серверов не хватит. А если на юзере нет полного сосояния всех товаров на складе - оно тогда всяко не синхронно с вами и возможны накладки. Ы? :)
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	91. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от zoonman (ok) on 07-Июн-11, 20:51
	Мне интересен такой момент, как то, откуда кэшсервер узнает, авторизован юзер или нет? Например у меня по одному и тому же URL сайт обязан открываться совершенно по-разному для авторизованного и неавторизованного пользователя. Ну а про блоки типа "вы уже смотрели" или выдачи материала в зависимости от запроса в поисковике наверно прийдется забыть.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	99. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от st (??) on 08-Июн-11, 12:08
	> Мне интересен такой момент, как то, откуда кэшсервер узнает, авторизован юзер или > нет? > Например у меня по одному и тому же URL сайт обязан открываться > совершенно по-разному для авторизованного и неавторизованного пользователя. никак, кэш на уровне httpd не твой случай > Ну а про блоки типа "вы уже смотрели" реализуемы через ajax > или выдачи материала в > зависимости от запроса в поисковике наверно прийдется забыть. ну так не кэшировать URL
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	100. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от zoonman (ok) on 08-Июн-11, 12:17
	> реализуемы через ajax Это увеличивает число запросов к серверу и усложняет архитектуру веб-приложения. > ну так не кэшировать URL что это значит? Получается, что кэширование вредно? Или даже не так. Получается, что кэширование применимо далеко не ко всем задачам. Еще раз прихожу к выводу, что nginx-frontend & apache=backend неплохая связка. И так получаем: использование nginx как кэширования динамики применимо только к высоконагруженным новостным/read-only/slowupdated сайтам и никак к магазинам и прочим web-apps.
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	63. "Http-сервер nginx обслуживает более половины хостов рунета"	+2 +/–
	Сообщение от sn00p on 06-Июн-11, 16:56
	>[оверквотинг удален] > минуту и каждый из них может написать новый комментарий в любой > момент? > В таком случае нужно event-based cache management применять. Т.е. сбрасывать/обновлять > весь релевантный кэш (а его еще надо найти, а еще хранить > индивидуально под каждого пользователя свой). > Кэширование нужно применять там, где в нем есть смысл. Например скэшировать 100 > картинок со страницы и быстро отдать их. Но лучше отправить верстальщика > на учебу, где он освоит спрайты и вместо 100 картинок будет > 1. И о чудо, сервер перестанет загибаться от нагрузки потому, что > вместо 1000 запросов к серверу будет 10. redis+nginx+версионирование кэша по ключам. Nginx рисует ssi по путям, который ему отдал редис, которые формируют в редисе динамические виджеты. Если что-то надо изменить, то по маске удаляем из редиса все измененное и рисуем заново. Если продумать схему страницы по виджетам, и продумать дерево виджетов, то получается очень неплохо. Кэшировать можно практически все и везде.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

5. "Http-сервер nginx обслуживает более половины хостов рунета"	+4 +/–
Сообщение от V (??) on 05-Июн-11, 05:11
гон всё это. за 90% из этого кол-ва nginx'ов стоят апачи...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Http-сервер nginx обслуживает более половины хостов рунета"	+1 +/–
	Сообщение от Bocha (??) on 05-Июн-11, 06:19
	В новости именно так и написано.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	7. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от жт on 05-Июн-11, 07:03
	Тогда в чем новость? nginx в принципе существует? Ну да, мы в курсе :-)
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	9. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 05-Июн-11, 10:21
	В том, что его доля увеличилась с 20% в прошлом году до 50% в этом. О чем это говорит? Ты уж будь добр подумай сам.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	29. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от szh (ok) on 05-Июн-11, 22:35
	20 - не в прошлом, а 3 года назад
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	20. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 05-Июн-11, 16:35
	надо еще было один график нарисовать: 90% Апач + nginx
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	27. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 05-Июн-11, 20:39
	> надо еще было один график нарисовать: 90% Апач + nginx Не факт что 90%. Я вот опач совсем не юзаю. А зачем?
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

11. "Http-сервер nginx обслуживает более половины хостов рунета"	+7 +/–
Сообщение от KDEist on 05-Июн-11, 10:46
А кривая динамики эмэсовского IIS доставляет, хе-хе...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от ВКПб on 05-Июн-11, 12:22
	Ынтерпрайз
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	15. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Xing on 05-Июн-11, 12:57
	Но они все равно счастливы :D http://habrahabr.ru/blogs/modx/120282/
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	23. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Anonymouss on 05-Июн-11, 19:26
	Внимание, реклама m$!
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	28. "Http-сервер nginx обслуживает более половины хостов рунета"	+1 +/–
	Сообщение от Аноним (??) on 05-Июн-11, 20:41
	> Но они все равно счастливы :D > http://habrahabr.ru/blogs/modx/120282/ Да конечно, можно заплатить тонну бабок за монструозные тормозные решения майкрософт. Но зачем, если не хуже, а как правило даже лучше - получается совершенно бесплатно на открытом софте?! Это какой-то тонкий вид мазохизма - заплатить много денег, влипнуть в зависимость от MS и получить решение, которое по параметрам просрет бесплатному. Если б это было не так - ну наверное, даунлоады MS не отгружал бы AKAMAI на пингвинах? :)
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	47. "Http-сервер nginx обслуживает более половины хостов рунета"	–1 +/–
	Сообщение от Codir on 06-Июн-11, 12:13
	> Да конечно, можно заплатить тонну бабок за монструозные тормозные решения майкрософт. Но > зачем, если не хуже, а как правило даже лучше - получается > совершенно бесплатно на открытом софте?! Затем, что M$ - это не просто "выучил сишарп и слабал асп-шку" (как принято в FOSS) - это целая инфраструктура, где мелкософт несёт ответственность за все свои продукты: от своевременной поставки заплаток до обучения всем тонкостям продукта. Если у вас есть задача, к ней всегда найдётся мелкомягкое решение (пусть не всегда оптимальное, но гарантированное). Это и отличает Ынтепрайз - покупка лекарства от головной боли "как прикрутить к нгынксу астериск с пробросом хэсервера через ssh". Плюс сюда (опять же гарантированное) наличие спецов по платформе, прогеров и т.д. - не нужно бегать по форумам в жалкой надежде, что такой же бедолага как вы пытался скрестить Хэсервер с Voodoo 3D. Это не агитация, это объяснение к вопросу "но зачем". :) Сам юзаю линукс, но для некритичных вещей.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	50. "Http-сервер nginx обслуживает более половины хостов рунета"	+2 +/–
	Сообщение от сергей канонивцев on 06-Июн-11, 12:29
	>где мелкософт несёт ответственность за все свои продукты: А вот я в еуле читал об отказе Майкросовта от ответственности, и об его обязанности в случае чего возместить ущерб в размере стоимости продукта, ну или пяти баксов. Не сходится.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	51. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 06-Июн-11, 12:29
	>> Да конечно, можно заплатить тонну бабок за монструозные тормозные решения майкрософт. Но >> зачем, если не хуже, а как правило даже лучше - получается >> совершенно бесплатно на открытом софте?! > Затем, что M$ - это не просто "выучил сишарп и слабал асп-шку" > (как принято в FOSS) - это целая инфраструктура, где мелкософт несёт > ответственность за все свои продукты: <b>от своевременной поставки заплаток до обучения  всем тонкостям продукта.</b> Вот это особенно толсто > Если у вас есть задача, к ней всегда > найдётся мелкомягкое решение (пусть не всегда оптимальное, но гарантированное). Это и > отличает Ынтепрайз - покупка лекарства от головной боли "как прикрутить к > нгынксу астериск с пробросом хэсервера через ssh". Плюс сюда (опять же > гарантированное) наличие спецов по платформе, прогеров и т.д. - не нужно > бегать по форумам в жалкой надежде, что такой же бедолага как > вы пытался скрестить Хэсервер с Voodoo 3D. > Это не агитация, это объяснение к вопросу "но зачем". :) Сам юзаю > линукс, но для некритичных вещей.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	53. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от AlexAT (ok) on 06-Июн-11, 12:31
	>> Если у вас есть задача, к ней всегда найдётся мелкомягкое решение (пусть не всегда оптимальное, но гарантированное). У меня есть задача: концентратор PPPoE с поддержкой QinQ (4094 абонентских CVLAN внутри каждого из двух десятков SVLAN), Radius, CoA, ... Не подскажете мелкомягкое решение?
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	54. "Http-сервер nginx обслуживает более половины хостов рунета"	+1 +/–
	Сообщение от Hety (??) on 06-Июн-11, 12:36
	>> Да конечно, можно заплатить тонну бабок за монструозные тормозные решения майкрософт. Но >> зачем, если не хуже, а как правило даже лучше - получается >> совершенно бесплатно на открытом софте?! > Затем, что M$ - это не просто "выучил сишарп и слабал асп-шку" > (как принято в FOSS) - это целая инфраструктура, где мелкософт несёт > ответственность за все свои продукты О да. Коллега ушел в контору, где кто-то из руководства полагает так же. В итоге имеет некислый гемор с эксченджем (глюк, который известен с 2009го года - workaround прямо противоречит документации) и еще парой мелкомягких поделий. Где сервис пак для TMG требует IE9, но сам TMG НЕ РАБОТАЕТ С IE9! Это ваш Ынтерпрайз? Я пропущу. В любой день.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	68. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от zazik (ok) on 06-Июн-11, 21:09
	> TMG НЕ РАБОТАЕТ С IE9! Это ваш Ынтерпрайз? Я пропущу. В > любой день. Спасибо, мил человек. Похоже, я теперь знаю, почему у клиентов консоль TMG не работает.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	74. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Hety (??) on 07-Июн-11, 15:54
	>> TMG НЕ РАБОТАЕТ С IE9! Это ваш Ынтерпрайз? Я пропущу. В >> любой день. > Спасибо, мил человек. Похоже, я теперь знаю, почему у клиентов консоль TMG > не работает. В принципе коллега уверждал, что если что - лезте в инет и гуглите. На форуме находите решение - и каким бы идиотским не казалось - просто делаете. Если написано - поставить вторую сетевуху (просто поставить, даже не включать) - и все заработает - делайте. Наверняка заработает.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	82. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от zazik (ok) on 07-Июн-11, 18:09
	> В принципе коллега уверждал, что если что - лезте в инет и > гуглите. На форуме находите решение - и каким бы идиотским не > казалось - просто делаете. Если написано - поставить вторую сетевуху (просто > поставить, даже не включать) - и все заработает - делайте. Наверняка > заработает. Да я гуглил. Но это же не Linux/FreeBSD, где можно быстро найти точный ответ. Ошибок-то внятных не пишется.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	83. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 07-Июн-11, 18:19
	> мелкомягких поделий. Где сервис пак для TMG требует IE9, но сам > TMG НЕ РАБОТАЕТ С IE9! Это ваш Ынтерпрайз? Я пропущу. В любой день. Особенно эпично было на одном мсовском же сайте: сайт>  Для улучшения работы наших продуктов скачайте сильверлайт! Вот вам ссылочка! Тогда вы сможете видеть прогресс аплоада ваших файлов, а ваши волосы станут белыми и пушистыми. юзерь> Хрен с вами, давайте. (скачивается и ставится эта хрень) юзерь> WTF?! Файло теперь совсем не аплоадится?! Что за на?! гугл> knowledge base сообщает, что есть баг: этот сайт некорректно работает с сильверлайтом. EPIC FAIL!!! P.S. не в обиду этим инвалидам, показать прогресс аплоада файла на сервак можно и без их многомегового фреймворка и ассоциированых с ним багов. Маленький и скромный нжинкс это вполне позволяет, кстати. Без идиотских багов в немеряном knowledgebase по супер-мега-турбо-фреймворкам.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	66. "Http-сервер nginx обслуживает более половины хостов рунета"	+1 +/–
	Сообщение от Аноним (??) on 06-Июн-11, 18:53
	>это целая инфраструктура, где мелкософт несёт ответственность за все свои продукты: от своевременной поставки заплаток до обучения всем тонкостям продукта. >(опять же гарантированное) наличие спецов по платформе, прогеров и т.д. - не нужно бегать по форумам Как человек, имевший  дело с техподдержкой мелкософта, могу сказать: они ни за что не отвечают, а их "спецы" сами ничего не понимают в своих продуктах. Вся поддержка сводится к более или менее вежливому посыланию клиентов на три буквы. А клиенты за это еще и деньги платят.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	78. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 07-Июн-11, 18:04
	> Затем, что M$ - это не просто "выучил сишарп и слабал асп-шку" > (как принято в FOSS) - это целая инфраструктура, Инфраструктура,блаблабла. Энтерпрайз, во! Большое, тормозное, монструозное... глюкало.За кучу денег.Гадость!Добровольно это может захотеть поддерживать только идиот или мазохист. > где мелкософт несёт ответственность за все свои продукты: Почему-то в лицензии написано AS IS, отказ от гарантий и все такое. Максимум который я видел - в пределах особо тонкого стеба они обещали в лицензии нести ответственность. Аж в пределах целых $5! А ничего что эта их винда и сиквели - "немного" дороже? :D > от своевременной поставки заплаток Раз в месяц. Своевременнее некуда, лол :). Кстати, 9й ишак который на контроллер домена зачем-то накатывается, с требованием его по этому поводу перезагрузить - это довольно интересное понимание о своевременной поставке заплаток. По-моему, админа который с DC ходит в интернет надо расстрелять без суда и следствия, а потом разберемся. > до обучения всем тонкостям продукта. Ой, всем тонкостям... они свои многочисленные баги годами не чинят. В новых продуктах нынче вообще глюкодром адский, все тормозит, а шаг в сторону = глюки, которые не разрулит никакой саппорт. Есть сомнения что их унылая индусня вообще разбирается в тонкостях. > Если у вас есть задача, к ней всегда найдётся мелкомягкое решение (пусть не всегда > оптимальное, но гарантированное). Гарантированное? На LSE они уже нагарантировались. В результате получили пинка под зад в том числе и за то что не смогли обеспечить заявленные времена транзакций. Грош цена таким гарантерам. > Это и отличает Ынтепрайз - покупка лекарства от головной боли "как прикрутить к > нгынксу астериск с пробросом хэсервера через ssh". Да ну бросьте, мало-мальски нестандартную проблему саппорт мс в жизни не разрулит. И вот вы уже 1 на 1 с вашей проблемой. И даже если до мс каким-то чудом допрет что вон то и правда баг, совсем не факт что они со своей бюрократией хотя-бы за 2 месяца вам его починят. > Плюс сюда (опять же гарантированное) наличие спецов по платформе, Унылых тупых эникеев, которые в случае проблем сливают, бегут как крысы с корабля и прочая. На LSE такие молодчики дружно обделались, завалив торги на 8 часов. Убедительнее некуда. > прогеров и т.д. - не нужно Прогеров? Г@%нАк0дИров, не более. Особенно среди дотнетчиков. На LSE они себя уже показали. Прогеры-индусы гарантировали, гарантировали, а в результате и времена транзакций не обеспечили, да еще и торги уронили на 8 часов, в течение которых никто не мог эту индуястину вообще оживить. Нормальных програмеров под винду не так уж много. Более того - почему-то есть ощущение что у *никсных програмеров код в целом более качественный. > бегать по форумам в жалкой надежде, что такой же бедолага как > вы пытался скрестить Хэсервер с Voodoo 3D. На кой черт в энтерпрайзе сдалось скрещивать иксы с ископаемым видеоакселератором? Если в энтерпрайзе вылезает такой вопрос, его надо переформулировать в "кого нам надо уволить?" :) > Это не агитация, это объяснение к вопросу "но зачем". :) Сам юзаю > линукс, но для некритичных вещей. А гугл, фэйсбук и даже LSE вполне себе используют для критичных вещей. Наверное, секрет в том что вы можете или сами чинить проблемы или купить саппорт например у редхата, etc которые это смогут. Хорошо при этом то что у вас выбор есть: можете сами упираться, можете найти тех кто будет вам саппорт оказывать. Выбирая из более 1 наименованя компаний.У MS выбора нет (исправить баги без сырцов малореално и долго) а саппорт особым качеством не страдает.Они уже пулично обделались с своими гетзефакс и гарантиями на LSE. Куда уж критичнее и убедительнее чем заваленные на 8 часов торги?!
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

14. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
Сообщение от Андрей (??) on 05-Июн-11, 12:47
Прям контрольный пакет :) (51%)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	22. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Онаним on 05-Июн-11, 19:03
	Контрольный пакет - это 50% плюс "золотой сервер" (очевидно, sysoev.ru) :))
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

35. "Http-сервер nginx обслуживает более половины хостов рунета"	+1 +/–
Сообщение от Анори on 06-Июн-11, 08:47
Пока nginx не научится понимать .htaccess и mod_rewrite он вряд-ли сможет заменить на 100% apache Как только научится - apache будет лично для меня мертв - PHP скрипты спокойно будет обрабатывать PHP-FPM
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	36. "Http-сервер nginx обслуживает более половины хостов рунета"	+1 +/–
	Сообщение от Анори on 06-Июн-11, 08:47
	А, да, еще не хватает open_basedir
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	42. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от ig0r (??) on 06-Июн-11, 11:15
	open_basedir в php.ini всегда была
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	60. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Andrew Kolchoogin on 06-Июн-11, 14:23
	> Пока nginx не научится понимать .htaccess и mod_rewrite он вряд-ли сможет заменить > на 100% apache .htaccess там не будет никогда по очевидным причинам, правила mod_rewrite транслируются в конфиг nginx скриптом, доступным через Web.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

38. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
Сообщение от AlexAT (ok) on 06-Июн-11, 10:28
На самом деле много чего не хватает. Схема отдачи контента по схеме конечного автомата для динамики малоприменима. Эксперименты с PHP-FPM встречаются, но это скорее извращение для энтузиастов.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	43. "Http-сервер nginx обслуживает более половины хостов рунета"	+2 +/–
	Сообщение от VX (??) on 06-Июн-11, 11:43
	... извращения которые вполне чудно обслуживают порталы 1m+ хитов в день.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	48. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Codir on 06-Июн-11, 12:15
	> Схема отдачи контента по схеме конечного автомата... Ого! Первый раз слышу такой симбиоз. Не поясните, зачем там КА?
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	49. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от AlexAT (ok) on 06-Июн-11, 12:22
	>> Схема отдачи контента по схеме конечного автомата... > Ого! Первый раз слышу такой симбиоз. Не поясните, зачем там КА? Затем, что каждый воркер nginx обрабатывает энное число запросов псевдопараллельно (с использованием как раз таки схемы работы КА), а не как в классике - воркер (не важно, тред или процесс) на запрос. А насчет 1m+ - я уж не знаю, с чего вы взяли, что nginx на них для динамики используется. nginx на таких ресурсах - это хороший балансер+кеш+статика. Тем более, что 1m в день, даже с учетом 50% загрузки по времени - это совсем ничего, ~23 хита в секунду. У меня есть нагруженный внутренний ресурс с достаточно тяжелыми запросами и практической невозможностью кеширования, который на апаче ~60 хитов в секунду легко держит всего лишь на двух серверах.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	69. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от VX (??) on 07-Июн-11, 00:55
	Взял из того, что видел все это изнутри, допиливал и переводил на fbsd. Кстати, хиты == просмотры страниц. Конечно серверов далеко не 2, а еще сервера серверам рознь. В моем случае там просто все не поместится на 2-х серверах, хотя в качестве эксперимента все запускали на 4-х (nginx, 2 x php-fpm, mysql) и работало без затыков. Но с другой стороны - побольше аппликух хороших и разных - каждый найдет свой инструмент для своей задачи. А так - используйте, что хотите, хвалите, что знаете, но попробовать что-то другое можно всегда - универсальных решений на все случаи жизни не бывает.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	72. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от MVK (??) on 07-Июн-11, 14:30
	> У меня есть нагруженный внутренний ресурс с достаточно тяжелыми запросами и практической > невозможностью кеширования, который на апаче ~60 хитов в секунду легко держит всего > лишь на двух серверах. - у меня был Apache (worker) + Tomcat на виртуалке (256Мб ОП) который нормально держал 1 мегахит в час (~ 270 хит/сек). Запросы были связаны с использованием БД MySQL (висела на той же виртуалке) - что-то типа чата.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	73. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от AlexAT (ok) on 07-Июн-11, 14:37
	>> У меня есть нагруженный внутренний ресурс с достаточно тяжелыми запросами и практической >> невозможностью кеширования, который на апаче ~60 хитов в секунду легко держит всего >> лишь на двух серверах. > - у меня был Apache (worker) + Tomcat на виртуалке (256Мб ОП) > который нормально держал 1 мегахит в час (~ 270 хит/сек). Запросы > были связаны с использованием БД MySQL (висела на той же виртуалке) > - что-то типа чата. Абсолютно согласен. Т.е. не в nginx/Apache дело. У меня, правда, не чат - там некоторые отчеты по полминуты выполняются...
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	79. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 07-Июн-11, 18:05
	> На самом деле много чего не хватает. Схема отдачи контента по схеме > конечного автомата для динамики малоприменима. А вордпрессовский сайт об этом не знает и поэтому работает :)
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	81. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от AlexAT (ok) on 07-Июн-11, 18:06
	>> На самом деле много чего не хватает. Схема отдачи контента по схеме >> конечного автомата для динамики малоприменима. > А вордпрессовский сайт об этом не знает и поэтому работает :) А с чего вы взяли, что собственно вордпрессовский сайт целиком на nginx? Или вы про личный блог на вордпрессе?
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	87. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Аноним (??) on 07-Июн-11, 18:38
	> А с чего вы взяли, что собственно вордпрессовский сайт целиком на nginx? Целиком не целиком, а если туда вместо нжинкса апач поставить - он там сдохнет. А хороший сетевой фронтэнд это уже полдела. И именно апач ему как бэкэнд совсем не обязателен, вообще-то. Более того - не факт что апач лучший вариант бэкэнда. На уровне архитектуры, он болеет тем что при форке на каждый запрос по процессу, память дико загаживается процессами апача. Очень тяжелыми - там висит и пыхпых и сам апач. Уродская какая-то логика.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	90. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от Alex (??) on 07-Июн-11, 20:05
	>> А с чего вы взяли, что собственно вордпрессовский сайт целиком на nginx? > Целиком не целиком, а если туда вместо нжинкса апач поставить - он > там сдохнет. А хороший сетевой фронтэнд это уже полдела. И именно > апач ему как бэкэнд совсем не обязателен, вообще-то. Более того - > не факт что апач лучший вариант бэкэнда. На уровне архитектуры, он > болеет тем что при форке на каждый запрос по процессу, память > дико загаживается процессами апача. Очень тяжелыми - там висит и пыхпых > и сам апач. Уродская какая-то логика. Почитайте про page sharing / copy on write...
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	94. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от MVK (??) on 08-Июн-11, 09:22
	> На уровне архитектуры, он > болеет тем что при форке на каждый запрос по процессу, память > дико загаживается процессами апача. Очень тяжелыми - там висит и пыхпых > и сам апач. Уродская какая-то логика. - уродская логика у того кто собрал Apache как prefork, а потом жалуется что процессы сожрали память и все медленно работает. Соберите его как worker и память чудесным образом освободится, да и производительность вырастет (песня что PHP хреново работает в многопоточном режиме не канает - нормально он работает, а что не работает, то и на preforke к висякам приводит).
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	95. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от AlexAT (ok) on 08-Июн-11, 09:29
	> - уродская логика у того кто собрал Apache как prefork, а потом > жалуется что процессы сожрали память и все медленно работает. Соберите его > как worker и память чудесным образом освободится, да и производительность вырастет > (песня что PHP хреново работает в многопоточном режиме не канает - > нормально он работает, а что не работает, то и на preforke > к висякам приводит). На Linux prefork - единственный нормальный метод. Расход памяти - как уже говорил - см. механизм page sharing / copy on write, он работает прекрасно, если PHP грамотно поставлен (хоть модулем, хоть CGI). К тому же, падение одного субпроцесса приведет только к отвалу 1 клиента, а не целой пачки, сидящей в тредах. Т.е. кому надежность отработки нафиг не нужна - юзают worker, остальные - prefork. Кому надо хитрое - скорее всего, как я, юзают mpm_itk.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	97. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от MVK (??) on 08-Июн-11, 09:41
	> На Linux prefork - единственный нормальный метод. - сильный аргумент, кстати Вы сколько Apache-ей и на протяжении какого срока админите? > К тому же, падение одного субпроцесса приведет только к отвалу 1 клиента, > а не целой пачки, сидящей в тредах. - теоретически, а практически PHP вешает prefork ничуть не хуже чем worker и форкать новые процессы зависший Apache не может, так же как и создавать новые треды в воркере > Т.е. кому надежность отработки нафиг не нужна - юзают worker, остальные - prefork. - я сформулирую иначе: те кто думает что префорк надежней чем воркер, маются от расхода памяти и от загрузки ЦПУ
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	98. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от AlexAT (ok) on 08-Июн-11, 12:06
	> - сильный аргумент, кстати Вы сколько Apache-ей и на протяжении какого срока > админите? Лет 10 уже, 7 площадок разного размера, в т.ч. кластерные. К Вам - аналогичный встречный вопрос. Естественно, никаких "портов" и внешних репозиториев, исключительно собственная сборка со своим набором параметров, индивидуальным для каждой площадки. > - теоретически, а практически PHP вешает prefork ничуть не хуже чем worker > и форкать новые процессы зависший Apache не может, так же как > и создавать новые треды в воркере А практически - ни разу не наблюдал такого поведения. Вы под виндой, или может быть просто не так его готовите? PHP вешает максимум один воркер, если у Вас от PHP виснет сам диспетчер - что-то в канцелярии неладно. > - я сформулирую иначе: те кто думает что префорк надежней чем воркер, > маются от расхода памяти и от загрузки ЦПУ Еще раз: почитайте про page sharing в Linux. А расход динамически распределяемой памяти на каждый процесс PHP аналогичен что для prefork, что для worker. При чем тут CPU - вообще плохо понятно, ибо в Linux нагрузка что от процесса, что от треда - суть одно и то же.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	101. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от MVK (??) on 08-Июн-11, 13:57
	> Лет 10 уже, 7 площадок разного размера, в т.ч. кластерные. К Вам - аналогичный встречный вопрос. - 9 лет, ~ 100 Apache (разных версий 2.0.x, 2.2.x, в основном worker, изредка prefork для особо глючных сайтов) посещаемость самая разная (от 0 до 1 мегахит/час). Собраны из сырцов под Fedora (6,8)/CentOS (5.x) x32 и x64. Про кластерный Apache, к сожалению, слышу впервые. > А практически - ни разу не наблюдал такого поведения. Вы под виндой, > или может быть просто не так его готовите? PHP вешает максимум > один воркер, если у Вас от PHP виснет сам диспетчер - > что-то в канцелярии неладно. - тем не менее факт, prefork тоже вешается >А расход динамически распределяемой > памяти на каждый процесс PHP аналогичен что для prefork, что для worker. - откуда в worker PHP-процессы? (думаю что PHP под worker иначе как модуль запускать бессмысленно). Многопоточная разделяемая библиотека прекрасно экономит оперативку, что очень хорошо заметно при большой посещаемости. > При чем тут CPU - вообще плохо понятно, ибо в > Linux нагрузка что от процесса, что от треда - суть одно и то же. - нет, не так, форканье новых процессов на запрос с подгрузкой PHP-интерпретатора также увеличивает загрузку ЦПУ, по сравнению с созданием новых потоков и использованием уже загруженной в ОП so-шки. Кроме теоретического утверждения могу также подтвердить это наблюдениями над некоторыми высоконагруженными проектами, где вынужденно ставил эксперименты по использованию разных сборок Apache.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	102. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от AlexAT (ok) on 08-Июн-11, 14:04
	> Про кластерный Apache, к сожалению, слышу впервые. Кластер может быть собран по-разному. В моем случае наиболее популярна связка Apache+glusterfs+NDBD > - тем не менее факт, prefork тоже вешается Вешается воркер, может быть терминирован по времени простоя. На spawning новых процессов это никак не влияет. Если прекращается spawning - значит повис процесс диспетчера, и это уже тревожный сигнал, не связанный с PHP. > - откуда в worker PHP-процессы? (думаю что PHP под worker иначе как В контексте обсуждения без разницы - процесс или "тред" (который тоже процесс, в идеологии Linux). Естественно, речь идет о модуле. > - нет, не так, форканье новых процессов на запрос с подгрузкой PHP-интерпретатора > также увеличивает загрузку ЦПУ, по сравнению с созданием новых потоков Это всего лишь fork(), ничего никуда не подгружается - модуль уже в памяти. В случае обработки скрипта дополнительно тратится некоторое время на инициализацию интерпретатора, но в условиях, где не более 1000 запросов в секунду, это - семечки. К слову говоря, то же самое время тратится и в worker на инициализацию интерпретатора в контексте треда. > использованием уже загруженной в ОП so-шки. so'шка, кстати, в prefork тоже общая. Она при вызове fork() наследуется от диспетчера в новый процесс. Кстати говоря, у worker есть существенные проблемы, в т.ч. со стабильностью и с распределением памяти, просто Вы, видимо, с ними не столкнулись. Есть такая вещь, как размер стека на поток... и вот с ней-то связано 99% проблем с масштабируемостью и стабильностью worker. Ну и у меня как-то так получается, что worker неприменим вообще - ибо надо исполнять несколько вхостов от разных пользователей. Я использую mpm_itk - а это двойной fork() на запрос. Нагрузка мало отличается от классического prefork.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	96. "Http-сервер nginx обслуживает более половины хостов рунета"	+/–
	Сообщение от AlexAT (ok) on 08-Июн-11, 09:32
	>> А с чего вы взяли, что собственно вордпрессовский сайт целиком на nginx? > Целиком не целиком, а если туда вместо нжинкса апач поставить - он > там сдохнет. О5 же, с чего вы это взяли? И где гарантии, что там не апач? Нгинхом хорошо отдавать статику и проксить, для остального существуют другие решения. Хотя проксирование у него - тоже песня, создание файлов для буферизации проксируемого контента - вещь неизбежная, но вот отсутствие возможности перехода для больших ответов в режим чистого сетевого прокси, без хранения - это песня.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

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

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