Сколько запросов может обработать каждый? Сколько оперативной памяти нужно?
Насколько я помню, FastCGI - это открытые инициализированные процессы, каждый может обработать один запрос.
А как насчет многопоточности?
Я активно развиваюсь как в PHP, так и в ASP.Net. Я не могу претендовать на глубокое знание IIS или NGINX, но я ОЧЕНЬ знаком с Apache и Lighttpd.
ASP.Net использует многопоточную архитектуру, которая во многом является частью самого веб-сервера. Статические переменные сохраняют свое значение между запросами и между пользователями. Именно здесь ASP.Net получает максимальное преимущество в скорости. Общая память хранится внутри каждого отдельного процесса и между потоками. Отдельные процессы не разделяют память. Поэтому при масштабировании за пределы одного сервера большая часть этого преимущества теряется.
PHP построен в старом стиле CGI, где каждый запрос - это чистый лист. Это означает, что любая общая информация либо должна быть получена из общего хранилища, либо полностью восстановлена. PHP НЕ медленный, он другой. Большинство основных операций в PHP - это вызов модулей, написанных на C, поэтому они работают молниеносно. Сам по себе PHP выполняется не так быстро, как скомпилированный язык, но ни в коем случае не медленнее. Существуют (очень распространенные) модули для PHP, которые кэшируют скомпилированные (в памяти) версии кода и могут повысить производительность от 4 до 10 раз.
PHP существует уже давно, и существует множество решений для его стиля CGI. xcache предлагает хранилище значений, очень похожее на статические переменные ASP.Net. Memcache предлагает немного более медленное, но лучшее решение для масштабирования (между физическими серверами) для постоянных общих переменных.
ASP.Net предлагает гораздо больше формализма и структуры. Но плохие программисты могут испортить любой язык. Если вы выберете ASP.Net, вам следует изучить некоторые из отличных библиотек, не принадлежащих Microsoft, для разработки. (например, NHIbernate & http://www.castleproject.org/)
Мое личное предпочтение (когда мне не платят за иное) - PHP. Несмотря на то, что это требует снижения скорости, его легче разрабатывать и менее сложно масштабировать (даже если для этого потребуется больше серверов PHP, чем .Net). Серверы намного дешевле программистов.
В любом случае любое приложение Web> 2.0 будет привязано к данным, и конфигурация базы данных будет иметь гораздо более сильное влияние на производительность, чем выбор языка.
Я провел простое тестирование веб-сайта asp.net mvc3, работающего в IIS7 на Windows 7, и того же сайта, работающего на centos 6.2 с mod_mono и mono 2.11.2. Это обе виртуальные машины на одном оборудовании, работающие в виртуальной машине. Фактическая машина - Core i5.
использование apache bench с другой Linux-машины в той же сети (ab -n 1000 -c 100)
Centos 6.2 (default settings, no other sites running on 8088)
Server Software: Apache/2.2.15
Server Hostname: 192.168.1.208
Server Port: 8088
Document Path: /
Document Length: 24 bytes
Concurrency Level: 100
Time taken for tests: 3.401 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 354000 bytes
HTML transferred: 24000 bytes
Requests per second: 294.01 [#/sec] (mean)
Time per request: 340.124 [ms] (mean)
Time per request: 3.401 [ms] (mean, across all concurrent requests)
Transfer rate: 101.64 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 3 6.4 0 25
Processing: 14 321 71.1 325 483
Waiting: 14 321 71.1 325 483
Total: 39 324 67.8 326 483
Percentage of the requests served within a certain time (ms)
50% 326
66% 344
75% 358
80% 370
90% 408
95% 426
98% 441
99% 445
100% 483 (longest request)
(Again default settings, Windows 7 x64)
Server Software: Microsoft-IIS/7.5
Server Hostname: 192.168.1.115
Server Port: 8088
Document Path: /
Document Length: 27 bytes
Concurrency Level: 100
Time taken for tests: 0.469 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 294783 bytes
HTML transferred: 27351 bytes
Requests per second: 2131.09 [#/sec] (mean)
Time per request: 46.924 [ms] (mean)
Time per request: 0.469 [ms] (mean, across all concurrent requests)
Transfer rate: 613.48 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 4 17 4.6 17 27
Processing: 12 28 6.9 28 61
Waiting: 9 22 6.9 22 55
Total: 24 45 7.0 45 67
Percentage of the requests served within a certain time (ms)
50% 45
66% 48
75% 49
80% 50
90% 52
95% 55
98% 59
99% 62
100% 67 (longest request)
Я уверен, что вы можете настроить параметры и т. Д. Но если мне не хватает чего-то простого, IIS, похоже, во много раз быстрее работает с asp.net mvc.
Само представление было в основном пустым, в нем было всего одно слово.
Это не лучший тест, и уж точно не то, что я бы дал своему боссу. Я подозреваю, что моно будет лучше отображаться с nginx или lighttpd, но сейчас у меня их нет.
Мы запускаем приложение asp.net MVC как в IIS, так и в XSP, и IIS превосходит XSP как по производительности, так и по надежности.
Вы можете довольно легко провести тесты производительности, но XSP не предназначен для производственных сред. Мы зарегистрировали ошибку, которая время от времени приводила к сбою процесса XSP, которую они не собираются исправлять (очевидно, это связано с некоторыми глубокими изменениями архитектуры). В конце концов, мы просто обернули и перезапустили процесс, когда он умер, но вы должны знать, что эти два (XSP и IIS) очень разные звери.
Если вы работаете в Windows, используйте IIS. IIS7 совсем не так уж плох.
Около года назад Microsoft опубликовала тест IIS + WCF под названием StockTrader. Не совсем ориентированный на веб-страницы тест. В любом случае он показал очень хорошую производительность при использовании IIS, рабочих процессов и кода .NET.
7 или 8 лет назад тестирование веб-нагрузок было более активным. Но в какой-то момент показалось, что производительность была настолько хорошей, что на одном стандартном крупномасштабном сервере Intel использовали ли вы Linux + ??? или Windows + .NET, вы получите действительно хорошую производительность. (При условии разумного дизайна приложения).
Однако я не могу комментировать PHP и FastCGI.
И я не знаю никого, кто бы сравнивал Linux + Mono + XSP с Windows + .NET + ASPNET на одном и том же оборудовании.
Здесь есть отличные тесты для IIS и nginx: (а также Apache, Cherokee, G-WAN, Lighttpd, Ulib и т. д.)
На Linux:
На Windows:
http://gwan.ch/en_windows.html
С помощью PHP, Java и C #:
Я никогда не видел таких четких сравнений где-либо еще. Исходный код теста (на PHP, Java, C #) также доступен здесь:
Надеюсь, поможет.
У меня есть одно небольшое мнение: последние несколько лет я работал с .net C # с IIS на крупномасштабном веб-сайте, который мы начали с IIS6, а теперь перешли на IIS7. 99% IIS очень хорошо справился со своей задачей с .net (кэширование, обработка запросов и т. Д.)
Поскольку Linux дешевле, и мне нравятся centos, я попытался перейти на моно с одной тестовой средой, и я заметил некоторое изменение производительности. Может, я не знал, как правильно настроить среду.
Мой личный опыт сейчас:
Если я хочу создать какой-либо веб-сайт с php, я устанавливаю его на свой Linux-сервер (Centos6, nginx, php-fpm, mariadb, apc cache)
Когда мне нужно что-то сделать на C #, я устанавливаю это на Windows Server 2008, меньше головной боли, больше надежности и поддержки.
Единственный минус Microsoft Server - цена. Если вы небольшой разработчик, минимальные требования к оборудованию для системы MS намного ниже, чем для машины с Linux.
Я бы не рекомендовал IIS. Во-первых, он упускает много ОЧЕНЬ ОЧЕНЬ важных функций (таких как dos_evasive), во-вторых, он использует много памяти, в-третьих, конфигурация - это кошмар и разная для каждой версии IIS (напишите документацию «a» - напишите 3 [iis 5,6,7]). Производительность IIS тоже невысока, в-четвертых, вы столкнетесь с проблемами сегментации памяти (нужно перезапускать сервер каждые 20 минут?), И в-пятых, что наиболее фатально, требуется операционная система MS (оперативная память от 1 до 2 ГБ только для запуска ОС) . Кроме того, хороший брандмауэр стоит целого состояния.
Я пришел из Linux и сейчас работаю в корпорации Windows.
И я могу только сказать вам, что этот переход был худшим решением, которое я когда-либо принимал.
Вам не только придется работать на заведомо нестабильной платформе, но и возникнут трудности с написанием установщиков (установщик Windows не может загружать по цепочке, что может делать любой установщик Linux, приложения не могут удалять себя сами, так что никаких реальных самообновляющихся приложений и вам нужно написать программу обновления самостоятельно, тогда как в Linux apt обо всем позаботится). И вы также переключитесь на платформу, где IE является браузером по умолчанию.
Я могу только сказать вам, что я трачу дни на создание веб-приложений, совместимых с IE, где вам нужны только часы для Linux, потому что вам не нужно исправлять все эти ОСНОВНЫЕ ошибки браузера IE с ВАШИМ КОДОМ, поскольку IE не работает в Linux ( ну вообще-то можно, но это не законно) ...