Как я понимаю, nginx отдает статический контент намного быстрее т.к. на каждый запрос не создается свой поток и при очень большом количестве запросов он просто должен быть намного быстрее IIS. Это так? Т.е. сейчас IIS просто не справится с highload приложением, точнее отнимет намного больше ресурсов? В этом контексте IIS проигрывает nginx или это как-то решается?
Здравствуйте, FreddieM, Вы писали:
FM>Как я понимаю, nginx отдает статический контент намного быстрее т.к. на каждый запрос не создается свой поток и при очень большом количестве запросов он просто должен быть намного быстрее IIS. Это так? Т.е. сейчас IIS просто не справится с highload приложением, точнее отнимет намного больше ресурсов? В этом контексте IIS проигрывает nginx или это как-то решается?
А может не парить и устроить "забег"?
Тут же самое главное не скорость отдачи контента, а затрачиваемые на это ресурсы.
Здравствуйте, Skipy Rich, Вы писали:
SR>А кто сказал, что IIS создаёт поток на каждый запрос?
Да я больше скажу... часть IIS'а живет в ядре и может раздавать статику даже не выходя в user mode.
Вот и гоняйся потом с этим читером...
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH> SR>А кто сказал, что IIS создаёт поток на каждый запрос?
WH> Да я больше скажу... часть IIS'а живет в ядре и может раздавать статику даже не выходя в user mode. WH> Вот и гоняйся потом с этим читером...
Отчего же, в таком случае, на кывте nginx, а не IIS стот как фронтенд?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, WolfHound, Вы писали:
WH>> SR>А кто сказал, что IIS создаёт поток на каждый запрос?
WH>> Да я больше скажу... часть IIS'а живет в ядре и может раздавать статику даже не выходя в user mode. WH>> Вот и гоняйся потом с этим читером...
H>Отчего же, в таком случае, на кывте nginx, а не IIS стот как фронтенд?
Исключительно от того, что в данном случае, nginx позволяет весьма гибко спрятать все, что есть на сервере за 80-ый порт. Если заглянуть на неймсервер RSDN, то будет видно, что на нем крутятся:
1) svn.rsdn.ru
VisualSVN собственной персоной (читай: спиленный напильником по самую мушку Apache)
Крутится на кастомной сборке WAMP (XAMPP, если быть точным), за исключением /Banners/ — этот локейшн уходит на IIS, т.к. баннеры генерятся Nemerle@ASP.NET кодом.
Собственно куски сайта и веб-сервис януса. Крутятся под IIS.
Это только что, что предназначено для паблика, есть еще и закрытые ресурсы для тима. И как прикажешь разруливать весь этот зоопарк на одном порту, учитывая еще и то, что в перспективе, часть этих хостов может быть физически вынесена на второй сервер (/me очень надеется, что рано или поздно это произойдет)? Nginx используется только как реверс-прокси для всего перечисленного, кроме статики на files.rsdn.ru, ее он отдает сам. Не потому что он быстрее IIS, а потому что в этой конфигурации и запросы и ответы в любом случае идут через него и смысла обрабатывать их IIS'ом нет. Кроме того, это весьма кардинальный способ исключения уязвимостей типа LFI (local file including).
Когда, чуть меньше года назад, на RSDN была организована DDOS-атака, помогло лишь выставление наружу IIS со всем, что перечислено в п.6 и отключение nginx нафиг. Позднее, я около недели по ночам проводил нагрузочное тестирование, пытаясь оттюнить nginx так, чтобы он давал на статике производительность, сравнимую с IIS. Но чуда не приключилось, IIS как рвала его как тот тузик, так и продолжала рвать, как только количество хостов в эмулируемом ботнете переваливало за 2500-3000. До этого порога, они показывали сравнимую производительность.
Что впрочем, не умаляет всех его достоинств на *nix'ах.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>MS верна себе — давать свои продуктам предпочтение и использовать методы, которые другие не могут себе позволить.
http.sys можно использовать даже из дотнета. Бери да пользуй.
Здравствуйте, FreddieM, Вы писали:
FM>Как я понимаю, nginx отдает статический контент намного быстрее
Не угадал. Статику IIS отдает быстрее.
FM> т.к. на каждый запрос не создается свой поток
Полная ерунда.
FM> и при очень большом количестве запросов он просто должен быть намного быстрее IIS. Это так?
Нет.
Но самое главное, что противопоставлять IIS и nginx вообще бессмысленно, это разноплановые продукты. IIS полномасштабный веб-сервер и сервер приложений, а nginx это reverse proxy прежде всего.
Здравствуйте, kochetkov.vladimir, Вы писали:
k> Но чуда не приключилось, IIS как рвала его как тот тузик, так и продолжала рвать, как только количество хостов в эмулируемом ботнете переваливало за 2500-3000. До этого порога, они показывали сравнимую производительность.
Количество хостов для nginx при раздаче статики не должны иметь значения — он упирается либо в сеть, либо в диск. По крайней мере, это утверждение справедливо для православных ОС.
Вот на вскидку тест на домашней машинке без каких-либо оптимизаций ОС (настройки по умолчанию). К сожалению ab, как утилита тестирования, ущербна более чем полностью и подчистую выела одно (из двух возможных) ядер (а параллелиться она не умеет). В это же время на втором ядре курил от безделия nginx.
# ab -c 10000 -n 500000 -r 'http://localhost/favicon.ico'
Server Software: nginx/0.8.41
Server Hostname: localhost
Server Port: 80
Document Path: /favicon.ico
Document Length: 2550 bytes
Concurrency Level: 10000
Time taken for tests: 97.325 seconds
Complete requests: 500000
Failed requests: 0
Write errors: 0
Total transferred: 1389747065 bytes
HTML transferred: 1281683550 bytes
Requests per second: 5137.43 [#/sec] (mean)
Time per request: 1946.500 [ms] (mean)
Time per request: 0.195 [ms] (mean, across all concurrent requests)
Transfer rate: 13944.77 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 200 1085 1018.1 788 10381
Processing: 220 846 319.0 768 2247
Waiting: 169 649 266.8 597 1708
Total: 694 1931 1009.7 1625 11297
Percentage of the requests served within a certain time (ms)
50% 1625
66% 1807
75% 2077
80% 2269
90% 2837
95% 4593
98% 5146
99% 5260
100% 11297 (longest request)
Здравствуйте, WolfHound, Вы писали:
WH> Да я больше скажу... часть IIS'а живет в ядре и может раздавать статику даже не выходя в user mode. WH> Вот и гоняйся потом с этим читером...
Здравствуйте, FreddieM, Вы писали:
FM> Как я понимаю, nginx отдает статический контент намного быстрее т.к. на каждый запрос не создается свой поток и при очень большом количестве запросов он просто должен быть намного быстрее IIS. Это так?
Да, это так, при условии, что nginx будет работать в родной для него среде — т.е. на *nix. Если же ставить его под windows, то:
В качестве метода обработки соединений используется select, поэтому не стоит ожидать высокой производительности и масштабируемости: пока это бета-версия.
Другими словами, его обгонит любой, кто будет использовать хоть какую-то оптимизацию при работе.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Добавлю. В системных вызовах есть 2-битовое поле вида АПИ. Одно значение — kernel, другое — win32k.sys, третье — IIS, четвертое зарезервировано.
Поделитесь источником плиз, Руссинович о таком предательски молчит. И рассказывает о всякой фигне типа хитрой диспетчеризации, Zw и Nt префиксах (см врезку Kernel-Mode System Service Dispatching)
Здравствуйте, WolfHound, Вы писали:
SR>>А кто сказал, что IIS создаёт поток на каждый запрос? WH>Да я больше скажу... часть IIS'а живет в ядре и может раздавать статику даже не выходя в user mode. WH>Вот и гоняйся потом с этим читером...
Здравствуйте, Anton Batenev, Вы писали:
AB>Так и nginx sendfile может спокойно использовать.
Ему всеравно в user mode переключаться надо что бы sendfile вызвать.
А IIS все делает не выходя из ядра.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Когда, чуть меньше года назад, на RSDN была организована DDOS-атака, помогло лишь выставление наружу IIS со всем, что перечислено в п.6 и отключение nginx нафиг. Позднее, я около недели по ночам проводил нагрузочное тестирование, пытаясь оттюнить nginx так, чтобы он давал на статике производительность, сравнимую с IIS. Но чуда не приключилось, IIS как рвала его как тот тузик, так и продолжала рвать, как только количество хостов в эмулируемом ботнете переваливало за 2500-3000. До этого порога, они показывали сравнимую производительность.
А как ты проводил такое тестирование? Syn-флудом или честными запросами? Если syn-флудом, то может и так, потому что IIS может что-то сделать в кернел-моде. Если полноценными запросами, хотя бы статикой, то не верю.
Да, и как ты смог эмулировать 3000 машин? Для этого их нужно иметь несколько десятков самому. Или ты просто забивал канал под завязку флудом? Но это не совсем честное тестирование.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Добавлю. В системных вызовах есть 2-битовое поле вида АПИ. Одно значение — kernel, другое — win32k.sys, третье — IIS, четвертое зарезервировано.
S>Поделитесь источником плиз, Руссинович о таком предательски молчит.
Нет, не молчит. Именно из книги Соломона-Руссиновича
As you'll see in Chapter 6, each thread has a pointer to its system service table. Windows 2000 has two built-in system service tables, but up to four are supported. The system service dispatcher determines which table contains the requested service by interpreting a 2-bit field in the 32-bit system service number as a table index. The low 12 bits of the system service number serve as the index into the table specified by the table index. The fields are shown in Figure 3-9.
Figure 3-9 System service number to system service translation
<skipped — PD>
A primary default array table, KeServiceDescriptorTable, defines the core executive system services implemented in Ntosrknl.exe. The other table array, KeServiceDescriptorTableShadow, includes the Win32 USER and GDI services implemented in the kernel-mode part of the Win32 subsystem, Win32k.sys. The first time a Win32 thread calls a Win32 USER or GDI service, the address of the thread's system service table is changed to point to a table that includes the Win32 USER and GDI services. The KeAddSystemServiceTable function allows Win32k.sys and other device drivers to add system service tables. If you install Internet Information Services (IIS) on Windows 2000, its support driver (Spud.sys) upon loading defines an additional service table, leaving only one left for definition by third parties. With the exception of the Win32k.sys service table, a service table added with KeAddSystemServiceTable is copied into both the KeServiceDescriptorTable array and the KeServiceDescriptorTableShadow array.
>И рассказывает о всякой фигне типа хитрой диспетчеризации, Zw и Nt префиксах (см врезку Kernel-Mode System Service Dispatching)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет, не молчит. Именно из книги Соломона-Руссиновича
Ух ты! Спасибо! В 5м издании абзац заканчивается на "The KeAddSystemServiceTable function allows Win32k.sys to add a system service table.". Вот что единственное, что не нравится в Руссиновиче — пока не сравнишь два издания, об изменениях во внутренностях не узнаешь
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Нет, не молчит. Именно из книги Соломона-Руссиновича S>Ух ты! Спасибо! В 5м издании абзац заканчивается на "The KeAddSystemServiceTable function allows Win32k.sys to add a system service table.". Вот что единственное, что не нравится в Руссиновиче — пока не сравнишь два издания, об изменениях во внутренностях не узнаешь
Одно из двух — либо убрали, либо к 5 изданию он посчитал, что это не так уж важно — книга-то не резиновая.
А поле там по-прежнему двухбитовое ?
