0

I'm running an ASP.NET website with a SQL Server database and another server side application which does processing to support the website on a Windows 2008 Web Server 32bit operating system.

The server is normally at 95% CPU usage with sqlserver.exe, w3wp.exe and my processing app taking up most of the CPU resources and the majority of RAM is also being used - which I understand is normal.

I intend to invest some money into the configuration of my servers to improve the speed of my website and to support it as it grows and was wondering if anyone had any advice on the situation.

It appears for the same price of upgrading to one Quad Core Xeon 2.66Ghz X3353 is around the same cost of running two Core 2 Quad Core Q8200 systems.

Would my money be better spent upgrading to a single Xeon machine or splitting database and asp.net front end between the lower spec Core 2 Quad Core systems?

Reference for current server -

Typical CPU Usage http://g33.org/cpuUsage.gif

Improve this question
1
  • CPU load can be a result of waiting for disk I/O, i.e. CPU load can be a symptom of too slow disk I/O. How big is your dataset, could your DB keep all your data cached in RAM? What is your data access pattern, do you generate many reads, many writes, or both, to the DB? What's you current disk I/O and on which hardware? Could you save a lot of CPU by caching key frequently accessed shared resources? That's a lot of questions, I know, but in my experience RAM and disk I/O are often the first real bottlenecks, because modern CPUs are really fast...
    – user2874
    Commented Aug 30, 2009 at 13:33

5 Answers 5

Reset to default
3

Two boxes will more than double the complexity of your system and more than halve your reliability. There is the very real possibility that you'll wind up with a system that's slower than your current system if you rearchitect it without understanding exactly why it isn't fast enough.

Have you profiled the bottlenecks?

The most reliable way to make your system faster is simply to replace it with something that is exactly the same but faster.

Improve this answer
1
  • +1 I like the simplicity factor. If we were discussing theory the answer might be different, but from an ease of installing and maintaining I like your answer.
    – Aaron
    Commented Aug 30, 2009 at 20:50
2

I agree with Ryaner. If the only cost is hardware purchase, go for the 2 machines setup. I prefer not to "mix" frontend and backend loads when possible.

Also, security-wise, it's better to have them split apart, so that a vulnerability in one of them does not mean the other service/server fails directly.

Of course, now you have two servers that you have to:

  • Patch
  • Provide power/cooling for
  • Provide Rack Space for
  • Monitor
  • License the OS/apps that you need in them

Are your services "internet-facing"? If so, then splitting them is almost a must for security reasons, and I'd add a firewall in between.

Also, splitting the app in frontend/backend sooner than later will enable you to grow painlessly; as your load increases you might need more application servers or DB resources, or... so the sooner you make sure your app can be split/spread, the sooner you find any lurking dependencies/issues that might arise later on.

In the long run, it's normally much simpler/cheaper to scale out (ie, add more servers to the same problem, see google ;) than to scale up. Of course, normally DBs are harder to split so if you're lucky and become extremely successful, the DB might become the bottleneck.

Even if for some reason (rack space/power/cooling) you're limited to a single "hardware" server, then I'd recommend to get a powerful one, and to look into virtualization to split the load into 2 logical servers. Yes, I know that adds up in licensing, etc, but if my memory serves, MS lets you run a single Win2008 license in a single "bare metal" server and up to (2?/3?) virtual ones. VMWare also has a free server product (VMWare Server) that you can use.

My 0,002 cents.

I'd love opinions pro/against.

Best Regards

Javier

PS: My background is in security, not so much on Web Apps, so maybe what I'm saying is not the optimal solution, but I know that I'd feel more comfortable not "piling up" functionality on a single server/point of failure.

Improve this answer
3
  • I wouldn't use google as a model of how to scale. They've got a really simple problem to divide into smaller pieces (that was part of their ingenious solution to search -- mapreduce). And google has an infinite budget of money and brainpower to throw at the problem. If you can't afford to refactor the problem, replacing a slower CPU with a faster CPU will always yield better results than throwing 2 CPUs at the same problem.
    – chris
    Commented Aug 30, 2009 at 16:45
  • MS Virtualisation only allows multiple virtual hosts on Enterprise and Data centre editions. Unless you get a very beefy machine, data centre isn't a good option.
    – Ryaner
    Commented Aug 30, 2009 at 17:07
  • @Chris: I agree that getting a bigger box is the quicker and simpler way to get better performance in the short term. But my point is that this strategy will only get you so far; if the project has to scale past a certain point, there will be a need to split functionality... and maybe it's better to face those pains now than later.
    – JJarava
    Commented Aug 30, 2009 at 19:40
1

Xeon:

Intel® Xeon® Processor X3353 (12M Cache, 2.66 GHz, 1333 MHz FSB)

C2:

Intel® Core™2 Quad Processor Q8200 (4M Cache, 2.33 GHz, 1333 MHz FSB)

I would definitely go for Xeon and i would change to 64bit ASAP.

http://ark.intel.com/Compare.aspx?ids=35278,36547,

Improve this answer
1

With a 2 box solution you can spec each box according to the requirements of what's running on that box, and also isolate each component from the other. Be aware though that the connection between the two boxes could become a bottleneck, and that the setup may be more fiddly - with everything running on one box it's always going to be easier to configure e.g. your site to talk to your database; going 2 box, and depending how things are written, this could require a non-trivial architecture overhaul.

Are you in a position to do a test 2 box migration before you need to do it for real, and have you got the time available to iron out any bugs or other issues that may arise? If not, I would say stick with one box. Otherwise 2 boxes would put you in a better position long term. This for me is the crucial deciding factor.

Improve this answer
0

If the costs are actually the same (Windows needs licences) then splitting them is a good option. The web frontend is likely to require less memory than the SQL server and can use different specs. You can also better tune the OS for the different types of data they are serving.

Again though, the initial cost tends only to be a smaller part of the cost over the lifetime of the machine.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .