Slashdot Mirror
Can .NET Really Scale?
swordfish asks: "Does anyone have first hand experience with scaling .NET to support 100+ concurrent requests on a decent 2-4 CPU box with web services? I'm not talking a cluster of 10 dual CPU systems, but a single system. the obvious answer is 'buy more systems', but what if your customer says I only have 20K budgeted for the year. No matter what Slashdot readers say about buying more boxes, try telling that to your client, who can't afford anything more. I'm sure some of you will think, 'what are you smoking?' But the reality of current economics means 50K on a server for small companies is a huge investment. One could argue 5 cheap systems for 3K each could support that kind of load, but I haven't seen it, so inquiring minds want to know!"
"Ok, I've heard from different people as to whether or not .NET scales well and I've been working with it for the last 7 months. So far from what I can tell it's very tough to scale for a couple of different reasons.
- currently there isn't a mature messaging server and MSMQ is not appropriate for high load messaging platform.
- SOAP is too damn heavy weight to scale well beyond 60 concurrent requests for a single CPU 3ghz system.
- SQL Server doesn't support C# triggers or a way to embed C# applications within the database
- The through put of SQL Server is still around 200 concurrent requests for a single or dual CPU box. I've read the posts about Transaction Processing Council, but get real, who can afford to spend 6 million on a 64 CPU box?
- the clients we target are small-ish, so they can't spend more than 30-50K on a server. so where does that leave you in terms of scalability
- I've been been running benchmarks with dynamic code that does quite a bit of reflection and the performance doesn't impress me.
- I've also compared the performance of a static ASP/HTML page to webservice page and the throughput goes from 150-200 to about 10-20 on a 2.4-2.6Ghz system
- to get good through put with SQL Server you have to use async calls, but what if you have to do sync calls? From what I've seen the performance isn't great (it's ok) and I don't like the idea of setting up partitions. Sure, you can put mirrored raid on all the DB servers, but that doesn't help me if a partition goes down and the data is no longer available.
- I asked a MS SQL Server DBA about real-time replication across multiple servers and his remark was "it doesn't work, don't use it."
I hate to say it, I've been too long out of the MS development world. That kind of overhead managed to amaze me.
I'm deploying systems right now (some buzzword compliant, some (more efficient ones) on lowly little open source, that scale to an order of magnitude higher transaction volume at a fraction of the cost. No, none of them are windows.
No wonder my company has been doing well in a downturn. (Oh, sorry, we're "recovering" now.)
I forget what 8 was for.
I got to tell you its probably not java more the actual application server and/or the application. We use ATG Dynamo, and for that we get what we pay for: More than 4000 concurrent users ( active sessions ) per Dynamo instance with out any problems). Although with Version 6, they've decided to go all J2EE Buzzword compliant and complicated the entire setup.
What?! You've never heard of any of the following: -- Terminal Services -- VNC for Windows -- Remote Desktop commercial programs
Yes I use them all the time, but when I'm on the road I have to manage servers over my CELL PHONE coneection. Window Termmial Services is unsuable in that situation.
Here's an example:
With UNIX I'm in Ireland (I'm usually based in the US) and I get a call "We just got a new user, could you add them"
I whip out my Ericcson 68i and Sharp Zaurus - and ssh into the server and run a script to add the user.
With Windows: I have to find a "Internet Cafe" pay 10 Euros, and convince the owner of the cafe to let me install VNC. Then I get to S-L-O-W-L-Y use the gui to add the user.
It get's even better - I can remotly manage my servers in the absolute wilderness with an Iridium satelite phone and a Zaurus with a serial cable. At 9600 baud, I can do it with UNIX - but Windows, forget about it.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
In other words, if you define a target performance metric and find that a single user can access the system at better or equal that speed, then a system can be said to "scale" if it still performs within that metric, on average, when 20, or 50, or 100, or whatever users are accessing the system.
Of course, due to the nature of computing systems, any system will hit a point where it will no longer scale to the requirements with the same hardware configuration. At that point we start talking about scaling upwards through hardware upgrades. But you can only upgrade hardware so far, at which point, again, the system will reach a hard limit on its ability to perform as required.
The next logical step is to scale through redundancy: If a system can, in whole or (more commonly, as in "multi-tier" web clusters) in part, run concurrently in multiple instances, then you can scale by adding more instances of the system or system components: Multiple web servers, multiple "back ends", multiple database servers, and similar. This kind of organic scaling can be, in practical terms, near-infinite if a system is designed well; for example, multiple mirrored web servers serving static pages will scale indefinitely, whereas a trading system requiring inter-process synchronization through a message-queue system will most likely not.
In scalability terms, efficient redundant clusters is the holy grail. It's the way Google scales, and it's how the core parts of the Internet scales.
In the context of this Slashdot story, since the poster faces limited possibilities for investing in expensive hardware, he might consider going for the "many cheap boxes" route, if his Microsoft-dominated infrastructure permits it.