How much requests each can handle? How many RAM needed?
As I remember FastCGI are opened initialized processes, each can handle one request.
What about multithreading?
Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.Sign up to join this community
About a year ago, Microsoft published a benchmark of IIS + WCF called StockTrader. Not exactly a webpage-oriented benchmark. Anyway it showed some very good performance using IIS, worker processes, and .NET code.
7 or 8 years ago the benchmarking on web loads was more active. But at some point it seemed like the performance was so good, that on a single standard high-volume intel server, whether you were using Linux+??? or Windows+.NET, you were going to get really good perf. (Assuming reasonable application design).
I can't really comment though, on PHP and FastCGI.
And I don't know anyone who has benchmarked Linux+Mono+XSP versus Windows+.NET+ASPNET on the same hardware.
I am actively developing in both PHP & ASP.Net. I can't claim deep knowledge of IIS, or NGINX but I am VERY familiar with Apache and Lighttpd.
ASP.Net uses a threaded architecture that is very much a part of the web server it's self. Static variables retain their value between requests and in between users. This is where ASP.Net get's most of it's speed advantage from. The shared memory is stored inside each individual process, and between threads. Separate processes do not share memory. So when you scale beyond one server, much of this advantage is lost.
PHP is built in the old fashion CGI style, where each request is a blank slate. This means that any common information either has to be fetched from a common store or entirely regenerated. PHP is NOT slow, it is different. Most major operations in PHP are calling modules written in C, so they are lightning fast. PHP executing on it's own is not as fast as a compiled language, but is by no means slow. There are (very common) modules for PHP which cache compiled (in memory) versions of the code, and can increase performance between 4 and 10 times.
PHP has been around for a while, and many solutions to it's CGI style exist. xcache offers a value store very similar to ASP.Net's static variables. Memcache offers a slightly slower but better scaling (between physical servers) solution to persistent shared variables.
ASP.Net offers much more formalism and structure. But bad programmers can make a mess in any language. If you choose ASP.Net you should investigate some of the excellent NON-Microsoft libraries for development. (eg NHIbernate & http://www.castleproject.org/)
My personal preference (when i'm not paid to do otherwise) is PHP. Even though it takes a speed penalty, it is easier to develop in and less complex to scale up (even if it would require more PHP servers than .Net). Servers are much cheaper than programmers.
In either case any Web > 2.0 application will be data bound, and the database configuration will have a much more profound impact on performance than the language choice.
I did some simple benchmarking of an asp.net mvc3 website running in IIS7 on windows 7 and the same site running on centos 6.2 with mod_mono and mono 2.11.2. They are both virtual machines on the same hardware running in virtual box. The actual machine is a Core i5.
using apache bench from a different linux machine on the same network (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)
I'm sure you can tweak settings, etc. But unless there's something easy I'm missing, IIS seems to be many times faster running asp.net mvc.
The view itself was basically empty, just had a single word in it.
It's not a great benchmark, certainly not something I'd give to my boss. I suspect mono would get a better showing with nginx or lighttpd but I don't have them set up right now.
We run an asp.net MVC application in both IIS and XSP, and IIS beats XSP in in both performance and reliability.
You can do the performance tests pretty easily, but XSP isn't really designed for production environments. We filed a bug that resulted in the XSP process to crashing every now and then, which they are not going to fix (it involved some deep architecture changes apparently). In the end we just wrapped and restarted the process when it died, but you should be aware that the two (XSP and IIS) are very different beasts.
If you are on windows, use IIS. IIS7 isn't that bad at all.
There are great benchmarks here for IIS and nginx: (and Apache, Cherokee, G-WAN, Lighttpd, Ulib, etc.)
Using PHP, Java and C#:
I have never seen so clear comparisons done anywhere else. The test source code (in PHP, Java, C#) is also available here:
Hope it helps.
I do have one small opinion here, the past few years I worked with .net C# with IIS on high scaled website we started with IIS6 and now moved to IIS7. 99% IIS did the job very well with .net (Caching, handling requests and etc...)
As Linux is cheaper and I love centos I did try to migrate to mono with one test environment and I noticed some performance change. Maybe I didnt know how to set up the environment in a good way.
My personal experience now:
If I want to make any website with php I install it on my linux server (Centos6, nginx, php-fpm, mariadb, apc cache)
When I need to make something in C# I do install it on windows server 2008, less headaches and more realibility and support.
The only disadvantage of Microsoft Server is the price. If you are a small developer the minimum hardware requirements for an MS system are a lot lower than those of a Linux machine.
I would not recommend IIS.
First, it misses a lot of VERY VERY important features (such as dos_evasive), second, it uses a lot of memory, third, configuration is a nightmare and different on every version of IIS (write 'a' documentation - write 3 [iis 5,6,7]). IIS performance is not good either, fourth you will run into memory segmentation problems (care to restart the server every 20 minutes?) and fifth and most fatally, it requires a MS operating system (1 to 2 GB ram just to run the OS). And besides all that, a decent Firewall software costs an extra fortune.
I come from a Linux background, and I work in a windows corporation right now.
And I can only tell you, that this switch was the worst decision I have ever made.
Not only will you have to work on a notoriously unstable platform, but also will you have difficulties writing installers (windows installer cannot chainload, a thing every Linux installer can, applications can't delete themselfs - so no real self-updating applications, and you have to write the updater yourself, whereas in Linux, apt takes care of everything). And you will also switch to a platform where IE is the default browser.
I can only tell you that I spend days making web applications compatible for IE where you only need hours for Linux, because you don't have to fix all those MAJOR IE browser bugs with YOUR CODE, since IE doesn't run on Linux (well you can actually, but it's not legal)...