IIS Performance

Question

We have the following setup:

Virtual server, Intel Xeon X5650 @ 2.67Ghz (4 processors) 8GB RAM Windows server 2008 Standard 64bit Sql Server Express IIS 7.5

Our database is only 200mb. We are running an ASP.net app. We recently ran into some performance issues, ~200 concurrent connections was causing 100% CPU usage (mostly consumed by IIS) and bringing the response time to around 20sec! After some tweaks to our code we have been able to run a load test from loader.io with 1500 concurrent users over 1 minute and our response time at the end was around 5 seconds and CPU was around 95%, again consumed mainly by IIS, our memory was sitting at around 4GB usage. However we are expecting bigger spikes than 1500, anywhere up to around 4000 users in a short amount of time.

My questions are the following: 1) Is this normal performance for our current setup? Our site is quite intensive on the database and we are using Entity Framework. 2) Would upgrading to Sql Web edition have any benefit seeing as though our Database is so small? 3) Do you think that this type of setup could handle 4000 users? 4) Any suggestions on what we could do to handle this load?

I know this is somewhat subjective, but any answers are much appreciated.

did you tried finally with **loader.io** ? any good patterns and practices about performance when a website has more 1000 concurrent users ? — Kiquenet, Jun 22 '16 at 12:20
http://stackoverflow.com/questions/1169634/limitations-of-sql-server-express — Pleun, Jun 22 '16 at 12:23

score 1 · Answer 1 · answered Dec 06 '12 at 05:52

Is this normal performance for our current setup?

Depends on your code. Did you profile the code to make sure you dont have anything stupid in there?

Our site is quite intensive on the database and we are using Entity Framework.

Again, did you pofile to figure out you spend a lot of time in entity framework? It is slow, ut the question is what "intensive" means. This is what profilers are for.

Would upgrading to Sql Web edition have any benefit seeing as though our Database is so small?

Help, my pizza comes too late. Wiould upgrade to a larger car help? You say yourself that you spend the time in IIS, not sql server.

Do you think that this type of setup could handle 4000 users?

You think my car is big enough? Note I don't tell you what I need it for. Without looking at usage patterns and your code - no idea. THAT SAID: the server is pathetic compared to what you buy today. As such, this is a irrelevant question - just upgrade if you have to.

Any suggestions on what we could do to handle this load?

Load test + profiler, optimize code. Get bigger server. Realize that we dont have crystal balls to figure out how good / bad / stupid your code is.

score 0 · Answer 2 · answered May 26 '13 at 16:56

0

Number one question arising here, is: did you deploy RELEASE or DEBUG compiled binaries of your project?

Upgrade to WebEdition will not solve any problem here, since the difference in the versions is very simple: WebEdition is just throttled in the internal scheduler/etc. - so you will be just fine with the standard edition.

answered May 26 '13 at 16:56

johngrinder

422
4
14

OP is not using standard but express. that uses only one core and not all the memory – Pleun Jun 22 '16 at 12:24

score 0 · Answer 3 · answered May 26 '13 at 17:58

My experience is that the most crucial aspect of concurrent request is the amount of server memory and the consumption of this memory by your code.

As the physical memory is consumed, the server starts to swap from physical to virtual memory which slows down processing dramatically and leads to symptoms you describe.

I would start with putting another 8gb of ram into the server. In the meantime try to optimize your code so that less data is processed during requests or less memory is used. Also, move sql server to a separate machine so that there is no competition between iis and sql server when it comes to memory availability.

score 0 · Answer 4 · answered Apr 17 '14 at 06:18

With your current machine, I doubt the problem is the IIS itself, but rather related to the way your app is designed and/or utilize frameworks. I personally learned just recently that IIS requests including multiple rounds trips to the database can be measured in hundreds of micro-seconds, not hundreds of milliseconds... A single locking bug, or unbalanced queuing can limit your application scalability and regardless of your hardware specs [https://twitter.com/michaelzino/status/454512110165184512]. Entity Framework is known for validating your models against the database schema for the first initial calls. I would suggest profiling your app layers, starting from the data access layer, or the intrinsic database calls, and going up.

IIS Performance

4 Answers4