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.
First, you didn't really specify anything except in generalities, but there's a few things that pop out from my experiences:
1. Why are you wed to C#, especially in regards to triggers? How many tiers exist, and are you pumping a lot of data back-and-forth.
2. Your scaling numbers are low already, especially under ASP and static HTML.
3. You never really define concurrent requests. For some people, it means simultaneous requests, and for others, it means simultaneous transactions. But you really are looking at fairly low numbers there, in either case.
4. Scaling this should involve looking at where you choke. One common choke point that keeps killing people is in open database connections. Are you running a pool? How large? How many connections does a page take? The single most common problem I've seen in scaling is poorly implemented connection pooling, thereby causing a ton of stuff to wait. Check this, check, then check again.
5. Sync versus Async shouldn't really be coming into play yet on the db.
6. When designing for light-weight systems, you want to minimize the tiers, and minimize the data passed back and forth. Just by reading this, I'm worried that you created a very elegant, but impractical, system that isn't suited to the hardware limitations.
This entire story is lacking units.. I am so confused, it is like this...
"I bought a 400 car from my dealer, who said it could go 0-1200 in 57, but I talked to an auto mechanic and he said that the rpm throttled at 4.5 billion, so I don't know if I should get a turbo charger which would at least boost the speed to 1295!!"
If you are talking about 100 concurrent request per second: Any DB worth its salt should handle that IFF the database queries aren't too complex. If they are, your schemas suck. This is doubly true on a 3 GHz machine.
2. SOAP is too damn heavy weight to scale well beyond 60 concurrent requests for a single CPU 3ghz system.
.NET specifically, but just SOAP in general. Make sure you separate out the platform from the product. Saying web services with SOAP won't work is a long way away from saying .NET doesn't scale.
.NET languages, but that's rarely going to be a way to make your system run faster and scale more. Plus, I'm confused - what's your alternative? What database are you going to recommend that allows you to embed C# (C++, whatever) programs in the database itself?
.NET question, it's an SQL question.
.NET, or just a particular product. You might go with .NET and not use MS SQL Server, for that matter.
It doesn't sound like you're talking about
3. SQL Server doesn't support C# triggers or a way to embed C# applications within the database
Embedding applications in the database violates basic scaling principals: you need to separate out into n-tier, right? You don't want the database server doing anything but serving databases. Now, having said that, Yukon (the next version of MS SQL) will indeed let you do certain things in the database with
9. 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."
Sounds like it's time to get a more informed consultant who can demonstrate failure or success beyond a throwaway line. I'm not saying replication does or doesn't work, but you can't base your enterprise plans on a single line from a single guy - let alone strangers like me on Slashdot. Furthermore, this isn't a
It's easy to make big decisions if you break them up into a series of smaller ones. Look at each of your questions and decide if it pertains to
What's your damage, Heather?
People in SMALL business do not want a system which requires them to hire someone to constantly keep tabs on it.
What?#$#@ I don't care who this "SMALL" business may be, but if you put a server on the internet, and plan on not having someone to "keep tabs on it", please, get off of the f-ing internet. It's that type of mentality that yields the servers out there that STILL are spreading Code Red and Nimbda, because nobody has kept tabs on these infected servers in years.
Hello, .NET Portal Application for the past few months. I ran a quick Test on our application just to see how it would run.
.NET platform can handle about 100 Requests per second before it starts to get hot.
I have been Developing a
Specs Are as Follows:
App Server:
Duron 800
512 MB RAM
40GB HD 7200RPM
DB Server:
Celeron 500
640 MB RAM
20GB HD 7200RPM
As you can see, these are not server class machines, but they seem to run the app alright. I ran a simulation of this application based on the IBS Portal www.asp.net running 150 Concurrent Requests Per Second:
The average Requests per second on this app were 98.51. So, IMHO on low quaility hardware, the
You're bound to get lots of responses of how to scale the system up. I'll focus on scaling the requirements down.
Unless the transactions are really long, "100+ concurrent requests" as a sustained rate is a lot of activity for a small business. So, that begs questions:
-- What percentage of these Web service requests are read-only "query" style, and can you use application-aware caching to return results out of RAM instead of having to hit disk for each one?
-- What is the client to this application, and can there be ways to help induce a smoother load from them (e.g., discount rates if the application is used in off hours or on weekends)? Or is the 100+ concurrent requests going on 24x7?
-- Do all the requests have to be filled by the server, or can you blend in some P2P concepts so the clients can absorb some of the load?
-- Can you increase the amount of data handled per transaction (perhaps by switching to document-style SOAP or REST instead of RPC-style SOAP) and thereby reduce the number of requests and excessive message parsing and marshalling?
There's probably a bunch other things to do as well, but those came to mind off the top of my head.
The Busy Coder's Guide to Android Development
In other words, it's not what you're using to do it, it's how you're doing it. If you're just pumping out files to clients on modems, 100+ concurrent requests isn't much. If those requests are all CPU-bound, I hope they're all niced or set to a low priority, otherwise you won't be able to log into the machine in a reasonable amount of time. If it's 100+ concurrent connections, but those connections aren't necessarily waiting for a response (just idle until the user does something) then you might not even care.
How many whatevers you have must always be qualified by knowledge of what those whatevers are doing. Otherwise your whatevers won't fit in your $20k thingamajig. And then Mr. Bigglesworth gets upset.
Of course, whether .NET is a properly-implemented system is a separate debate...
Argh, I hate to give up moderation rights but I have to chime in here.
A small business CANNOT afford to employ a full time UNIX administrator. Open source solutions just do not have the ease of administration of the Windows GUIs. Until they do, they will not be small business friendly. Windows Small Business Server provides you with one installer that will basically set you up completely (Exchange Server and all).
Now, before you flame me out for being pro-Microsoft, you should know that almost all my machines at home run Gentoo Linux, and I prefer to use Linux myself.
I had a long discussion with a good friend who is not terribly computer literate. Linux drives him _crazy_ because he can't just, "point, click and go" as he said it. Until these issues are resolved, we won't see small organizations without dedicated IT staff rolling out Linux installs.
Hi!
Executive summary:
Yes.
Boring details: .Net (mostly C#, some components in VB), including Windows forms and ASP.Net web pages. (Why both? The project incorporates multiple applications for different kinds of users.) As part of pre-shipment testing we're in the midst of extensive testing, including load testing.
I'm goofing off, perusing SlashDot at the end of a dinner break. We're shipping a big project to a customer on Monday--the project is written in
The Windows applications communicate with the data tier using SOAP/XML, using synchronous messaging. Practically every message involves a database transaction with SQL Server 2000. Across a range of loads we are seeing round-trip message responses (from receipt of the inbound XML message to return from the web service) averaging less than 90 ms per message. That 90 ms average can be misleading--some of our messages involve extensive processing and/or lots of data. Some of the transaction work we're doing with SVG images involve SOAP messages with payloads greater than 1 MB, so the average gets dragged out.
Based on our testing, we anticipate supporting hundreds of simultaneous users--in a near-real-time environment--from a single web service. As we scale out on larger projects we may need to scale the number of web servers (although IIS on Windows 2003 is supposed to be substantially faster--YMMV), but we won't need to scale the database. Using a similar messaging architecture for a different client I have a project supporting 400+ users on a single SQL Server.
This is SlashDot, after all... .Net. And recommending it. But you asked, so I'll answer: .Net is scaleable in terms of the final application, and .Net is scaleable in terms of the size of the development team that is involved. This project involves 19 developers (a total of 60+ individual projects in the nightly build) and we're able to manage the entire thing remarkably well. Developing web service applications with .Net is remarkably easy to do; developing sockets apps is unbelievably simpler than using WinInet.dll. And the web developers are extremely happy working in ASP.Net--I don't know where you heard that ASP.Net is slower than ASP, but that's simply not true. ASP.Net is significantly faster.
Obviously you're going to get a lot of "why not use...?" posts, and I'm sure I'll get flamed for having the temerity to admit to using
With regard to other comments .Net Remoting. Quick to prototype, barks in production. Like OLE, it's a great way to make a Pentium 4 box emulate an original 8086 IBM PC. (Far smarter to manage communication with XML-based messaging. It just takes more coding.)
I'm the data/messaging architect on the project: I can speak to the comments about messaging, reflection, and SQL Server. As with any Microsoft-based development project, you have to think carefully, and think critically, about how to design your application. Microsoft will always give you a quick! easy! fun! way to rapidly produce a prototype. You have to dig deeper, and think harder, to produce a scaleable application. The quick! easy! fun! technology du jour is
That SQL Server doesn't permit triggers to be written in C#--so? Transact-SQL is suitable for database development. We could ask for more (such as integrating stored procedures and other database code into Visual SourceSafe). There is talk that the next version of SQL Server will permit coding in .Net languages--that'd be cool, but I'll wait and see.
The single most compelling argument for .Net .Net Framework. You might look into this particularly for clients that are choking on server pricing--but you might also pay careful attention, because a robust Mono project will encourage/force Microsoft to compete on features and functionality, instead of a take-what-we-give-you mentality. That's a Very Good Thing.
Mono--an Open Source implementation of the
A common misconception is that anybody can administer an MS server, but the truth is that it's not a whole lot easier to do than administer a Unix box. What's scary is that it looks easier and most IT managers think it's easier. That's why most Windows admins are grossly incompetent, especially when it comes to security.
A good Windows admin costs the same as a good Unix admin.
The global economy is a great thing until you feel it locally.
I had a long discussion with a good friend who is not terribly computer literate. Linux drives him _crazy_ because he can't just, "point, click and go" as he said it.
Windows systems need an administrator every bit as clueful as a UNIX sysadmin if they are to have any reliability at all. If the Windows 'sysadmin' has to be able to point-click-go to be able to function, in all probability the Windows system will be unreliable and insecure.
It is a false economy to think that "It's Windows. I can hire a junior reboot monkey to admin the system" - a Windows system really does require a sysadmin every bit as competent, skilled and clueful as a Unix system. A Windows system can be very reliable with a clueful admin - but it *needs* a clueful admin. Companies are shooting themselves in the foot if they think otherwise.
Oolite: Elite-like game. For Mac, Linux and Windows
telling those companies they don't just have to buy
TANSTAAFL.
No matter what you'll have to layout cash to buy the three essential ingredients:
Microsoft marketing would have you believe that their software solves all your problems and that lots of cheaply available people can do the job. They'll still charge you for their software and you'll find out that hardware still costs something and that getting good people to support and maintain your software and hardware is more expensive, but worth it.
Linux advocates will tell you that the software costs zero and that any competent sysadmin can do the job. You'll find out you still have to buy reasonable hardware. And you'll find out that getting good poeple to maintain and support your hw and sw costs more, but is worth it.
Any way you go you're gonna pay.
"Provided by the management for your protection."
It's a damn simple question: can .NET really scale?
.NET will provide a relatively non-diminishing gain in performance as more capacity is added, which would be scaling.
That really isn't the question being asked at all.
This person doesn't want to know if
They actually want to know if it will handle a large number of concurrent connections to services on small hardware.
The real question is:
Will it handle a lot of clients at once on very little hardware?
The answer is: No.
If you don't have enough capital to invest in the infrastructure you need, you have to either find something that will do what you want with less, or give up on the whole idea.
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.
Install an SSH server on Windows and you'll have much of the same functionality as UNIX through the command line.
" 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."
Did you even bother to check out whether this was possible in Windows? I guess not: this site shows you how to add a user from the command line in Windows. In fact, you could even write a script to do that (batch files... remember those?) In fact, here are lots of handy other things you can do from the command line in Windows, including changing user passwords, forcing users to log off, and more.
Once again, ignorance of what Windows can do is no excuse. I administer 16 Linux boxes... I'm not anti-Linux by any stretch of the imagination, and I know that there are lots of situations where Linux is the better choice. But that still doesn't mean I'm ignorant about what Windows can and can't do.
Simpli - Your source for San Jose dedicated servers and colocation!
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.