Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an ASP.NET application that will be hosted on Windows Server 2003. Below is the average traffic estimate that the site will be having.

  • Unique page views - around 150,000 per day
  • Number of visitors - around 30,000 per day

Current hardware of the machine:

  • Windows server 2003, standard edition - Service Pack2
  • Intel X3330 - 2.66 GHz
  • 2GB RAM

Will this hardware be able to handle this much traffic. If not what will be an ideal combination to scale the site?


share|improve this question
You all THAT large scale? ;) My first large scale application had 400.000 visitors in one hour. That said, terribly outdated machine. – TomTom Jul 3 '10 at 5:24

It all depends on your application - at one end of the scale it could just print 'hello world', at the other it could be a complex decision-support platform - you need to benchmark a sizable number of potential users - at least 50 or so simulated users - so that you can see how it behaves.

In terms of kit, well you have a single 2008 quad-core CPU - this may well do what you need but what worries me is you have little 'headroom' if things start getting hot. That chip can't be replaced with a newer nehelam-based chip with hyperthreading or >4-cores. If I had no idea how my machine was going to respond I'd personally like the comfort of knowing I could move to a faster/more capable chip or indeed have the ability to add a second CPU. Also I'd suggest that you move to 4GB as memory is very cheap right now and it may significantly help for such a small investment.

Good luck with your new site.

share|improve this answer
+1 - Exactly. Let's not forget about disk configuration. Have a fast an capable IO system is very much welcome, especially if the application is reading/writing a lot. – Pier Jul 2 '10 at 7:56
Thanks for your answers. To clarify more, this site will be used to make hotel reservations. For data exchange, it depends on a WCF Webservice. Client application is not involved in any database operation by itself. It contacts the web service for all requests. The webservice is responsible for all database operations. Currently the web service and database(MsSql) both are sharing the same server with client application. This leads to another question. Is it a good idea or should we deploy them on separate servers? – user47379 Jul 2 '10 at 9:22

+1 for @Chopper3's scaling points.

If your security model permits it, you might want to look at hosting this in the cloud; e.g. Amazon. Scaling issues become less risky when you can add another server in ~15 minutes. You've also got redundancy that a single box can't do.

I'm currently running a site on AWS with ~2500 daily users, >800K requests, on 3 load balanced small-size web servers (32bit, W2K8, 1.7GB memory, 2 processors) + 1 medium-sized database box (64bit, W2K8, 7.5GB memory, 2 processors).

All boxes average less than 35% CPU, with enough headroom for peak periods.

share|improve this answer
Well, we cannot move to a cloud like amazon etc. So that is not an option. Any suggestions for hardware? – user47379 Jul 2 '10 at 14:51
Grab a dual Opteron server, plug in plenty of ram (16-32gb) and a lot of discs, then you actualyl can kep everything on one system. – TomTom Jul 3 '10 at 5:25

Vijay - Responding to your second question.

Currently the web service and database(MsSql) both are sharing the same server with client application. This leads to another question. Is it a good idea or should we deploy them on separate servers?

Given the estimation you provided we are looking at over 104 views perminute. And that is assuming an equal load over 24 hrs which we know will not happen. I, personally, would say get that ap off my database server, if I were your DBA.

You are probably looking at a large number of reads from disk for both the ASPX pages and the database files. This will certainly cause some sort of disk contention. If I were you I would be sizing this deployment to make it scale, placing the DB server on the same server as the application is generally not a good idea for scaling. If this were some little departmental application that would only be serving 100 people 9-to-5, ok, but it is not.

share|improve this answer
Thanks for the answer Robert. So, basically you are suggesting that we should keep the DB on separate servers. And what about the web service? It is also on the same server. – user47379 Jul 2 '10 at 14:29

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.