The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

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

"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="http://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
Новость: http://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 email(??) 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 | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2022 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру