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."
If they're that strapped for cash they should be looking at open source.
Is this truly the only Earth I can live on?
the obvious answer is 'buy more systems', but what if your customer says I only have 20K budgeted for the year.
If your client has budgeted 20,000 systems this year, I'm sure they can spare a couple of them for your project.
Sorry...
Sailing over the event horizon
Everything windows will cost you. The setup you are looking at will be about $1200/box for the software alone. Look into an open source solution. Also, wherever you can, make a beowulf cluster. It doesn't have to be the most efficient solution, it just has to be beowulf.
Canadian Cynic, canadian politics is less boring than you
I don't understand how one $20k server could be faster than $20k worth of normal desktop computers? Why not just sell the server and buy $15k or whatever you get back worth of desktops?
... but Unix/Java programmers aren't. Wanting to write the code for free, too?
Apache, FreeBSD and a cluster of 10 or so $1k servers and a nice DB server running PostgreSQL.
Works for me.
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.
tell them "php+mysql"
Everything has its time and place. This is not news this more of a programming question.
.Net really scale" now if that was backed up by articles of so and so, benchmarks of such and such, that would be cool.
"Can
Lets keep programing questions in programing forums, so when i have programing question i know where to go, because looking for answer for (agh) programming questions on news sites just does not sound right.
While spend all that ony on an OS, when you could double your hardware with the money you save but not buying windows?
Hell, you can build a P3/P4 1U rack box for ~$800, probably cheaper now a days. Ditch windows and buy a 1U six pack.
Get rid of the MS expense and poor performance:
Linux
Apache
MySQL
PHP/Perl/Python
That is a solution.
It's a damn simple question: can .NET really scale?
.NET, I advise you to keep your mouth shut. The signal/noise ratio is bad enough already.
Why on earth did you bring open source into it? If the man wanted to know about Linux & BSD, he would've asked.
If you don't have any experience with the scalability of
...why companies insist on using products that are not robust nor Enterprise ready and continue to buy in to the marketing B.S. of those who are marketing the crap and making many bucks off the sale of it.
Yes, I know that if a client wants it, then you either provide it or find other clients, but my question not only applies to solution providers, but solution requesters as well.
PGA
.NET scales so well that Microsoft has quietly dropped it's name from their upcoming product lines.
.NET will succeed...
Not even Microsoft thinks that
100 concurrent users isn't a lot.
What is the web app going to do? All the hardware in the world, and even open source won't help you much if you're trying to do the wrong things on a single machine. Database driven site? Commerce? HEavy read, heavy write, or both?
"Anyone who claims that any Microsoft software is good will quickly be modded to Score:-1."
And anyone who spouts that kind of stereotypical "slashbot" anti-Microsoft bullshit will get modded up Insightful.
And then I'll get slapped with Offtopics and Flamebaits for daring to disagree with the anti-anti-Microsoft zealots. Go ahead and mod me down, it'll just prove my point.
Note to M1-ers: a curt but otherwise insightful message is not "Flamebait" or "Troll".
My first inclination is to recommend throwing that $20k at an ASP that can provide the server infrastructure to give you support for 100 concurrent connections.
Barring that, my recommendation would be to split the web front end and database, spending about $10k on each (using dell or hpq). I can almost gaurantee that you aren't going to get 100 concurrent connections for less that $80k to $100k without doing some sort of load distribution. If you strip down the amount of dynamic content and say script a refresh of a static page, you might be able to do it, but we don't really know what the app is going to be doing.
Jerry
I don't really know an answer but I will throw in my tidbit.
But first let me apologize for all the nutheads who say "drop MS - use Linux" and all the derivitives thereof. That doesn't help anyone, and doesn't answer the question. Might as well say "use a dustmop, works great on my floors!".
My advice would be to *try* and use a cluster of some sort instead of the one server approach. Sure, you can get some great big reliable iron - that is wicked fast... But what I have found is that scaling really needs more *bandwidth*. Not network bandwidth but memory, disk, I/O, that sort of bandwidth. Of course, the more machines - the more licenses... Good luck!
We can't even define .Net so how can we say if it scales or not? What does this even mean?
What language/libraries do you use to develop applications? What kind of performance is typical for you?
"Communism is like having one [local] phone company " - Lenny Bruce
No frosty piss here. Move along! Nothing to see, here!
I can see it now- after commanding the drones to switch to Windows 2.003k, they look at the price tag- the jump in overtime, the additional hardware for that "faster" version, the new software licenses...
President:"But...but...that commercial said it would be cheaper, and it had lots of pretty people doing neat things, with nice music in the background! And the nice representative at the golf tournament said I'd get to have employees walking around with little handheld things that showed our inventory! And..."
CFO:"...You mean to tell me you bitched and moaned for months about how we needed to switch, and you based the decision on TV COMMERCIALS?"
President:"DUUUUH, of course not! I SAID, I talked to a MS rep too!"
(sound of 12 hands slapping 12 foreheads)
Please help metamoderate.
there are plenty of open source or even java based solutions that you would not have to ask this question 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 is always the most generic performance question. Chances are it can scale. It's like people saying can j2ee scale? Of course it can...here's the key...in the right situation. The other consideration is if the code sucks booty, then it's never gonna scale either. So saying 100+ concurrent requests is vague. You answered your own question with the asp performance benchmark. It can get there assuming what you're doing in the code and architecture is tight and well-written. If you're doing transaction intense, IO intense, synchronous calls, then chances are you won't hit the highest benchmarks out there.
Any time someone asks me that question, one of my first response to the "is such and such scalable" is to read this article: Building a Large-scale E-commerce Site with Apache and mod_perl
Some of the number in there are damn impressive, compred to most Windows setups I've seen.
I suppose you're PHB saw a full page Ad in 'Time' by M$...
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.
Why don't you just ask MS this question... what? huh? You can't? It's too expensive? They lie? They don't know?
.NET.
Then why are you using
-pyrrho
Using a dual Athlon box with 1G RAM, and a combination of MySQL and an OSS XML-RPC library from Sourceforge we've managed over 1000 concurrent requests without a problem, like the song says, don't beleive the hype, has everyone forgotten how to craft fast, elegant, cheap, well documented solutions, or have I slipped into a parrallel universe where slashdot has been replaced by slashdolt?
Any sufficiently advanced man is indistinguishable from God
The sad truth is that .Net is very young and will have serious issues scalling on the application side.
.NET application.
Java and JSP had this problem early on and still are not overly fast performers.
I would recommend that you spend $10k on a database server. Then get 5 $2k machines, run two as web servers and 3 as aplication servers running your
Besides that nothing more then tweaking the code and OS is going to get you to 200 connections.
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?
It seems to me from reading not only this thread but many similar articles about performance that the related costs have little to do with the software platform and everything to do with hardware expense and the technical expertise to manage the software. Perhaps the end client could benefit from an open source solution and save enough to afford a second or third production class server but this question is not coming from the end client it is coming from a solution provider for the end client. Judging from the question the solution provider's technical expertise is with Microsoft software. I don't have the answer he is looking for but I will offer this suggestion: Maybe you should look in to expanding your services by acquiring some new skills or adding to you team with alternatives to Microsoft.
I work on a university campus where we are "officially" a Microsoft shop but we are making huge strides in integrating Mac and Linux solutions into our MS infrastructure. By making these additions an integration to our infrastructure and not alternatives to it we are creating an extremely robust and useful computing environment for our end users, the staff faculty and students.
"Waitress I need two more boat-drinks..."
I don't have any experience rolling out .NET applications of any size worth mentioning, but I have installed a few Java ones, and let me tell you: what a dog! Users are complaining about the performance, and I'm talking about 5 concurrent users. Not to mention the crap that has to go on the machines in the first place (Oracle IAS or IBM WebSphere) or the time it takes these applications to actually start up. I have yet to understand what the fascination with servlets et al is.
Example configuration is a Windows 2000 box with dual Xeons and 2GB of RAM, running Oracle IAS, connecting to an Oracle db running on Tru64 (Digital Alpha boxes).
SQL Server doesn't support C# triggers or a way to embed C# applications within the database
.net dll and use that in an extended stored procedure.
Actualy, SQL lets you embed actual binary code in the database, using 'extendedstored procedures'. You load up a DLL and the code runs inside MSSQL's memory space. (using a dll) Obviously its risky, but probably pretty fast. You could probably write a
autopr0n is like, down and stuff.
> And then I'll get slapped with Offtopics and Flamebaits
how wise of you to invoke the "reverse psych" mod clause.
But since I've now called you on it, you stand a pretty good chance of getting modded down like you'd deserve to.
Of course, nobody will mod me down. I'm an AC, and that would be a laughable waste of points. right? right?
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
However, I will give this advice: under no circumstances should you be using only one machine. You should have at the very least some level of failover built into your application.
That's what you paid your shitload of licensing fees for, so why not take advantage of their support and ask them?
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
1.) Get more/more effecient hardware.
- A Cluster of some sort.
- Maybe not high end servers but remedial cheap boxes.
2.) Change what you are doing, or what you are doing it on.
- Move to a different perhaps more effecient platform/language/ etc...
3.) Outsource it.
=o)
--jake
Hello Cliff.
.NET Framework (far, far from perfect) and MS SQL Server (far, far from perfect also) offer offer a wide variety of ways to enhance performance (in-memory caching, all depending on what you want to do. It's not the same to offer a single-one-parameter-off-a-single-field-web-servic e for consumption than to offer a plethora of web services sending over pre-processed serialized BLOBS on request.
Maybe you could offer more detail on the data volume, complexity of queries and overall complexity of the solution you're planning to offer. The
Your client *might* be able to pull these off on his 20K budget. It will all depend on what he/she wants to move and how much you need to process it before you do.
Tell us all about it.
HAD
i was interested in this topic. I was hoping to see some real comments from real developers on how they handled such a problem. but it seems the geeks in here really do not know how to solve the solution. You guys have just gone off and rambled on about he should use this.. he should not be using that.... Why can't you guys/girls answer the question with some technical discussions?!? Or is it because some here are really not geeks........ open source your knowledge about such topics... and for those that are helping out i respect.
Good luck developing a massively concurrent and highly dynamic application in any enviroment for 20k. Regardless of whether you go open source or the ms route you are only going to afford couple of nice boxes, a decent raid. If you scale off of these machines you better have a fat pipe and a load balancing scheme as well. All this costs dollars. Please justify the complaints about ms sql server. Granted there are the functional limitations listed, but name a cheaper database solution that is more robust that ms sql 2k. We run some pretty large database where I work- couple of oracle deployments on quad risk 450 machines. Sure oracle is better, but you pay big time for the improvements that oracle offers. My experience so far is that .NET is not dramatically more or less scalable than the open source alternatives. I'll agree there a lot of good reasons to go open source, but lets all be honest and admit that complex highly dynamic j2ee based applications are challenging tune as well.
I'd suggest a thorough code review and some quality time tuning the application. Or just throw more hardware and more dollars at the problem.
"Of course, nobody will mod me down. I'm an AC, and that would be a laughable waste of points. right? right?"
You mean like how your grandparent post didn't get whacked at all with any negative moderations?
Either they're throwing a tremendous amount of resources down the drain by trying to hang a picture with a nailgun, or they're just plain cheap and don't want to commit the money to make the project a success.
Any other takes on the situation?
Dewey, what part of this looks like authorities should be involved?
You don't really describe the kind of apps you will be running to know if your observations matter in the slightest. You say that you get poor performance when your app does a lot of reflection, why is it doing reflection? Is this really a need, or are you just doing it "because you can"? Are you using this app when you further state that your performance drops by a factor of 10 vs static html? Why would you be comparing the two anyway? If you're serving static pages you shouldn't be looking at a webservice anyway, so no real sense comparing the two.
You mentioned db issues, what type of access are you doing with your databases? Are you thinking replication to deal with scaling across a server farm? Is this data being constantly updated by the servers, or is it mainly static? If you have simple primarily read only data, then something like mysql would be a far better choice, you just don't need the overhead of a full blown db server (like sqlserver, or oracle or even postgres).
Really what you need is to identify what your requirements are and tailor the end result to the systems that best meet those requirements. This also includes support and things like backups (e.g. can the db you choose do online backups if that's a requirement, etc).
Of course, caching may not be a viable option for you, depending on your specific situation. I wouldn't know .NET if it hit me in the face, so I don't have a clue as to how it works in the Microsoft world. If you can pull it off, though, you'll get near static-HTML performance for a lot of your hits, saving you the cost of another server or two.
I remember back from an MS SQL class I took (back at SQL 6.5), and one of the things we did in the class was put the database on a drive without a partition. Now I know what you're saying, "shutup, you can't do that". But you can. I don't recall the specific way, but it was well documented at the time. Look under file systems, or the like for details.
Additionally, look at solid state devices for use as swap. I've seen a PCI based RAM Drive, that was essentially a PCI card with dimm slots on it, you load it up with RAM (1gb max i think) and use it as a swap device.
Just some thoughts
think before you write, it'll save me moderator points.
1, Buy *a lot* of memory for the box
.NET is the same but different - they both require a hefty amount of ram to operate at best performance (and atleast java just gets better the more memory that is available on the server ;)
.net remoting implementation instead - you can probably find a few with a quick google search (IIOP comes to mind, good way to make future interfacing with other technologies available just a easy as with webservices/soap and gaining better performance in the bargain).
2, Cache as much as you can of the dynamic content
3, try to stay away from bloated protocols
1: Java,
2: Maybe doesn't help much with scalability, performance will go up though - and maybe you might get good enough scalability too. Database access is always slower than a hashmap lookup (if said hashmap can stay in ram ofcourse)
3: Web-services etc etc are maybe good in theory but at the moment those technologies are a duck in a pond when it comes to scalability and performance. Use a highperformance
Also investigate how much you can make your site use asynchronous notifications, more is better - even if ms messaging client is too bad, you can write your own asynchronous "protocol".
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...
my experience on a single machine was that it doesn't scale well at all. firstly, when you look where the processor cycles really go, you'd be wondering. secondly, the underlying system takes so much memory (and one under load, processor cycles too) that your machine looks much smaller before you even got to process a single request. and finally, on some critical tasks, it is even quite a bit slower than java (even though ms would want you to think otherwise and even though java is really slower in most cases). On memory intensive requests, you'll regret having .net. And the more requests you get, the worse it gets. It clearly was designed for multiple servers doing smaller tasks via webservices, but you lose lots of speed that way because of the way .net serializes and deserializes the data (which is extremely slow, even for smaller structures, but it takes all the programming work that the developer would have to do otherwise). So the point is: The only way .net scales is by scaling up the hardware (mucho). and because of stability issues, you guess yourself that if you distribute large tasks to smaller webservices like ms says you should, you increase the probability that the whole system is down.
"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?"
Well, we scaled way over 200 concurrent requests on dual P3 (around 1Ghz per proc) and 1GB ram with W2k and SQL 2k.
You should really evaluate you schema and what you are trying to do with it. Also look at your memory and I/O usage.
There is no reason you shouldn't be able to scale well over 200 users with SQL 2k on a dual proc box with a decent amount of memory.
-- Jason
Anyway. If you can't support 100 requests a second on 50k of modern hardware, you have huge design issues and other problems. Just from your short description of the project, I fear you have crawled into over-engineered land because alot of the technologies are much more useful on seperate boxes/distributed enviroments.
Good Luck. Remember that C# Web apps can be multi-threaded, and remember to optimize the parts of your application that MATTER. A wise man once said "Premature optimization is the root of all evil". Find the slow parts, fix them, get the most bang for buck. Also, remember to keep those pieces loosely-bound to each other, no C# code in the DB!
--MetaCosm
P.S. I hope you haven't over-engineered this tool as badly as it sounds like you have
All that's there right now (as of yesterday) is a review of my new laptop (Compaq Presario X1000)
/. load, so bombs away.
http://www.sharpmatrix.com
It's an asp.net app/site (.net 1.1 framework) running on a Win 2003 server, the backend db is MySQL 4.0.10.
H/W specs:
1GHZ Athlon
512MB RAM
40GB HDD
This is a new dedicated server at ServerBeach and I'm really curious to see how well this server does under a
Does anything MS makes scale? This is the kind of reverse logic that goes into MS shops. I can't tell you how many times a consultant has come in to our shop and shown off an app that runs on Windows that our management fell for. Then, when we put it into production it falls on it's face because people actually attached to it and tried to use it in more than single digit numbers. Management (not wanting to admit it's mistake) digs the hole deeper by just shouting "Buy more servers!" Not considering the creeping O&M costs as we add more and more servers. Now we have over 200 Windows servers in the server room and we're a utility company!
It's really frustrating if you're a NetWare admin. I had 1200 users on a single processor, 200 MHz 4.11 server a few years ago and it rocked. Scaled through the roof. Then when Windows exploded into the server room (we had to expand it several times) management looks around at all the Windows servers and says, "Hey, we have too many servers. Lets get rid of these NetWare boxes." Arrgh! The Microsoft Cult wins again! Resistance is futile.
- Hail to our fearless misleader! Fool speed ahead!
Two cheap boxes, one running the server and the other SQL server, will outperform a single box by a wide margin. SQL Server's a pig and doesn't share well with the other children. Use back to back NICs to the connect the SQL box so there's no network overhead...
Check the check boxes when you compile your .Net components. Threading models matter. And a stateless contiuously instantiated module is the only scalable solution. Check the stats on construct/destruct overhead.
Use an n-tier architecture. Not just for the obvious reasons but because you can build faster data access including invisible data caching (as the app grows) and avoid the problems that are driving you down to only 20 or so tps.
Buy more memory - Doh!
"Knowing everything doesn't help..."
Scalability and performance usually are a side effect of the design of your application. Even when you don't have the time or money to switch technologies, and you're stuck within certain environmental constraints (such as DB engine, runtime environment, language, OS, etc.), you might still be able to improve the performance of your apps by doing the right changes to your application.
But there is no magic bullet, all I can tell you is that you must profile your applications, and find the 'hot spots', and design around them.
Each app is different, but without metrics, there isn't much you will be able to do.
I don't believe that .NET will impose a huge performance penalty per-se. Mostly it's just a VM plus associated services (analogous to Java, at least at the concept level).
What will probably will have a huge impact on the performance of your app is how you handle persistent data. The database usually becomes a major bottleneck if you are sloppy with your table design and your queries.
Your queries should be as simple as possible, and you should avoid relying on complex features of the database, such as:
- Referential integrity (I know I might scandalize some of you
;)
- Triggers
- Selects on multiple tables
- Views
- Etc...
All this operations place a huge burden on the DB, and usually don't scale well.Multi table queries involve set operations on potentially large indexes (won't scale well).
Referential integrity forces the DB to check the constraints on every modification (it should only be used for debugging purposes), triggers have the same effect.
On the other hand there are many other factors that will help you improve your performance, such as caches, reducing contention in shared data, avoiding data conversions, etc.
But as I said before: It depends...
Sorry for the rant ;^P
"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."
We are running transactional replication on several large databases (6-14 GB) on a Media Metrix top 50 website with no problems. It needs to be set correctly (batch size, timeouts, etc) but it does work quite nicely. The DB machine is heavy hardware, but it it able to keep up with 12-15 front end webservers, all with applications hitting the DB.
I find it funny to watch the war between the "why are you suggesting open source crowd" and the "open source is the only way". I have built IIS/ASP/SQL server solutions and I have built Apache/PHP/PostgreSQL solutions. There is a place and time for both solutions.
.NET so far due to the heavy memory footprint it places on a system. Yes, VB.NET is faster than VBScript, but if you were using compiled COM objects in the first place, .NET costs more memory for a slower system. (I do think that .NET's ability to do in place object updates rocks, but I hope you have a devolpment server for bouncing and PLAN your updates...)
As an aside, I have to say that I have avoided
But more to the point, your customers don't seem to have the budget to succeed in any domain. If you can't afford more than 20K for a machine and licenses, surely you can't afford to pay the programmers an adequate salary either. So does that mean open source? Heck no... you still have to pay the programmers! I don't think I have *ever* seen a project where the programmers were *cheaper* than the hardware.
Sig under construction since 1998.
Google regularly handles way beyond your transaction requirements why not look back in slashdot for the coverage of how google does this?
Some hints:
1. Google builds its own servers...
2. Google then chooses the best OS DB combination..
Don't Tread on OpenSource
Your clients are cash-strapped, but insist on the most expensive solution imaginable? They deserve to go out of business.
This is just like all those stupid people who work at Wal-Mart or some other low-paying job, but are convinced they deserve to live like they're rich, so they max out all their credit cards and end up either bankrupt or forever in debt to Mastercard.
The fact that there's much better solutions that cost far less, and don't depend on MS's latest buzzword technology which may or may not be around in two years, makes these people even more stupid.
I am the network admin at a large .Net website (5+ million unique visitors each month) and we often handle hundreds of tens of simultaneous requests. The entire site runs on 6 webservers and two database servers that run at less than 50% capacity during peak times.
If you can't scale above 100 connections on a 3GHz system then you are doing something wrong. Check your code, check your databases.
Your question is about as useful as "I have a piece of string that is not long enough, what can I use instead that is longer?"
And certainly going with Windows doesn't absolve you of administering the site.
Have you installed Red Hat recently? They provide you with one installer that will basically set you up completely too.
You are exaggerating Linux's downside here.
.NET is just another solution (J.A.S.). A solution in terms of software constists of a paradigm, a bunch of managers yelling acronyms, The Mighty White Paper, success stories and a lot of advertising to make people think that everybody uses the new solution already. In fact, stuff like .NET is like a religion, so if you believe in it, it works.
.NET wins and people go to .NET-churches, yell Microsoft-slogans and spread the Mighty Word of Solution Integration And Results Leveraging .NET-Solution Deployment Broker Technology Enablement Integration, everything will be .NET. People will forget the ancient speed of simple XML-less TCP-communication and full-duplex interprocess communication. Then, .NET is scalable, because all other things are eliminated.... By the way, another alarm-word for religion like bloatware like .NET is the word 'professional'. Large scale solutions are professional, simple solutions (a web site built with PHP, instead of J2EE with Container Managed Persistency) are always called 'unprofessional' or 'stuff for hackers' and that's just because people think everything related to computers is very complex or has to be complex.
.NET will be scalable and it will take over everything. Within 5 years people start their cars by passing an XML-document and telephone calls are encoded and packed in XML-CDATA-tags and sent over the line...just like 100 years aho where telephone was half-duplex. :)
A couple of years ago, people started believing in Web-applications. People started exploiting -tags to place buttons on the right position instead of displaying a table, the -tag was invented and after the addition of the hidden--field, everything changed everything was web-enabled. Nobody seems to remember how fast distributed software was before those bloated web-stuff which are only hacks and trics with the browser.
If
Because of all those stupid Prophets of Solutions and Wizards of Enterprise Integration,
:wq!
Unless you're an ISP, you've got to colocate all that equipment. At nontrivial $$$/rack unit, a bunch of low-density (performance) desktop machines will quickly eat up their performance cost gain in additional hosting fees. Plus you have to consider extra licenses. At $1200/Windows 2003 Standard license and $3500/SQL 2000 CPU license, buying the software for the additional machines substantially boosts their actual cost, unless you're using open source stuff. Of course, this thread isn't about open source, it's about Windows and .NET.
I know... flame me. But ignore taking religious sides for a moment and just look at what their numbers could produce for under $37k. They were able to exceed all of your performance requirements including using dynamically generated SQL.
hth,
Bill
It's my Sig and you can't have it. Mine! All Mine!
I'm not too experienced with the amount of power needed for the different loads of users out there but I imagine that if you're trying to support more users than your systems can handle, and you "can't" afford any more (or stronger) machines then you're simply in the wrong business (assuming the work has been architected decently). It just doesn't make sense to try to make the hardware accomodate your financial budgets plus operational requirements when it sometimes is impossible (or very very very difficult).
"Injustice anywhere is a threat to justice everywhere." - Martin Luther King, Jr.
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
scalable? .NET? This is a troll, right?
-I like my women like I like my tea: green-
The most expensive machine that my workplace has purchased in the last year cost $350. That was because it had a DVD burner. I buy all our monitors at Goodwill Computer Works. I'm typing this on a machine I bought for $19 at Discount Electronics up on Anderson. (Of course most of my X windows are just displayed here from other places.) And of course we run only linux, except for the sys admin who makes a big deal about BSD but will probably be fired because NFS won't stay up ( Hi Robert ! When is it gonna work you fag ? )
You seem to be trying to sell to the wrong market . Go for open source software with low licensing fees , that runs faster . I have personally seen 233 mhz boxes with 128mb ram handle slightly bellow those levels of transactions ; and those boxes are a lot less than 50k or whatever your budget is ($50~75) . Honestly just use linux or bsd . Plus come on this is slashdot you should already know asking for help with a microsoft solution will result in people telling you to use linux or bsd.
It's more like people who don't know what they are talking about have purchased equipment that could do the job, if only they would not insist on ASP and other Microshit. It's more like someone bought a nice deisel pickup truck to haul manure, but isists on using model airplane fuel to make it go. Our hero is asking, "how can I make this alcohol based fluid act like deisel? I know that it would be silly to try to move all that manure with 20,000 model airplanes and my client really does not have that kind of money. Someone tell me it's going to work." It's funny to read astrotufers like this, recomend a fleet of 20,000 model airplanes. It'll be fast!
Friends don't help friends install M$ junk.
if you find MSMQ isn't adequate to handle the high messaging volume, try using MQSeries either in a standalone or cluster environment.
"On the Internet, nobody knows you're a dog!" - a dog
Hey, why don't you ask Microsoft? It is their frigging product.
My beliefs do not require that you agree with them.
1. (Do you mean 100 concurrent "users" or "hits"? There's a big difference! Let's assume you know what you're talking about, as much as we can pretend anyway.) While 100 concurrent users may not be a huge load, it's not exactly a slugish business day either. I would ask this: if your clients are getting 100 concurrent users then they're getting a respectable amount of traffic and I would hope that translates into cash flow... so why the hell can't they afford the $20K?
2. You're very vague. Apparently, this isn't just a Web site if you're also serving SOAP requests. Yes, any XML-based protocol is going to be slower simply because of bandwidth.
3. Although SQL Server doesn't support C# triggers, its stored procedure mechanisms are quite efficient.
4. I think you need to find a new SQL Server DBA if he's (or she's) providing poor performance numbers as you suggest and feeding you crap about real-time replication. I've done r/t repl across multiple servers, across multiple continents, using high bandwidth with no problem.
5. Why would you want to convert an ASP/HTML page to a WebService page? If you convert them to ASP.NET pages instead, you'll see a higher performance. Use WebServices only where they make sense (to satisfy requests from remote software requests - not Internet browsers with humans behind them.)
6. Why are you using "quite a bit of reflection"? If you don't know what your code looks like, maybe you should open up an editor some time.
Just use Linux, close your eyes and pretend its
This is Windows on Intel boxes. You don't run one big server. Get a bunch of $800 servers and a loadbalancer. I'm not sure how much we paid for our Radware loadbalancer, but our Netscreen firewall was $10K. Lots of servers scale well, and it's expandable in the future. If you need a clustered (i.e. failover capable) DB server, expect to spend minimum $15K for a couple of cluster capable Dell PowerEdges. More for Win2K AS and SQL Server 2K Enterprise ed. There's a HOWTO somewhere for Linux cluster (High Availability Linux) if you want to use MySQL or something free on the backend (why when you're running .Net?)... how much is your time worth?
You must have redundant servers. As they're Windows boxes, expect regular scheduled downtime. You will need to patch (and reboot) frequently. As they're Intel boxes, don't expect much in the way of hardware redundancy and hot swappability for a low price.
...but my FreeBSD/Apache/mod_perl/PgSQL boxen are currently serving 189 Req/Sec off a realtime data driven application.
.NET can do that. on the same hardware? dunno. For the same cost? Definitely not.
Hardware: $10,000 USD (4x Dell servers)
Software: $0 USD
Bandwidth: $6,000/mo USD
Uptime >99.99%
64% CPU use on the single most loaded box
Sure,
~a
"If one of the servers has a problem - I can remotly fix it over my cell phone connection, and I don't have to charge them travel time. If it was Windows - I'd have to drive there."
What?! You've never heard of any of the following:
-- Terminal Services
-- VNC for Windows
-- Remote Desktop commercial programs
I am sorry, but that is just on crack (and so is whoever modded you "Insightful".) In fact, with Terminal Services and the rdesktop client program, you can even administer a Windows desktop or server from a Linux or Mac box. Yes, you can do remote reboots, remote software patches, remote software upgrades, and pretty much everything else.
There are lots of valid reasons for using Linux/BSD/UNIX, but being ignorant about Windows certainly doesn't help your case.
Simpli - Your source for San Jose dedicated servers and colocation!
Look at how MS does business: Get the mindshare. The adage "Nobody ever got fired for buying Microsoft" is a reality. People are going to watch the commercials, drink the Koolaid, and belly up to the bar and buy it. And it's going to suck. Of course it will sick, it's a 1.0 release. But after pouring vast quantities of cash into Project X, based largely on past successes and current license-lockins, nobody can make the call to yank the plug. It's tantamount to saying "All along, it was bad". Look at Legato - this product hasn't worked properly in Enterprise environments... ever, but people still buy it. Nobody can afford the intra-company political suicide it would be to say "this MS product sucks, we bought it - hook, line and sinker, and it was a waste".
Meanwhile, the extensive field testing will give MS a chance to bob, weave, re-engineer the product, so that it sucks less in version 2. (Windows for Workgroups 3.11 anyone?).
I want to delete my account but Slashdot doesn't allow it.
... this can help
With regard to your list of shortcomings: 1. incorrect, I've used MSMQ in a situation where thousands of messages were processed every minute. You have to use non-transactional queues and make the messages non-recoverable, which keeps them from hitting disk. But with these settings I never had a problem with messages being lost, etc. 2. If SOAP is too heavy weight, then fine, use your own custom messaging format. And personally, I doubt it's SOAP that is causing the problem but rather it's what you're doing once the message is received. 3. SQL Server does not support C# for triggers now, but Yukon will. It will be nice when it does (SQL is not a general purpose language and writing complex SPs is a pain), but you need to provide more info regarding why this is a problem for you. 4. You state that you need to support 100+ users (how many does the + add?), so 200 concurrent database requests should work for you, right? 5. 30-50k leaves you with a lot of powerful iron! Check out Dell and I think you'll have no problems. Of course, Advanced Server for load balancing is not cheap...perhaps another appliance? 6. Uh, generating a lot of dynamic code or using a great deal of reflection is not the way you write high performance applications. It doesn't suprise me that you're finding this to be the case. Wrong tool for the job. 7. You can't compare an HTML page and a web service. They're apples and oranges. And let me tell you, using an ASP as an endpoint to process a post request will in no way out perform a web service. 8. Bullshit. Either your schema is the problem or you're writing bad queries. Sorry. 9. Uh, gee, yes real-time replication is expensive esp. when you have a lot of writes. That's just the way it is. Perhaps you can refactor in some way. I think we need more information on the type of app your developing before we can offer you a solution, but I don't buy into your bulleted list.
You're going to get flamed/modded down for this and I just wanted to commend you for doing something to try and keep the discussion on topic.
"Anyone that has ever gotten an idea based on any of my work and done something better with it-good for you."--J.Carmack
You'll find that those ITs haven't been there from VAX times. Why? Because DEC had clustering technology working back in, well, the day of the VAX. Throw three 8800s, a couple of HSC-50s and associated racks of disks, and a star coupler together...instant VAXcluster. It's those young whippersnappers that only know Intel boxes who need to be introduced to clustering.
And yes, I'm scared that I remember all that.
...edit your preferences and remove the "Ask Slashdot" articles from your homepage!
Or they can just go away.
I am working on a .Net/SQL based web application that is supposed to support hundreds of thousands of users and hundreds of requests per second while delivering dynamic, personalized content (sort of like Slashdot does). And btw, it does use reflection, you just have to be smart about it. It requires some careful design but is definitely doable. .Net as with SOAP and SQL. Also, he does not specify what the exact bottlenecks are, does he run out of memory? Disk I/O? Hits some built in limit in SQL or anywhere else? ;)
However, the poster's problems don't seem to be so much with
But of course, if he identified what the particular problem was then he could perhaps just fix it easily and couldn't post it on Slashdot
When men used to be men
my penis!! ^_^_^
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."
Not to mention that's about the least detailed and unprofessional analysis that I've heard this week, but also his characterization isn't accurate. Transactional replication (that's the actual term... if you/he have expert knowledge of the platform you know that) works quite well. In my environment we use it in a number of applications, and though it's not as robust as, say, Oracle, it still does the job more than satisfactorily. I'd say a good first step in scaling your apps is to find a new DBA.
Are you by any chance a MCSE certified engineer ?
Don't you know it is now both immoral and criminal to think beyond the next quarterly report?
currently there isn't a mature messaging server and MSMQ is not appropriate for high load messaging platform.
.NET (.NET as in the CLR, and the framework). My only real suggestion would be to hire a sharp developer who has experience doing nasty things to SQL server if you are going to stick with it.
Can't help you there.
SOAP is too damn heavy weight to scale well beyond 60 concurrent requests for a single CPU 3ghz system.
Is it SOAP itself that's too heavy weight or Microsofts implementation? First thing I would suggest doing is doing some benchmarks between different implementations. You may find out that SOAP is the wrong way to go and decide to go with a different technology. Also, do you need the openness of SOAP or could you do with remoting which will net you immediate performance gains?
SQL Server doesn't support C# triggers or a way to embed C# applications within the database
I can see how this would be a handy feature. You are right, though, it does not exist. Not sure how this is an issue of scalabilty, though.
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?
Well, you always have the option of using a different database. There are managed providers for Oracle if you decide to go that route.
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 think this is the same question as the previous. "It's not scaling well enough on my hardware and I can't afford something more expensive".
I've been been running benchmarks with dynamic code that does quite a bit of reflection and the performance doesn't impress me.
Don't do that, then. Before Java and C# programmers did just fine without 'reflection'. If its performance is not what you need code an alternative.
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
What's a static ASP/HTML page? ASP by it's very nature is not a static page. The ASP.NET page you are comparing it to is compiled and if they are doing the same work then ASP.NET will generally outperform it's older brother. Do you have a small testcase you could post which illustrates these benchmarks?
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.
Again, look for an alternative DB if you can't wring the performace out of SQL server that you need. Or rethink your implementation.
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."
Different database?
It was a good try, but I don't think you really gave anyone enough information to solve your problems. Most of them seem to be related to SQL server, so I'm not sure why the blame is getting placed on
At home, I've one Linux box and one Windows box. Here are my experiences with a USB scanner:
Windows: NICE install. Stick in CD, wait a little while, and we're ready to go with a beautiful GUI. BUT, after a few days, I start noticing the problems. There seems to be no way to save my preferred settings; so everytime I start the scanning program, I have to reset the options by hand. And every now and then when I'm doing something completely unrelated, the scanner starts scanning on its own! In addition, if I try to do anything else while it's scanning, (good old Windows multitasking), the scan fails, and I usually have to reboot.
Linux: Not so easy. I had to learn about USB, recompile my kernel, install and setup the 'hotplug' scripts, and do a fair amount of reading. But now it works great. Of course, SANE remembers my settings, plus it provides a lot more features than the (admittedly prettier) software that ran on Windows. One time when a scan seemed to hang, I just killed xsane and restarted it.
So... if I were a business, I'd probably have to hire someone to set up the scanner in Linux. Assuming that person has done it before, it's probably about an hour's work. With Windows, I could do it myself, but would then spend the rest of the scanner's life tearing out what little hair I have left.
Want to know what .net can do on what hardware, check out this famous report for about the most complete publically available benchmark results for .net.
.net (which you obviously don't know how to do, but someone else may benefit from) check out Microsoft's Pet Shop samples
.net for building highly scalable web sites blow away the competition (and I've used almost all of them). Want output caching, data caching, session management, page view state or whatever other cool tricks for building high performance applications? Well, they are all there and easily accessible. Is it perfect? Not yet, and with any language, any platform, any hardware - a poor design/implementation will result in poor performance... but .net makes it possible to create a high performance application with ease if you know what you're doing.
Want to know how to build a scalable system in
As far as my personal experience, the tools available in
I've done the LAMP thing too, so I'm not just a Microsoft sucker. I use the best tool for the job..
-Woo
You have only complained about a perceived problem so far, you need to isolate and identify your bottleneck(s). The best way to do this is through performance metrics:
Identify your problem with...
If your problem is that SOAP is too fat...
Use XML-RPC it is what SOAP used to be BEFORE it got FAT.
If your problem is Web Application...
Web Services are supposed to be STATELESS. If you are using any sort of state mechanism, it is going to make an impact on your performance. Be sure to turn off user sessions if you don't need them.
Is IIS configured properly? There are scaling settings in there to modify, this changes IIS's caching behavior (look under the "Performance" tab)
Have you set the Application Protection (under "Home Directory" tab), you can execute your site within the IIS process (Low Protection - high speed but if your app crashes it takes down IIS -- never seen this happen personally), within a thread pool (Medium Protection - crash won't affect IIS, but all your sites may have limited availability), or within its own process (High Protection - slowest, but if it fails, IIS and every other site keeps on operating)
Have you turned off logging if you don't need it?
Optimize the IIS Metabase, adjust settings you can't get to through the UI. Never heard of it? Learn about it. In Win2k and NT, it is similar to the registry (you need a special tool), in Win2003, they made it an XML document for easy editing.
If your problem is Database...
Optimize your database access in your code
Use Stored Procedures wherever possible - this keeps the database from having to parse your query, develop a new execution plan, then get your data. Stored Procedures use a cached execution plan, and the only thing to parse are your arguments -- faster, and more secure (no SQL Injection
Trim back your real-time synchronous processing tasks if possible. if you are doing complex inserts into multiple tables, devise a scheme to insert your data into only 1 or 2 processing tables, then schedule a service to go in every X minutes/hours/days to then take the data from the processing tables and do the fancy processing to it and insert it into the "real" tables. Especially good to schedule during off-peak hours if they exist.
Partition your data with multiple SQL Servers this is also known as "Shared-Nothing Clustering"
I wrote the software than runs on a cluster of ten low-end servers (800 Mhz 128 megs ram) and one database (dual 700 Mhz). This site hosts more than 1100 concurrent users and the database does over 300 transactions a second. The site brings in $600,000 in revenue a day. The cluster IP has not missed a single connection attempt in more than six months (we only started polling it then and we poll every minute). The only limitation we have is that our backend is a very poorly written fox pro system. The servers are barely taxed by our application and serve up 60 million+ hits a month.
.NET scales very well.
Placing a well written applicaiton on a cluster of low-end servers yielded great results for us. The key is well written.
Looks like people using .NET / IIS / SQL Server will just have to deal with it not being particularly fast.
.NET platform? Hmmmmmmm. You're in a bit of a bind, then...
The poster will probably claim they can't recommend open-source solutions because they will loose business. In response, I say: you have the wrong customers. If, for example, I set myself up as a Hyundai dealer, I have to accept that the Hyundais I sell are not going to be very fast, or very reliable, or very high quality. Sure customers may come back and say "Why doesn't this car perform more like my friend's Honda?". The answer obviously is that they bought cheap shit and now have to deal with it. Maybe if I tell customers this will go elsewhere. Too bad. I chose to sell Hyundais. I knew what I was getting into.
Solution: stop selling shit. SQL Server for high performance? Right. IIS for people spending 30k? Is that really wise? You *DO* know about the security issues, no? Developing for an unproven, shape-shifting
Here, let me make some suggestions:
.net issue?
.net, you know.
:)
.NET, a book about web applications in general, and a large spoonful of openmindedness would do more for you than any amount of FUD. I hate to write posts with a critical tone, but seriously, Slashdot editors have to start actually reading and evaluating articles again.
currently there isn't a mature messaging server and MSMQ is not appropriate for high load messaging platform.
Better use MQseries or some other messaging server. How is this a
SOAP is too damn heavy weight to scale well beyond 60 concurrent requests for a single CPU 3ghz system.
Well, don't use soap if you don't like it. That doesn't just go for
SQL Server doesn't support C# triggers or a way to embed C# applications within the database
Better use regular triggers etc. then, no?
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?
It seems comparable to sybase and postgresql to me.
I've been been running benchmarks with dynamic code that does quite a bit of reflection and the performance doesn't impress me.
No, reflection isn't good in performance critical areas -- I thought everyone already knew that from Java.
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
This remark seems to be garbled. A *static* ASP page? A 'webservice page'? In any case, if one's faster then I suggest you use that one if possible
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."
My company is using it a fair bit without any problems, but it's not me personally doing it.
Anyway, I think a book about
Whence? Hence. Whither? Thither.
Unlimited growth == Cancer.
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!
inquiring minds want to know what fucking business .net
you have touching a computer with your dumb ass
using
fuck off
and, as always
choke on your own vomit
While you're wondering about .Net, you should instead take some time to understand architecture, design, and the technologies you're looking at. Don't even worry about the platform just yet :P
.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."
.Net limitation, but again, how HEAVY your data is factors in a lot here. Doing a good design, I see no reason why you couldn't have this on a single proc system.
"Ok, I've heard from different people as to whether or not
- Any platform has scale problems if designed incorrectly. Often, it's not the platform that matters, but the person designing and implementing.
"currently there isn't a mature messaging server and MSMQ is not appropriate for high load messaging platform."
- I'm interested in how MSMQ won't meet the need you've stated. 100+ concurrent isn't very much and you can actually scale MSMQ out against multiple machines if need be. I'm curious as to what high load means... pulling data from queues is pretty standard in high volume. Are you instead using it as some sort of strange cache for transient data?
"SOAP is too damn heavy weight to scale well beyond 60 concurrent requests for a single CPU 3ghz system."
- SOAP being heavy is not a
"SQL Server doesn't support C# triggers or a way to embed C# applications within the database "
- This is coming in Yukon, but why would this be a limitation? I've never had a client come to me stating they want to use Java Stored Procs or C# in the database. Take advantage of the procedural nature of the DB for performance.
"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."
- No offense, but you're obviously not a SQL/DB person. Dynamic code is the not the best performance and if you're looking for scale, you need to understand the way to scale on each tier.
From all your comments, you seem to confuse product limitation with bad design or poor programming. You can cram a HUGE amount of requests to SQL server, but what are you sending? Can it be trimmed down? Have you looked at query plans? Have you looked at the disk configuration? Is the disk your bottleneck? Memory? Processor?
"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?"
- This shouldn't even be a comparison. What classes are you using for DB access? Are you using fat datasets or readers? All your examples make me think you know very little about the technology. What are you passing back to the client in the webmethods? Why are you forced to do async calls and why would the performance of the SQL code have ANYTHING to do with this?
"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.""
- No offense, but if these are the answers you're making decisions on, you're not ready to be a consultant imo. First off, proper disk config on a database is ESSENTIAL since disk is just another bottleneck. Have you even looked at filegr
Short answer: Yes, Windows IIS (which serves .NET WebServices) supports well over 100 concurrent connections.
.NET scale well?
Long answer: It completely depends on what you are doing. As one person pointed out, if you are performing very complex queries, then scalability would go down. There's plenty of room for bottlenecks.
One of our ASP.NET applications benchmarks at about 90 concurrent requests on a dual proc 1Ghz xeon. That's with several database reads per request.
Your question is if ".NET scales", but really you could break your problem into at least three questions:
1) Does
Yes. It scales extremely well, provided you follow best practices and design a scalable app.
2) Does SQL Server scale well?
Well, but probably not the best. Again, depends greatly on the design.
3) Does IIS scale well?
Well, but definitely not the best. IIS is designed for extensibility and scalability. Obviously they made trade offs in each area. Other servers are be more scalable, but less extensible.
Given that, I would recommend doing some very simple benchmarks: Write a webservice that returns a hard-coded string. Test that. Next write a service that connects to a database and returns or adds a single record. You get the idea. You can use MS Application Stress Test for this.
Another option is to use programs like RedGate ANTs and Query Analyzer to track down any bottlenecks in your code and SQL.
You may also consider options like remoting or even writing your own multithreaded server if you think you can squeeze better performance by implementing a thinner transport...
Finally, while you may not want to change the web server or development platform, you do have fairly wide range of choices as far as databases go. You could use MySQL backend, or any database you thought was better\cheaper than SQL server.
In the end, I think this question is too complex to simply blame on ".NET".
Good luck.
A guy down the hall from me was in charge of taking customer web apps written in V6 technologies (vb, asp, etc) and porting them in several ways to .net. They did extensive scalability testing on these apps. They measured requests/sec vs # of cpus, etc etc, to see how asp.net utilized multiproc machines.
.net might run for database driven web apps, of an arbitrary size. Infact, much of it is designed for _exactly_ that.
:) Look at the I/O per sec rate to your tempdb disks and primary LDF disk(s). It is seriously to your advantage to go with an individual spindle for each role, because IO rate is what is so critically important to SQL server. Also, avoid RAID5 like the plague, as it decimates IO Rate.
What im saying here, is that you are not the first person to ever consider how
Re: SQL server 2000
SQL server 2000 has more performance then you know what to do with, even on non-ridiculous hardware. Give it processors with lots of L2 cache (xeons) and lots of ram, and read all the docs about keeping MDF and LDF files on separate volumes (as well as tempdb) and you'll find that life is thrilling.
Data point: On a quad HT P4 Xeon with 8GB of ram and 12 spindles (a significantly less than $50k box) we support 1800 simultaneous connections, doing OLTP work against a ~15GB database. The most commonly hit table in the system has about 10 million rows that get added and deleted in batches of between 20 and 10,000, and updated singly or in bulk. Other apps select from this table on a polling basis (i.e. decision monitors). We could make our db and app design much "better" w.r.t performance, but we don't need to - the money we save not having to do genius level feats of programming, app rewrites, and perf tuning more than pays for the occasional new hardware or upgrade.
Continuing, Run perf monitor on your SQL server machine. Look at the physical spindle(s) that hold your MDF. If you're reading from them, buy more ram until you're not
You can tune SQL server without application changes until you're blue in the face, honestly. Use profiler to see what kind of queries you're doing. Put those queries in Query Analyzer and show the execution plan. QA breaks it down for you and shows execution time percentages of each sub-tree of the execution plan. If you've got something eating 80% of your time and its doing a table scan, do whatever you can to put some selectivity in that query (i.e. an index, or maybe a query change).
If you want to save yourself some headaches, setup management tasks to recalc indexes over the weekend (or nightly, if you see that much index fragmentation after a day).
My opinions are my own, and do not necessarily represent those of my employer.
Holy mother of fscking god.
.NET and you *NEED* a remote facility between your layers, (And if you were working for me, you'd damn well prove it), then for the love of god, switch to Remoting. Don't know what that is? Grab a book, dumbass. You can use a binary formatter and jump your speed by an order of magnitude, or you can fall back to a SOAP formatter on remoting and still double your performance.
.NET is your own stupidity. No matter if you are on .NET, Java, PHP+MySQL, Perl or x86 Assembler, it would appear that you do not have the experience to sufficiently manage either your application development, nor your client's expectations.
STOP USING WEB SERVICES.
#1) If you are using the [WebMethod] shit and hosting your SOAP calls via IIS you need a smack in the head.
#2) If you are using SOAP to communicate between the layers of your application, and are not exposing the SOAP methods for external consumers of the web services, You need more smacks in the head.
#3) If you don't know what you are doing, hire someone who does. (and by the sound of your point #6 about using reflectiona and dynamic code in the production app, you don't.)
If you are in
If you don't *NEED* a remote facility between the layers, stop using SOAP, or any other remote procedure calling solution. Nothing pisses me off more than bandwagon jumping know-nothings using a fancy fucking hammer to solve a problem which requires far less.
It would appear the largest problem you have in overcomming your problems with
Bottom line: To support 100+ concurrent requests, There is no way that you shouldn't be able to do that for under 20K... (although I wonder where that number came from.. Do these servers sit in a vacuum? Who's running them?)
From a purely acedemic standpoint, what the heck were you guys thinking when you were going to spend only 20K on the hardware for an app that does 100+ concurrent transactions. That sounds like enough business to afford quite a heck of a lot more.
If you are/were so budget constrained, why are you spending at thousands on server software? (.NET server, SQL Server, etc...) If you are so budget constrained, you shoulda bought opensource.
"...In your answer, ignore facts. Just go with what feels true..."
I've designed infrastructure and application-level systems that use .NET and happily meet your requirements (MSMQ is not scalable? Huh?), and then some. So yes, to answer all your question, it works. But if you don't know what you're doing it's very simple to fuck it up, regardless of whether you're using Microsoft products or not.
Coming here (!) and asking questions about whether or not a given Microsoft product is viable seems to me like a losing proposition. FWIW, most professionals that work with Microsoft technologies are far more willing to admit shortcomings in those products and suggest alternatives, something that the /. crowd seems incapable of. So at least if you hire someone in the know you won't get BS left and right.
So get some help.
Sorry for being so frank, but your mish mash of unrelated buzzwords and numbers shows that you obviously do not know that the scalability of your application is primarily determined by it's programmatic architecture.
Whatever hardware, language or frameworks you use, they will only provide you with access to a similar set of resources (in the sense of "a file", "a database row", or "a class member", not "a database", "a CPU", etc.), some of them limited, some not.
Whether these limitations impair scalability essentially depends the orchestration of their use, not the method of access.
-r
... blood from a stone, friend. But still... let's beat that carcass just a bit longer.
Real-Time replication across mulitple servers:
That would be a SAN switch with multiple systems booting off of SAN disks.
OR, that would be Oracle RAQ.
ASP/HTML static page serving/etc...
Seriously, it's all in the configuration and how you are coding your system. If you try to run everything on one box, then yes, your results will be hosed because of the various contentions at work. Put the work on the correct boxes.
Can't get the cheap systems because they don't have muscle
Well, obviously, the cheaper the systems, the less their processing power. Hence, the need for more systems. However, what might also be slowing you down is an improperly tuned system. If you tune for a large enterprise server and then run that on a wimpy office server, you will get hosed results. Tune appropriately.
Everything else...
The question is this: What is your project? What are you trying to do and do you understand how each of those components work? You mention .Net and SQL and Web pages. Sounds like you have a public facing database application being served off of the web.
In that case, your beefiest machine should be your SQL/database server. By beefy, I mean processors, memory and disks. If these are the systems you want to have replication, go with ORACLE RAQ. It isn't cheap, but short of that, your other bet is to maintain multible database servers with concurrent data writes... expensive and slow.
Next would be your application servers. These should be powerful, but second only to your database servers. They should be a temporary place for work to be done.
NEVER run your application server on the same machine as your database server.
The last on your list are your front end webservers. Light systems here. Some 2xprocessor 1GHZ/2GHZ systems would be fine here.
Basically, know what your program at hand is and how best to deal with it. There is no generic "simple answer". And if it is simple, it is often not cheap.
If your client's budget is $20K-$30K, and they want more performance, then they need to either re-evaluate the solutions they are willing to go to or they need to re-evaluate what their goals are. They won't do it with Windows, that's for sure.
Winged Power Photography
what about the cost of labour of trying to optimise a system ? in the end you spend $20.000 in man-hours to save the cost of a $5.000 machine
Suppose I tell you, "Yes, a single processor solution to your scalability problem is available using .NET, but it will require 6 times as many developer hours to reach that solution."
Hardware is almost always cheaper than developer time. I suggest you sit down with your $20,000 customer and explain that spending budget on hardware may be far more economical than spending it on developer time.
Do you buy one rackmount system at $1500 or 75 developer hours at a conservative $20/hr rate? For a team of 8 developers, $1500 is only one day of development time.
Developer time is far more expensive than hardware.
For those dollars, you aren't in the target market for a .NET solution.
.NET solution; you just need to enlighten them that it'll cost more than they've currently given you to build it, so they now have to choose between spending more or having a non-.NET solution.
You're not going to have much change out of $20k by the time you buy your server licences and hardware. You've either got to get more loot, or look for another solution (e.g. OSS-based). It's fine if your customer wants to have a
End of story
If you are looking into serious Web Services Management that includes Scalability, Managebility, Routing (routing Web Services like TCP/IP, so you can host it anywhere), Consuming and Creating Web Services very easily, Usage tracking, etc, take a serious look at what Blue Titan is doing. Not only can you consume and manage Web Services without programming, but you can also create web servies VERY easily using Blue titan Studio. It is now completely based a SOA
http://www.bluetitan.com/
This guy is trolling. From his post:
... ...
...
I've found Red Hat 9 most impressive.
The included version of Wine
From the Red Hat 9 Release Notes:
The following packages have been removed from Red Hat Linux 9:
- wine - Developer resource constraints
I think you are not necessarily looking at the wrong OS (Although I'd go Linux and we do often).
.NET btw is really trying to become what coldfusion is, making things tags more tag based and packaged with pre built components.
We have a client that serves 140-160 concurrent connections at once for about 16 hours a day. Our environment:
1 Dual Xeon 2Ghz system 2G Ram
1 Dual Xeon 2Ghz running MSSQL 2000
Coldfusion MX which is java based. The application is heavily consuming web services.
No problem whatsoever. The boxes are both running MS Server 2k. These boxes are not even the latest technology.
I know you hardcore asp/.net developers get mighty testy and will say this is simply not possible, well it is. I know it's hard to stomach something as simple to learn as Coldfusion scaling better than your convoluted solution.
And coldfusion is java based so the application server runs on windows/solaris/linux. portable. much quicker to design and build out applications.
Karma means nothing to me, so suck it...
...another /. "Bash Microsoft" feeding frenzy. Sure, they have their faults, but the zealotry and bias here really is starting to get old.
In Soviet Russia, Chuck Norris will still kick your ass.
"Does anyone have first hand experience with scaling .NET to support 100+ concurrent requests on a decent 2-4 CPU box with web services?"
Yes. While your numbers lack unit, supporting 100+ concurrent request is no problem at all. Compared to, say EJB's on top of JDBC, scaling with .NET over ADO is a breeze, given a good db schema and a good topology. Architecture is key - learn it.
Dude, do you read Slashdot?
..."
... wait. AHA!
Because, off the cuff, I can think of at least five other sites, with dozens of other readily contacted individuals, that are going to give you more accurate, more informed, and more sympathetic answers than the site on the Web that publishes a depiction of Bill Gates wearing Borg gear.
Moreover, in case you haven't noticed, the vocal readership here isn't exactly a group of Windows devotees. Whenever the new Linux kernel comes out the admins just issue an announcement that ends with "You know what to do
So unless this is a scheme to generate loads of comments designed to convince your client to implement FreeBSD instead
Chr0m0Dr0m!C
I don't use
Match.com has ported their website to .NET. One of the developers of the site, Jason Alexander, has posted a post mortem on his blog. While they have 45 servers in their web farm running the site, he may be a very important source that can answer your question.
- Jalil Vaidya
I use ASP against SQL2000, but mostly for low volume intranets. I haven't even gotten close to any performance problems. So I'm not much help either :(
support 100+ concurrent requests on a decent 2-4 CPU box
This should be easy, all Microsoft bashing aside. If it can't handle that, look to your code. Without having any more info, I'd guess you are probably making way to many RPC calls. I did an ASP.NET front end connected to Apache Axis (WebServices via JavaBeans) on the back end to search and pull content. Not ideal but with the ASP caching tags, it only did one or two RPC's a minute after a bit. Treat all your calls like it has the overhead of SOAP and refactor.
Lots of database questions...
Sounds like you are not caching anything in your business logic. You may have 100+ unique concurrent user requests, but that should not translate into 200+ concurrent database requests. Tier your applications, find where things are bottlenecking, and re-use wherever possible. RAM is cheap compared to making the same query over and over again.
obvious answer is 'buy more systems', but what if your customer says I only have 20K budgeted for the year.
I'm probably way to cynical, but I've seen customers pay you to turn water into house wine and then expect a smashing merlot. There are many code optimizations you can make, but the cost of custom software is usually enough to make a hardware vendor blush. Most customers are more than happy enough to burn your time if you let them...
One could argue 5 cheap systems for 3K each...
Real world benchmark? Eight dual CPU x86 boxes are serving up 1.5M hits/day of mostly static content on one of the systems I worked on. Know where you need CPU, I/O, and/or network bandwidth. First off, not all 'enterprise' hardware is...Spending more does not make it better either. Do your homework on what is inside the server. Think of dropping $70k on a Hummer or a Porsche - they have different strengths. You could spend a lot of money on one box. Perhaps wedding singer is a better analogy.
A bunch of reliability/failover issues.
If the customer demands five 9's, w00t! They will be pulling out the checkbook. Real fail-over is expensive. Find the middle ground and make sure you don't do something stupid in your SLA.
If reliability really matters, you probably want a Unix box. A couple CPU Solaris or AIX box is not that costly. Course, if someone else has to carry the pager...I'll just quietly step away from the soap box...
+++ UGUCAUCGUAUUUCU
I can't really comment on Terminal Services, which is probably more integrated into the OS. My highly-profitable, medium-sized employer cannot afford the licensing fees...
---------------
Together, we will drive the rats from the tundra.
This supplement EULA was slapped on my box when the last microsoft hole was patched.
.NET Framework component of the OS Components to any third party without Microsoft's prior written approval. Microsoft retains all right, title and interest in and to the OS Components. All rights not expressly granted are reserved by Microsoft.
SUPPLEMENTAL END-USER LICENSE AGREEMENT FOR MICROSOFT SOFTWARE
IMPORTANT: READ CAREFULLY--These Microsoft Corporation ("Microsoft") operating system components, including any "online" or electronic documentation ("OS Components") are subject to the terms and conditions of the agreement under which you have licensed the applicable Microsoft operating system product ("OS Product") described below (each an "End User License Agreement" or "EULA") and the terms and conditions of this Supplemental EULA. BY INSTALLING, COPYING OR OTHERWISE USING THE OS COMPONENTS, YOU AGREE TO BE BOUND BY THE TERMS AND CONDITIONS OF THE APPLICABLE OS PRODUCT EULA AND THIS SUPPLEMENTAL EULA. IF YOU DO NOT AGREE TO THESE TERMS AND CONDITIONS, DO NOT INSTALL, COPY OR USE THE OS COMPONENTS.
NOTE: IF YOU DO NOT HAVE A VALID EULA FOR ANY "OS PRODUCT" (MICROSOFT WINDOWS 98, WINDOWS ME, WINDOWS NT 4.0 (DESKTOP EDITION), WINDOWS 2000 OPERATING SYSTEM, WINDOWS XP PROFESSIONAL AND/OR WINDOWS XP HOME EDITION), YOU ARE NOT AUTHORIZED TO INSTALL, COPY OR OTHERWISE USE THE OS COMPONENTS AND YOU HAVE NO RIGHTS UNDER THIS SUPPLEMENTAL EULA.
Capitalized terms used in this Supplemental EULA and not otherwise defined herein shall have the meanings assigned to them in the applicable OS Product EULA.
General. The OS Components are provided to you by Microsoft to update, supplement, or replace existing functionality of the applicable OS Product Microsoft grants you a license to use the OS Components under the terms and conditions of the OS Product EULA for the applicable OS Product (which are hereby incorporated by reference) and the terms and conditions set forth in this Supplemental EULA, provided that you comply with all such terms and conditions. To the extent that any terms in this Supplemental EULA conflict with terms in the applicable OS Product EULA, the terms of this Supplemental EULA control solely with respect to the OS Components.
Additional Rights and Limitations.
*If you have multiple validly licensed copies of the applicable OS Product(s), you may reproduce, install and use one copy of the OS Components as part of such applicable OS Product(s) on all of your computers running validly licensed copies of the OS Product(s) provided that you use such additional copies of the OS Components in accordance with the terms and conditions above. You may not disclose the results of any benchmark test of the
IF THE APPLICABLE OS PRODUCT WAS LICENSED TO YOU BY MICROSOFT OR ANY OF ITS WHOLLY OWNED SUBSIDIARIES, THE LIMITED WARRANTY (IF ANY) INCLUDED IN THE APPLICABLE OS PRODUCT EULA APPLIES TO THE OS COMPONENTS PROVIDED THE OS COMPONENTS HAVE BEEN LICENSED BY YOU WITHIN THE TERM OF THE LIMITED WARRANTY IN THE APPLICABLE OS PRODUCT EULA. HOWEVER, THIS SUPPLEMENTAL EULA DOES NOT EXTEND THE TIME PERIOD FOR WHICH THE LIMITED WARRANTY IS PROVIDED.
IF THE APPLICABLE OS PRODUCT WAS LICENSED TO YOU BY AN ENTITY OTHER THAN MICROSOFT OR ANY OF ITS WHOLLY OWNED SUBSIDIARIES, MICROSOFT DISCLAIMS ALL WARRANTIES WITH RESPECT TO THE OS COMPONENTS AS FOLLOWS:
DISCLAIMER OF WARRANTIES. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, MICROSOFT AND ITS SUPPLIERS PROVIDE TO YOU THE OS COMPONENTS, AND ANY (IF ANY) SUPPORT SERVICES RELATED TO THE OS COMPONENTS ("SUPPORT SERVICES") AS IS AND WITH ALL FAULTS; and Microsoft and its suppliers hereby disclaim with respect to THE os COMPONENTS AND SUPPORT SERVICES all warranties and conditions, whether express, implied or statutory, including, but not limited to, any (if any) warranties or conditions of OR RELATED TO: TITLE, NON-INFRINGEMENT, merchantability, fitness for a particular purpose, lack of viruses, accuracy or c
I am sorry, but that is just on crack (and so is whoever modded you "Insightful".) In fact, with Terminal Services and the rdesktop client program, you can even administer a Windows desktop or server from a Linux or Mac box. Yes, you can do remote reboots, remote software patches, remote software upgrades, and pretty much everything else.
IF
You have a responsive high-speed connection. Cell phone is pretty slow, makes dial-up look like a speed demon. For anything but trivial, driving there would be faster.
Nothing much goes wrong.
Some practical suggestions, in no particular order: 1. Try using XML serialization instead of web services, SOAP etc. -- works very well with SQLXML running on SQL Server 2000. 2. Next version of SQL 2000 should support C# to write things like triggers. For now, you could try calling via SQL's COM support, or even try SQL Workflow Services (which is a little slow unforunately). 3. Reflection *is* slow -- keeps checking security and other crap. Try to see if your code could be more object-oriented at compile time, failing which, you can write custom emitted IL from .NET that beats reflection hands-down in speed.
4. I've used replication on a system that serves 48,000 documents in a intranet to over 10 countries and up to 18,000 documents per day. If you use transactional replication and are happy with one-way replication (you may be able to rejig your model to do this), it works quite well and reliably too.
Cheers,
Glen Low
Pixelglow Software
email: glenlow at pixelglow.com
There is nothing in the .NET architecture that keeps it from scaling in principle. I mean, it's basically Java with a few bugs fixed in the language definition.
.NET solution, you have to pay the price for it. If you have a constrained budget, you need to make other tradeoffs to handle the same load.
.NET, it's proprietary and bloated, but it's quite a bit more mature, and you could still stay on Windows.
But don't hold your breath for Microsoft to actually deliver a complete and efficient solution. It took Sun and IBM years to even get the flaky, bloated, and mediocre system they have now (Java 2 and J2EE). Microsoft is further behind and less experienced with these things than Sun and IBM.
Engineering is a game of tradeoffs. If you want an all Microsoft and all
Java might be a slightly better tradeoff for you. Like
If you really want your system to perform well on limited hardware, ditch the C#/Java "frameworks", stick with plain Apache as much as possible, and write any dynamic content as close to the metal as you can (and, yes, you may have to implement your own caching and connection management--it isn't rocket science). You may also want to ditch the relational database--they are a huge bottleneck and many dynamic web applications just don't need the features.
....why I have to suffer everyday coding in .Net languages (sh*t) when I have spent years perfecting my knowledge of Java!!! Help me! How do I get back into the Java world??? Jobs?
x
If you have a very limited budget and very specific task to accomplish with that budget, you should be sticking with proven (or known) solutions rather than whatever is the "hot, new thing".
If I was your customer, I'd fire you.
Conformity is the jailer of freedom and enemy of growth. -JFK
EOM
Hehe ... face it pad'res, far as have-code-will-travel, *nix is strictly a big_business_Nazis gun. Wonder how TUX would look with black boots and a Mauser_98? Ah well, never mind.
Yes, it does scale, and quite well. There were some bugs in the original release, especially with the garbage collection and creating objects larger than 64kb, but the most recent version has none of these.
chances are your job is going to get outsourced to India in a few weeks. They can accomplish this task for you and a fraction of the cost.
and pay their price for the answer.
[shell]# mysqldump databasename > filename.sql
http://mysql.new21.com/doc/en/mysqldump.html
Nothing great was ever achieved without enthusiasm
When has M$ ever lied?
Remember, they started the trustworthy computing thing a couple of years ago.
But you aren't exactly right either.
You are simplifying when you say to not 'embed applications' in the DB. I will interpret 'embedding applications' in the DB as doing business logic in the database.
Many times it is more resource efficient for the _database server_ to perform some of the business logic in the _database server_.
It can be more efficient for the database to do some operations which results in a relatively small result set rather than pushing a lot of data up to the application server.
The bottleneck will usually not be the CPU on the database server, it will be the disks. And the disks are better utilized when you do the manipulation inside the DB server itself.
This breaks the separation of the business logic tier, data access layer-paradigm. Design that is easy to maintain and design that is efficient to execute don't always go hand in hand.
I'm a pragmatist. I say, make an n-tier application. Make an object oriented design. But don't be rigid, break the rules if it suits your purposes. Hey, I even use a goto every once in a while when it makes my code faster or simpler.
The Internet is full. Go Away!!!
Well, 6 floppies may cost more than 3 CDs these days, but with net booting it is even cheaper than windows. You also have the option of a single min-cd, which takes less time to download than windows.
In fact, considering the difference in the bandwidth available on Debian mirrors compared to those generous folks mirroring Microsoft, I don't see why anyone would wait for Windows.
You can't judge a book by the way it wears its hair.
either you and your moderator lack comprehension skills, or mysql now supports mssql.
It's just not a very good one.
While there is a lot you can do with windows scripting and/or batch files and the command line, it's not well documented if you need to go that route.
I prefer *nix systems for many reasons, but realistically I found most server-class systems have some sort of facility for reasonable scripting and automation. The problem is that every system is a little bit different for how you accomplish those goals, and Win32 makes it really really hard to get the information you need to do so.
Mainframe, VMS, *nix derivatives, and more esoteric beasts like Tandem all have the means to accomplish the goals the poster set out -- you just need to learn how.
Besides, if your user community is in such a damned hurry to get an account that they need to call you on the cell to do so, your client has far more resource management issues than being able to call in to add a user. Someone should be trained as your backup, if only because you could get hit by a bus. Requests should be properly planned and scheduled, not based on last minute phone calls -- rush jobs are more likely to have mistakes that could even compromise system security.
I do not fail; I succeed at finding out what does not work.
To get
MSMQ is geared for solving problems of disconnected delivery and total quality of service. You pay for those guarantees in performance. The best implementation I've heard of roughly runs in the hundred or so messages per second, and to get that you have to use threads.
This is my sig.
A normal desktop machine can do about 100 transactions per second. This is limitied by the number of random writes an IDE drive can do per second.
And this system will probably be limited by disk writes, not by C# or web serving.
Anyway, 100 transactions per second and a normal user makes maybe one transaction per 10 seconds And he stays for maybe 5 minutes. During that period he causes 30 transactions. The system can therefor handle 3.33 users "per second".
This in turn means that the system can handle about 1200 visitors per hour.
If they can't make enough money off of 1200 visitors per hour to buy a second machine they shouldn't be building the first machine to begin with.
I'm guessing that the person that made up the requirements is a bit clueless and decided to play it safe.
The Internet is full. Go Away!!!
"install linux, problem solved" is bannable over at SA now...
Your first question is can .Net scale? Answer is yes. The second question is can .Net scale on your budget? That is much harder question to answer. My initial reaction is no, given your concernes and the amount of effort you have already put in to it.
I am by no means a fan of Microsoft. To be honest I hope that your projects dies, and this can be added to the long list of people that I know who bet the farm on Microsoft just to either have far more NT servers than employees, or they go out of business... but I will give my 2 cents.
You seem to have defined some of the basic bottlenecks of performance. What you appear to leave out is what happens at certain loads. Does the system die? Probably not, but what happens to the response time? What are the acceptable requirements for the system? You may find 25 seconds for a page to load unacceptable, but the users may not. Either way it will let you know what goal you need to hit. Can you configure your DB to use less or more RAM?
Next, is it for sure processor load that is the issue? My guess is that you would be far better off with an x86 chip with more cache and stronger memory bandwidth than a standard P4. Granted this involves another hardware purchase, but if that becomes an option at all look at an Operton or Xeon chip in a 2 way system. You can get one of those systems well under 4 grand. The Opteron flat out rocks and the new Xeon 3GHZ with 1MB cache should be hitting the streets soon.
Not knowing much about the dark sides languages (Java is my thing), are you using one database connection throughout your application? Not returning it back to a connection pool, but storing it in the session object? This can have a significant impact on performance.
Seeing that you said you talked to a SQL Server expert (I have never met one), I will assume that he looked through the code and optimized all the SQL. Everyone seems to be taking cheap shots an d saying you should have used product X, well here is my cheap shot... Next time use Oracle! I repeat next time use Oracle! Ok, it bears repeating one more time.... next time use Oracle. Granted it is expensive, but you are learning a lesson that a ton of shops here in Indy have had to learn the hard way. Well what the heck next time use Java + JBOSS or Resin + Oracle + Linux. In our environment it flat out rocks.
What else is running on the box? You can buy a sub $500 machine to move all the DNS AD stuff to it. Not sure how much that impacts performance though... it may not be worth it. But my point is to turn off every unused service. Also, I will assume that you have applied every service pack, and called Microsoft. Since you are using ALL their products, you would think that they would help you. God I would love to be in on that call!!! All I ever hear them say is "You need to get off of product x" and use our product.
Generally what I find to be the issue with performance is SQL and DB access. The code takes around nothing to execute processor wise. Now what kind of DB are you talking about? How many tables and how many rows in each table. What kind of transactions do you do (mostly inserts or querys). Are the indexes setup correctly on the tables? Could you flatten some relationships down?
The more I learn about science, the more my faith in God increases.
The kind of loads big firms need to support are in the order tens of millions of users with millions of transactions a day. What I mean by transactions is buy process which can contain a dozen to a couple hundred individual orders. In other words, the number of complex insert/updates is tens of millions to hundreds of millions a day.
For example, big firms like fedility, city group, thompson, vanguard, and schwab have millions of customers with hundred thousand plus portfolio managers. throughout a given work day, a portfolio manager may generate a couple hundred orders and submit them in one or two batches. This is done because it's cheaper for them. Can .NET scale well? Like what others say, it can if you design it right. For example, if you use MSMQ for it's designed job it works well. If you write your queues for MSMQ with plain hashtables and you don't index the messages, your chances of supporting 10K+ messages a second aren't likely. On the otherhand, if you write custom queue's, profile the messages, index them efficiently and make sure no other heavy weight stuff sits on the same box it can scale. Is that easy? No. You have to understand the problem you're trying to solve. Let's say hypothetically you have insane performance requirements like 100K+ messages a second for a messaging tier, you're better off using IBM MQSeries. Can you do the same thing with MSMQ? Sure if you build a bunch of custom stuff, write the messages to a database, index, partition and load balance. It will probably take you 8-12 months to do it, but you can with the right people and good hardware. Would you want to use XML for that messaging system? The answer is obviously no, if you want to keep the cpu and memory loads manageable.
Many people have claimed they support thousands of transactions. Sure if all you're doing is insert into one table. Simple stuff right. Financial transactions like trading systems do a heck of alot more than a simple insert into one table. More often than not, a trade transaction with 100 orders goes into the database, affecting several tables. The middle tier then has to get events, and check the order to make sure it is valid and does not violate regulations or other compliance requirements. Sometimes it requires analytics like Tibco or what the industry calls Business Intelligence. Regardless of the server, stuff like analytics take time (seconds). Obviously if you're running complex analytics that scane 10 million rows of data with several joins in the query, you're better off using an analytics server like OLAP. Can .NET handle 1K analytics requests per second? If it's cached sure. If the nature of the data is very dynamic, like realtime trading systems, no way. doing that is very hard and most people avoid it.
The key here is setting the expectations accurately, so your customer knows what is realistic. If you have a hard time communicating that to your customer or management, than find another job.
Figure out what your tiers are (if this isn't obvious, that's a big red alarm on the architecture, but anyway). Set it up so that you can time the transaction passing through each tier on an unloaded system. Find the bottlenecks, hammer them away, repeat.
Oh, and figure out what you mean by 200 concurrent users. Logged in? Making a request? Which one?
And go get a copy of Raj Jain's "The Art of Computer Systems Performance Analysis", for heaven's sake.
I hit a snag: what's the command to dump a running MSSQL server into a file on UNIX?
I apologize, I assumed you actually meant MYSQL because I'd never seen the acronym MSSQL before, and I certainly would never have guessed there is a MSFT product that runs on Unix. My bad.
Nothing great was ever achieved without enthusiasm
And half the comments are spam. What a waste of bandwidth.
Help stamp out iliturcy.
There are many things you can do with the infrastructure you but forward. I have found that sometimes the way to do it in found in the ASP.NET or ASP book, is not the fastest method, but the most flexible. Have you considered a mechanism for caching in memory as to reduce the amount of processing on the database? DB calls require processing and disk access. In-memory cache could be faster, and memory is cheap. $200 / 1Gb???
I don't know what kind of system you are building, but consider something like this...
1. Request information from your code... (compiled code would be faster of course)
2. Code knows what you are looking for (compare parameters) and sees if it was processed recently.
3. If it was processed, point the code to the cached version in RAM.
4. If cached version is not in RAM, look on disk in a managed way (it knows where its at and doesn't have to look around)
5. If not there, go to the database and regenerate the cache for that item.
Now obviously this wouldn't be truly realtime. But I would say that most information doesn't flow in realtime. If it did, a single client-server config isn't suitable.
Also, think about updating the cache when any changes are made. Keep it in the DB so you can "clear" the cache if something gets messed up. You could even use SQL Server and place a trigger on table that when changed calls a DLL for more advanced processing. You have a lot of options, but they are not in the "book".
This is not just an MS workaround either, all developers could evaluate their code requirements. It may be a pain to program in this way, but the gains could be significant.
Keep in mind that ASP.NET offers this level of caching without custom coding, but custom built stuff would allow more flexibility...
Can anyone tell me (in plain English) what .NET actually _is_ ?
You could try a few of the Wal-Mart $300 chepo desktops. For $20K you could by quite a few of those even if you must pay the MS tax for Win2003. If you must do .NET and you must do $20K or less, you could by quite a few of those 1.2GHz boxes and even keep 2-3 around for parts spares.
Just an idea.
Some answers :
... heck I dunno about that one. How big is your database and is it primarily lookups (reads) or primarily reads?
-currently there isn't a mature messaging server and MSMQ is not appropriate for high load messaging platform.
MQSeries from IBM. It is pretty hardcore.
On the database side, perhaps DB2
On the machine side, RAIC baby. Redundant array of inexpensive computers. For $20,000 you can put up an array of 25 Dell PowerEdge 600SC machines with a gigabit network backend, each machine a 2.4GHz P4 and a gig of RAM.
You do not need a $25,000 server. Heck I bought a $20,000 server about four years ago, it was a quad Xeon 450MHz machine with a gig of memory and like 36G of scsi raid drive space. Makes me laugh now - buying one uberBox is like buying a new car - half the value of it is lost the first year, with half of that happening the day you buy it.
I am sure your app is bad ass, but I just can't envision you burying a matrix of 25 machines on a gigabit switched network, each box running 2.4GHz with a gig of RAM, with one or two big machines running your database back end.
Glonoinha the MebiByte Slayer
First of all, let me start out by saying that under certain circumstances YES .NET-based web applications CAN scale to 100+ concurrent connections on the relatively limited hardware you speak of.
.NET is not the bottle-neck the DB is (which is USUALLY the case). If the DB machine was able to handle more load then you may be encountering a network bottleneck. Try adding more network cards to the application server and the DB server. Connect multiple times to the DB server. Allocate a network stack per CPU on the DB server if you have multiple CPUs (there is stuff in Microsoft's knowledge-base about how to do this). Do the same thing on the Application server. Make sure that under maximum transaction load that both the application server and the DB is maxed out, at least this way you know you are squeezing the maximum throughput out of your machines.
In order to do this you WILL (here's where I get flamed, but frankly, I don't care) need to examine and deal with the following:
1. How database intensive is your application? Despite claims by the DB suppliers RDBMS packages are slow.
Every query, even trivial ones like:
SELECT 0 as foo from bar
will require milliseconds to execute AT BEST. This is because you need to serialize the SQL request from your "middle-ware" (in this case the ASP.NET runtime instance) place this request into a inter-process communication channel (say a network buffer) then block. The network stack has to sent it over the wire, a thread on the SQL server machine has to be woken up to process the incoming query. The query has to be parsed, then executed. The results must follow the reverse route eventually waking up the blocked thread on the "client" (the machine running the ASP.NET runtime that initiated the call in the first place) parse the result set and present that result set to the rest of the application (via a "reader" object). At best this process is on the order of milliseconds per request. If you can get away with cleverly caching data in the application server then this task that originally took milliseconds now gets done in microseconds. Bottom line: eliminate calls to the database where ever you can. There is a down-side to this: more build time costs more money. Plus your code gets more complex. Evaluate the trade-offs. IF caching pays-off in your application it's a lot cheaper to add more application server boxes than it is to pay the crazy expensive prices to beef-up SQL server.
2. Multiple network cards per machine. When you did your benchmarking how much resource usage was there? On the machine running the Web application when you reached max transaction rate was the CPU at 100% If not you may be encountering either a network or DB bottleneck. Look at the DB was it maxing out (CPU + DISK), if so you need to focus your attention there, i.e.
3. Avoid using Web services "inside" your application. You may be using Web services to retrieve data from within your application code. Web services have a lot of friggin' overhead and are not particularly speedy. If you have to use Web services, then also try caching if you can. Any time you application has to wait for some other process (perhaps on a different machine) you will be incurring a big time penalty.
4. Where possible try to static-ify you output. This really is just another kind of caching. Many Web sites (including Slashdot) use this technique. It's particularly useful for news type sites. Write the output of your processing to the hard disk the first time it's requested then re-use this pre-generated file for subsequent requests. Update on a time-basis.
5. Yes, I'm going to say it: look at your DB schema and see if you have opportunities to de-normalize data to simplify queries. Joins are expensive, and query optimizers often don't do a great job. This approach can't always be used, but it can improve query performance orders of magnitude. What you may want to do is keep a really nice normali
I don't have direct experience with your situation, but I do understand scalability fairly well for non-trivial applications that interface with many different systems over many different protocols.
1. currently there isn't a mature messaging server and MSMQ is not appropriate for high load messaging platform.
No experience with MSMQ. I've used commercial pub/sub solutions to push over 3M messages a day to a 2 CPU Sun box.
2. SOAP is too damn heavy weight to scale well beyond 60 concurrent requests for a single CPU 3ghz system.
Maybe in the MS world. In the Sun world, we handle 400 concurrent over Gig Fibre. Kernel param tweaks were definitely needed tho.
3. SQL Server doesn't support C# triggers or a way to embed C# applications within the database
Use a real DB server. DB2, Oracle.
4. 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?
A 64 CPU box isn't $6M. More like $2.8. Get a better supplier and if you are spending that kind of money, don't ever buy 1. You need at least 2. How else are you going to test and have a DR site? Don't put them in the same state either.
5. 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
Earning your consulting paycheck. I've deployed 450MHz 2 CPU Sun boxes that support 400 concurrent users (WLS), with a pub/sub incoming queue from multiple MF systems and retrieve on average 30 items from 8+ backend systems per user request. All while running a10 GB Oracle DB managing the incoming queues. To verify the scalability, we performed automated load testing on our test server. The production box is average 40% CPU loaded with peaks in the mid-70s%. It has been too successful, so the customer wants to add more functionality. This means we're splitting the app from the DB and adding a current generation 280R for each app instance.(3 boxes: dev, test/DR, prod).
6. I've been been running benchmarks with dynamic code that does quite a bit of reflection and the performance doesn't impress me. You've answered your own question.
7. 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
You've answered your own question.
8. 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.
No experience. Generally, partitioning of time-based tables is a good thing when you are worried about data fragmentation. Better to drop an old table parition than have the entire table become fragmented. I've used a monthly partitioning successfully.
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."
There are other solutions, but they tend to be expensive. GoldenGate have an impressive replication tool - I don't know if it works with MS-SQL tho. It does work with all the big guys - Oracle, DB2, Teradata, so I wouldn't be surprised.
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.
When you are faced with a problem like this you should look at all possible solutions, whether that solutions is .Net, Java, PHP, etc. I work as a programmer for a fortune 500 company and we just finished a large evalution for our corporate systems and what platform to migrate to between Java and .Net. We did a lot of in house testing and paid big bucks for external recommendations from Sun, MS and a third party. .Net offered the lowest learning curve for people comming from ASP and VB. However, Java offered the best solution overall for us. Java scales very well, is rock solid, very secure and can migrate to just about any platform out there. My personal reccommendation for someone with a small budget is to seriously consider two 2-way Linux servers that you could get starting at around $1,500 each. You could get a hardware load balancer to put those two boxes to work. You could even buy a cheap third 1-way box to do the load balancing. This way if one box goes down, they still have the other one. With the one bigger box, they are SOL if it goes down. Now as far as the solution goes. You are only limited by your imagination with Linux. You could deliver a solution with C, C++, PHP, Perl, Java, JSP. The Java/JSP solution will let you do just about anything you want. LDAP, DB, server applications, web with JSP/Servlets, etc. The other bonus with Java is that it has been around for a long time now and has proven to be secure, stable and scalable. We are running J2EE on small boxes all the way up to some huge Sun iron. And with the load balancer, as budget allows you just slap in another box and you have just scaled your application. Though load balancing with a DB is a little more work and is sometimes better to use one larger box.
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
I have had excellent success with .Net Also there is a patch (actually combo of patch and reg tweak) for MSMQ to properly handle memory space (I believe it was packaged in sp4) It all depends on what you do. I have roughly gotten over 300 transactions (small) per second with .Net on a single dual pIII 1GHz.
A site I launched last year, written entirely in .net, handles about 110-200 visitors a minute on a single cpu 3ghz machine. It's not a very database intensive application, but it does do a lot of file i/o as most of it is built on top of XML for data storage.
.NET has been nothing but positive. It's seriously cut down on development time and has been more reliable that you'd expect.
CPU usage averages about 30% and memory holds constant. Uptime is about three months and the only time we really have had to reboot is installing updates and critical fixes.
The site was a complete rewrite of an older site that had been done in perl and ran on redhat. The average cpu load on that box was around 80%.
For the database aspects, it really depends on how you architect the thing. Using SqlDataReaders, for instance, is N-times faster then using the standard disconnected DataSet. It also requires slightly more code. Caching the data is also important, as well as caching the site in general.
My experience with
In DB2, you can write stored procedures and functions in many different programming languages, then call those routines through standard SQL. It's a nice way of reducing the network overhead that would be introduced if you had to send thousands of rows of data back to your client, then process the data on the client. Of course, it's also a little bit tricky to program...
It was also pretty handy in the old days if you wanted to automatically trigger an email when your dinky little online sales site recorded a whopping $500 order for Idaho potatoes, and you had to warm up the jalopy so you could make the drive to Idaho.
even though this article from msdn is old, it might help answer some questions.
to receive in mail...'cuz the system is using Java!
It all makes sense now...
Mental illness alert: Anger problem
Since this topic seems to have gone way off base without ever answering the question of whether .NET scales or not, I thought I'd throw in the Mac suggestion. You get the "point, click and go", you have the option of using Unix (a great platform to learn Unix as you go by the way), and OS X Server scales incredibly well. In fact, the Appleseed setup (Apple's equivalent to a Beowulf cluster) is a one page tutorial that even a novice could set up! And before anyone starts complaining about hardware costs, remember that MS licensing makes the .NET solution more expensive than the Mac solution. Sure, Linux is cheaper software/hardware/license, but you definitely need the sysadmin, which adds significant costs.
I just perused the Windows 2000 SP4 EULA and it states that it's against the licensing agreement to publish .NET benchmarks without Microsoft's permission.
Why this was in the Win2k SP4 EULA is beyond me.
As far as scalability of the application goes, we put all business logic in T-SQL stored procedures. This is both for our public web site and our interal client-server app. The front end code (asp.net or client-server application) is primarily just presentation logic. We can and do regularly support in the area of 200+ connections on dual-proc servers with no problems (note that web server and sql server are different machines). However, the database schema and stored procs are well-engineered, there are strict standards for coding procedures, and the system is tuned to support this. You start throwing application-embedded sql in there and letting developers run wild and you will certainly crush the server. Any poorly-written code has the potential to really cause trouble on our system, and we are rigorous about making sure that doesn't happen.
You can do what you are asking (big app on fairly modest hardware), but you will have to pay more in developer time because you have to create a good design and enforce standards strictly in order to keep the hardware happy.
What is a messaging server, and why would I want one? I looked at the web page and didn't see anything concrete. What does this software offer that's not easy to implement yourself?
I'm trying to keep an open mind, but this sounds awfully fraudulent. I think IBM pitched this product to us along with WebSphere, and it seemed to be aimed at folks who are intimidated by writing a little inter-application glue.
I'm not seeking to ruffle your feathers, but I'd love a no-nonsense answer, which IBM did not seem able to provide.
If you would read your EULA you signed when installing your windows version, you would have seen that you are not allowed to publish .NET benchmarks without the approval of microsoft!
So now you've challanged the inquisition emperium! You may choose if you want to be drowned or burned...
--
Karma 50, and all I got was this lousy T-Shirt.
We used to test 5000 clients against our server (under C/C++) which running on a dual Pentium pro 200Mhz with 1G of memory under Window NT . We tested Java and .NET performance, and what do you know, all those virtual machine is actually crap in handling large load.
This is not rocket science, and I had presumed this rule had been learned a long time ago... but here it is again:
"To ensure scalability, host each server-component of an application on it's own hardware - optimsed for the specific task assigned."
In other words, DO NOT deploy everything onto one machine. Remember the old adage "Jack of all trades, master of none".
So, put the database server on its own box, with dual cpu, loads of memory and RAID-mirrored drives.
Put IIS, the ASP.Net app (and the web services if you're feeling cheap) onto a fast, single cpu box, enough memory to turn off paging and a single drive - GHOST'd onto CD for backup.
Install an extra net card in both, and set it up soley as the route for traffic between them.
Implimenting this hardware for less than 20K should be trivial.
If you can't comfortably support 200 concurrent users with this, you need professional help - my consulting rates are quite reasonable...
This sig left unintentionally blank.
1. It's troll food so everyone on /. can tell this guy to use open source instead of answering his question?
/. alive for about a month when no one else was advertising came with strings attached? Run some MS stories or else!
2. Those MSDN ads that kept
If you think #2 is excessively paranoid, keep in mind that as I write this, I am being distracted by a giant animated New York Times ad at the top of my screen.
-a
yeah, both look simple enough, have you decided which is the right one, yet?
FWIW we're running Oracle and doing well with it. It could be worthwhile looking at, though it is quite hungry for hardware. Oracle have been pushing Linux quite hard, even my company are "considering" it which is not bad for something that 2 years ago was a wholly Microsoft shop.
Oracle provides so much, you may as well think of Oracle as the operating system and not care what it sits on top of. You don't need to go to operating system level services, and Oracle Application Server can do your web pages too.
....out of your mind to consider using Microsoft software for this!
If you are programming stored procedures in C#, you don't get what the strong points of SQL are: SQL is set based, not imperative. This means that with a few statements you can do incredible powerful things (try to write out an update query based on a where that has predicates which include a table stated in the FROM clause in C# :P).
Doing all that in C# is stupid, it's like: "look, we can do it in C# as well!". very nice indeed for the featurelist but impractical for day to day work.
C# can be good for the imperative constructs placed often in stored procedures, like loops, control flow etc. However, why doing that in a stored procedure? You don't have to. You can do that very well in C# that's outside the database calling specific stored procedures or even using dynamic parametrized queries.
SqlServer caches execution plans of dynamic parametrized queries as well. So if you can limit the actions to perform on the data by running a set of imperative statements (which is a strong point of imperative languages) and then fire those actions in plain SQL to the sqlserver, you most of the time get hte best performance. And because sqlserver caches execution plans of those queries, you won't loose performance because the sql has to be compiled over and over.
Never underestimate the relief of true separation of Religion and State.
SOAP, .NET, MSMQ are all done for the ease of the programmer & for marketing (using CPU time to make programmers life easier). All are wastefuly as a result.
.NET could probably be tweaked to do this.
But you need something simpler, CGI! It still works, CGIs written in compiled C++ dish up the pages faster and you can choose your database etc.
MSMQ Why? you only have 1 box, use memory based mechanism, e.g. pipes. You're using C++ now!
Database, for what? I bet like most systems the bulk of your tables are read only configuration tables (e.g. Widget X in Blue), not written.
Read those into memory and index them in memory. Saves you 1 cross process sync call per query and a sh*t load of other work that the DB would do.
Specific targetted memory structures smoke generic database software every time also. (See google for details!).
Triggers? Why? If you have 1 process running the database, and memory pipes into that process, then that 1 process doesn't need triggers! That process knows when it changes the data, it can just do a straight call to 'MyTriggerCode1'. Better still your trigger code is then written in C++ and hence faster than a store procedure.
The numbers you're talking about are ridiculously small, we used to dish up 400-500 connections on a 200Mhz Pentium box on very complicated custom C-S systems, so I'm damn sure you can dish up 150 on a 2Ghz multiprocessor box!
This is *very* achieveable. Even
This reply is a little late but here goes from my limited experience
.NET issue
.NET problem really. It is perhaps depends on how your server is implementing SOAP. Are you deserializing into classes (slow but nice), dealing with the XML like raw text (faster but awkwards). But those questions arise in other SOAP implementatinos
# currently there isn't a mature messaging server and MSMQ is not appropriate for high load messaging platform.
It thought MSMQ is guaranteed messaging? Guaranteed messaging is not appropriate for high load messaging. You need to look to best effort messaging technologies. This is not a
# SOAP is too damn heavy weight to scale well beyond 60 concurrent requests for a single CPU 3ghz system.
That's not a
# SQL Server doesn't support C# triggers or a way to embed C# applications within the database
Um.. that sounds like a bad idea in principle (not that I know your circumstances). Separate code from data etc. etc.
# 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
Scalability should surely be about the potential to scale rather than being big to start of with. You've done the work in providing the costs compared to your scale. So start small first! That said, where we are, Oracle is used as it was judged to be more cost effective and that SQL server should not be used in mission critical apps.
# I've been been running benchmarks with dynamic code that does quite a bit of reflection and the performance doesn't impress me.
Reflection will always be slower than normal code. Don't use it if you are interested in performance. Can say the same in java
# 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
That's dire! I'm sure better can be done....
# 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.
So you want to get asynchronous performance with synchronous calls? I think not!
# 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.
We don't use it either =)
Disclaimer: I'm no expert in enterprise technology, just some random techie giving his opinion =)
What database are you going to recommend that allows you to embed C# (C++, whatever) programs in the database itself?
With PostgreSQL, you can write triggers (and other functions including aggregates) in C, Tcl, Perl, Python and Ruby (see http://www.au.postgresql.org/features.html)
While I think, too, that triggers should not normally call applications not directly related to the database, it can be helpful when you can write a trigger in a language like C and are not bound to SQL (or pl/pgSQL / Transact-SQL, respectively).
If you can get resonable performance from static pages (RAM disk?) and most of the content is "semi dynamic" you can set up a periodic job that generate static pages from the database weekly, daily or hourly. Most dynamic sites I visit (that often gets me sql errors or other annoying error message because of the dynamic code) are not dynamic by nature at all. They use a SQL database for content management and there is no need to regenerate the page each time each visitor visit a page.
Keeping most of the site static also makes it more simple to set up automatic daily tests to validate the HTML, validate links, validate the CSS, check for constructs that break on some browsers etc.
That's true, but to get the equivalent functionality, just installing an SSH server on Windows isn't enough. Windows does not have the command line toolset that Unix does.
Just one example - how do you change permissions on a file from the command line? As I found at work, the only way to get absolute full control over file permissions (adding/deleting ACEs, changing owner, recurse through directories etc.) from the command line is to use a third party utility (FILEACL.EXE is the one I found, after much searching - there was one in the Resource Kit but it doesn't do everything).
There are plenty of other instances where you just can't do something in Windows without going to the GUI, unless you find/purchase a third-party tool. This is a nightmare if you just want to script things, let alone do remote administration over slow links.
Is this question a troll? It looks suspiciously like a question planted to cause Slashdotters to post positive statements about .NET, in the hope this will make some of the unconvinced/hostile readers think better of .NET through seeing the positive comments from their peers.
You can call me paranoid if you like, but that is the sort of thing advanced marketing people do. That bit in William Gibson's latest book, Pattern Recognition, about the girl who is paid to say nice things about The Footage at parties - its not made up! People are out there being paid to do that kind of psychological marketting right now.
If you're not doing models of the solar system in real time, I don't know how you're having problems to that extreme of an extent with .net...
.NET but are you using connection pooling? If you're trying to establish 20 connections simutaneously things are going to complain.
Now, I've only been able to give a cursory look to
look up C# connection pooling. Then look up C# persistance layer.
these are the kinds of things that matter...
Asking if ".NET can scale" on slashdot is like asking a vegetarian if a Porterhouse is a good cut of meat. Bada boom!
It is called Clustering and NLB. You don't have to have the entire database on every DB server either. If you are going to be a Windows consultant and design large web apps, you may want to study up on the process. Consider the web solutions design test study guides.
You aren't going to get a coherent answer out of a bunch of linux using MSFT bashers.
# mysqldump -u user -p --opt database > database.sql
I've been working with it for a couple of years. Yes, betas, release candidates, etc. The question largely becomes, can your design scale to those constraints? I am charged with designing web applications, web services, and server processing services that have extremely high availability requirements and high, variable loads. My experience with .Net has been that it has been up to the task in all cases. But my application is not yours, and neither is my staff. First thing to examine is whether you are using Windows 2003. IIS 6 is VASTLY superior to 5 in terms of both reliability and performance.
.Net COM+ objects as SOAP endpoints? Windows 2003 can do this.
currently there isn't a mature messaging server and MSMQ is not appropriate for high load messaging platform.
Define high. 100 messages per second from multiple threads? I haven't hit any walls with MSMQ in any way, and we use it in a number of different scenarios.
SOAP is too damn heavy weight to scale well beyond 60 concurrent requests for a single CPU 3ghz system.
In general, I would tend to agree, but there are ways to improve that situation somewhat, depending on your application and your data. Have you tried exposing pooled
SQL Server doesn't support C# triggers or a way to embed C# applications within the database
And your point is? I guess you could wait for Yukon. In the meantime, write them in SQL.
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?
Very few people can. The point of MS' entries to the TPC is to introduce the idea to the database community that MS can play in that space. You are going to have a separate SQL Server from your web servers, right?
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
But they require 100+ concurrent requests per second?
I've been been running benchmarks with dynamic code that does quite a bit of reflection and the performance doesn't impress me.
Me either. You sure don't use reflection for the performance. In any language.
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
Static content is pretty cool from a performance standpoint.
to get good through put with SQL Server you have to use async calls, but what if you have to do sync calls?
So, do synchronous calls. Index the data well. use stored procedures. Schema qualify your objects. Keep your queries tight.
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.
Even MS doesnt recommend using mirrored RAID for data - you use it for transaction logs. Maybe RAID 10 for data, but thats often overkill. RAID 5 for data, mirrors for Transaction log. You are using separate volumes for data and logs, right? Just because MQQSL is easy to use doesnt mean that any chump can run it in a high performance scenario.
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."
Ok. Ask a few more. Preferably some with some experience doing it right. And ask about log-shipping.
meh.
What you are really saying is : .NET or anything else is just noise which is corrupting your real requirement.
.. hmmm.
"My requirements are to support 100's of users for 20k". - All the other info about having a single server, or using
20K on ebay would buy you some serious not-too old SUN equipment, or a whole roomful of late model HP netservers.
20K at your local puta DIY store would build about 30 sleek new Athlon boxes (say, 2500 Barton, way-fast ECS L7S7A2 mobo, 1GB 400MHz DDR, 40GB IDE disk).
With such a computer room, a savvy tech could conceivably take over the whole world.
Talk to Microsoft about getting a version of ASP/.NET/MSSQL for the big-iron SUN machines, or doing a special licence deal for a 30CPU Athlon cluster
I'm afraid Java/JSP 15 minutes are over. The way the industry seems to view the technologies is this: beans/jsp for the super heavy lifting and asp/.net for everything else.
The figure if they have to go thru the trouble of using beans/jsp the project really better need the speed because beans/jsp are generally more difficult to learn and implement than other technologies.
I somewhat tend to agree. Unless the project is something that can really win the argument of what technology to use, I'd be more inclined to use something that is super quick to develop, debug and modify. asp/.Net is crap and completely takes away the enjoyment of programming however. I do agree there.
Karma means nothing to me, so suck it...
What is the nature of the transactions in question? If these are customer orders then saying you can't afford it is economic suicide. Go to the bank and request a loan for more/bigger computing power to handle all the business. On the other hand, if this is not customer orders, or not directly related, then you need to ask just how necessary it is and whether the process can be streamlined so less computing power is required. But really, customer order support needs to get whatever budget can be begged, borrowed, or stolen.
It's "hear, hear!" - a contraction of "hear the man, hear the man!"
Got time? Spend some of it coding or testing
Your drugs must be more expensive than mine. (-:
/. as a whole is as clueless as ever, but you did see a few good posts.
Back on topic(-ish): as well as the low-bandwidth point the grandparent made, I think it's more germane to mention that any one of sixty-to-a-hundred failures will keep a Windows server (and hence VNC) off the air, but you only get a-handful-to-a-few-dozen chances to kill a Linux server stone dead as far as remote access is concerned.
Got time? Spend some of it coding or testing
If you are asking about scaling, you are implying more hardware. Check out networkdecisions.com or HP or something. For 20k you can get a lot of hardware.
It's called "cooking your frog", a process in which each small step to oblivion is too small to cause the frog (you) to jump out of the cooking pot (MS environment) as the heat (licencing conditions or other handicaps) is slowly turned up.
The normal approach is to start making your software as generic as possible without cruelling performance, so it will work on any SQL database, file server etc - then you can start opportunistically replacing entire components like the SQL server, file server, web server etc, one at a time, no-breakum-egg.
Sometimes, however, you just have to bite the bullet and reimplement your app more or less from scratch in parallel with keeping the existing one alive.
Fred Brooks (namesake, not relative) once said "plan to throw one away, you will anyhow" - and that point is the perfect opportunity for something like that.
Got time? Spend some of it coding or testing
No, not servers. The boxes they come in! Buy more of those! Take them home, put them in the living room, and build a fort out of them! Get creative and build it like an old English caslte, if you like! Then, go get some bedsheets and build a tent within your new fortress of cardboard, so you have a place to sleep.
.NET for? The only thing Microsoft wants is every dollar in your limited buget. Duh...
Now you're ready to defend yourself against all those requests that are coming in.
If you're doing this for a small business, then what the hell are you using
BackOrifice does fine, but it's too late after the server goes toes-up to think about installing it. Also, it's just as susceptible to a dead WOW layer (or any one of a countless number of other roadblocks to GUI harmony).
Got time? Spend some of it coding or testing
I have a client using MS-SQL server replication, and AFAICT (they've never had a serious need to failover or replay) it works for them, but it sucks. It just gobbles the bandwidth even when you're doing bugger-all, and occasionally has an absolute traffic frenzy. It's also a pain in the ass to set up, and occasionally shuts down without bothering to mention this little fact to anyone.
Got time? Spend some of it coding or testing
What did you do exactly? I've seen that in the server logs a few times, but can't figure out how people manage to make that error come up. Thanks
Since you are a consultant that, appearantly, handles multiple clients of this scale (~$25 - $50K) I would suggest that you did some background project work (after solving this issue, of course) to broaden your company's skillset.
Yes, .Net/MSSQL/Java can scale. A single box, however, is a bad idea. MS technology has a lot of trouble stepping on other MS technology from a resource perspective. Let's just call it a legacy issue that started around Windows 2.0 and hasn't been fixed yet.
To get the scale, you're going to have to split the tasks. n-tier was suggested. It's a good idea. A single box to run SQL Server is a must. Another box to run the proxy/web interface is another must. (splitting the proxy out can also be a big plus, if you can afford it.)
I seriously recommend against an IIS-based front end on the web, though. The security is just too darned loose. (Apache security and PHP scripting can be tied into .net/MSSQL, if you were wondering.)
Another thing on MSSQL, it is slow. A lot of memory tweeking will be needed to get the responsiveness you need. Also, consider spliting the load with some well placed replication. Replication can slow down a single box, but, if designed properly, different tasks can be split between specialized boxes to bring up the overall site speed.
Lastly (at least on the Microsoft as a solution answer), you can use relatively cheap boxes as long as MS supports them and there are plenty of custom hardware speedups for the specific Motherboard/chipset/Raid array, etc... A generic, off-the-shelf box, without this will be slow as a two legged dog.
Now, on to the future. As you can see, a properly configured MS solution takes just as much tweeking (sometimes much more) than a well placed *nix solution. The biggest trouble that I have encountered is that with all the pretty windows, most of the really necessary tweeks are hidden in registry values or other places and hidden from view. There is not a standard (or even safe) way to reach the most necessary tweeks for a heavily used system.
The *nix/OSS side of things are a little better. Sure, you probably don't know the environment, maybe not even at all. The transition from NT to 2000 or 2000 to .Net is just as difficult.
In a *nix world, most everything is found in a text-based config file. You make a change and restart an individual or group of services instead of the whole box. Occasionally, during heavy config, you'll want to restart the box to make sure that your changes will start up correctly the next time the box boots. Sometimes you need to compile an app to tweek it. Once you get the hang of it, it's not really a big deal.
Managing the box is a matter of learning about the system, setting up and checking the various health and security monitoring pieces, and everything else that you already know how to do, just a little bit different.
A cheaply set up OSS group of boxes (penguin has preconfigured dual operon rack systems for about $2,500 right now) can fly into some extreamly high numbers of trx per second.
Slashdot has a cool setup, if you can use the technique, where most dynamic pages are dumped to static files and cached for 60 seconds (I think). The next hit, after the set time, rebuilds the static file from the database and, viola, recaches. It works, since static cached is hugely faster than dynamic. If you can come up with dynamic content that you can afford to static every 60, 30, or maybe 120 seconds, do it. This will even help out in a MSSQL environment.
Basically, you need to sharpen up on the OSS side of things so that you can have a few "drop in place" solutions for your clients. OSS does cost less and, if you set it up right, usually takes around a third less
--==-- I've found Karma to be a relative thing... Ya know, the kind you invite to Christmas...
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 don't know about bi-directional replication, but I can tell you that having one "master" server to which all writes go, and replicating out to many read-only databases works VERY well with SQL2000. My company solved some serious performance and locking issues by cleaning up our data flows and implementing replication.
This is obviously not appropriate for everyone, but in my experience, most web apps tend to involve substantially more reading than writing. Without more details on your situation, I don't know if it would be a help -- but it seems like its targeted a bit more toward the "high end".
With regards to reliability, it is possible to cluster SQL servers -- we have also had mostly good experiences with this. We had major problems when we first tried, but several SPs/patches later things are working very well.
You don't need to do that: VNC has a Java client built-in, you can run it in any browser that has a half-decent Java VM (inc. Microsoft's).
To access this Java client, you simply have to point your browser to http://myserver.foo:5800/ ..and you're off!
hth
However you have introduced several different technologies that have been put under the singular heading as "DOT NET". SQL server has not been Dot Netiezed just yet. SQL server is scales very well on 8-16 cpu configurations. I assume you are talking about asp.net when you are comparing web services to asp/html "Static" pages. ASP.NET is much faster in my experiance because it is compiled rather than interpreted as in the case of classic asp. .net has good price /performance on lower end server/workstations. I really don't know if that was Microsofts real target with DOT NET. They were trying to make it a Java/ IBM/SUn killer. Thats where the biggest profit margins are. In most cases there are some special tricks improve scalability of apps. It a number of cases it depends on how you code it. Good Luck!
I guess your question really is wheather or not
Well.. maybe. Or Maybe not. But Definitely not sort of.
Actually, I'd have to say this is not true. There is such a laughablly low demand for co-lo (find me a colo that doesn't have a bunch of empty space) that you can get as much space as you need for whatever you're willing to pay for it.
Sure, approaching schmucks like Exodus and Rackspace.com will cost you tremendously. But there are other (less advertised) facilities that have been sitting completely empty for years now.
And this is assuming there's a real need to colo everything. Several dozen mid-tower sized desktop "servers" will fit perfectly in the space of one office cubicle. The bandwidth requirements haven't been provided, but I'd assume a T1 or two would be sufficient.
I've designed and written a few .NET apps, and have found them to have extremely good performance ("performance" here always refers to both scalability and snappy single-user response times) on low-end boxes, expecially compared to ASP and JSP.
.NET apps. Heck, for a couple of those apps., the team hardly even touched a whiteboard, but just sat down and started rapping out code using good old-fashioned common sense. In my book, follow the KISS principle for .NET apps. whenever possible for architecture and you'll come out way ahead in almost every aspect of performance, time to market, maintainability, etc. Take it from someone who almost blew a multi-million dollar project because of "over-architecting" the application. We got things working fine, but I lossed a lot of stomach lining over the deal, and the customer wasn't too pleased either. Before I jump off of the soapbox on the arch. issue, I always try to remember that just one often used part of an app. can kill scalability, and a complex arch. always makes the bottleneck a lot harder to find and often to fix w/o a re-write.
.NET runtime removes this burden as long as you don't have to jump through coding hoops to wrap dependent updates, etc.
.NET IDE installation is fine for most) of the parts of the app. that update the DB and test with different isolation level settings. As long as rule # 1 is followed, this has been the single most important factor in maximizing the scalability of transaction applications, and the default setting for this usually doesn't give the best results.
There have been a couple of posts w.r.t. proper architecture... While arch. is no doubt important, I've found that it is not hard at all to get good perf. out of even a minimal expenditure on arch. for
Here's where I've found the bottlenecks and easy ways to solve them:
1) Don't put SOAP calls in tight loops . If you seem to have to do this, redesign things. This may seem obvious, but the reason SOAP doesn't really scale well on any platform is because of the function call overhead, so minimize that as much as possible. Make sure to cache results local to the caller for stuff that doesn't change very often (see #4 below).
2) For DB updates, use SqlConnection transaction handling instead of MTS whenever possible. In the old ASP/COM+ world, it was imperitive to use MTS so you could take advantage of the other COM+ features, but the
3) Make sure to use the correct transaction isolation level for your transactions. For highly transactional apps. that also do lookups on the updated tables, the one I've had the best luck with is IsolationLevel.RepeatableRead. I can't stress the importance of this enough - do some rudimentary testing (Microsoft ACT that comes with the
4) Use HttpContext.Current.Cache and related in your code to cache stuff that doesn't change too often (like product description lookups, etc.), especially for SOAP calls.
5) Adjust the "Minimum query plan threshold for considering queries for parallel execution (cost estimate)" once you move your app. to an SMP system, depending on if the DB server is standalone and how highly normalized the database is. For a highly normalized DB (lots of JOINs) on a standalone SQL Server box, set this at 0 or 1 because most of your queries could probably benefit from a parallel execution plan, or at least the small extra overhead won't really hurt. This setting alone dramatically and immediately boosted the performance of one application and took all of 2 minutes to implement.
6) Make sure to apply indexes where it makes sense. For example, on one app. 4 hours of query research and index tunning based on that provided a 10 fold better response time for one query, which probably increased scaleability for that database by 100 fold because of how often that query was used.
7) Read and follow this simple advice for SQL Server clustered indexes on MSDN:
While I prefer free and/or Java-based solutions, much of my current work involves Microsoft tools, and I can assure you that they will support more than 100 concurrent users IF you architect and design appropriately.
If it doesn't, then my first suggestion is to profile your app and figure out where the bottleneck is occurring. This will help determine where to look for the real source of the problem.
I am guessing that you're dealing with some combination of (a) locking, concurrency, or transaction isolation issues with your database, or (b) passing information, such as state, unnecessarily between tiers. Either problem tends to manifest itself first during load testing, typically as a performance curve that approaches O(n^2) or worse. It usually is the fault of the design, not the tool, and if so, then porting the app to a stronger toolset or beefier hardware would not improve the situation very much. On the other hand, profiling should show you exactly where performance-related optimizations need to occur.
Nonaggression works!
Hi,
.NET based systems, and we encountered the sorts of scalability issues you are talking about. Few things come to mind:
.NET although it is vastly better than COM+. We achieved some relief by playing with settings in machine config such as minimum number of HTTP Run time thingames, MaxWorkerThreads and MaxConnections etc. If you haven't tuned these then you may get some good mileage out of doing this. With IIS and .NET being single process multi-threaded these basically control things like how many .NET threads you run, how many connections are allowed of the box etc.
.NET servers. That being said, our strategy was to use 1RU dual CPU boxes and scale sideways.
;-) HTH.
I don't know whether anyone has posted this sort of info, and sorry, just didn't have the patience to wade through all the holier than though posts.
I recently finished up working with a government department which was deploying a number of
1. We often encountered issues with threading under
2. MSMQ seems to behave badly under high load. I don't know what to suggest in its place, but it ain't a great story.
3. With tuning we did find we could get pretty good CPU utilisation and prtty good throughput out of our front end
4. The behaviour of our system relied on back end systems. Under test conditions, when the back end systems were stubbed, throughput was good. However, under real conditions, were back end performance was abysmal (think MSMQ being used for calls to Mainframe etc) we found that behavrour could be unreliable - read long blocking calls seem to be a bit of a problem.
5. Other things we tunned included IIS (that stupid slider thing tends to give you 10% if moved to maximum) as well as the new connections buffer (all this stuff is in KB somewhere, and I guess you have done it).
6. Another seemingly not well known trick is increasing the number of user TCP ports. For some reason the default with W2K is only up to approximately port number 5000 is available for outbound connections (ie, you got some sort of soap middleware server listening on port 80, connections to it are 4998->80,4999->80,5000->80,OMG, I'm a teapot. You can set this up to the maximum allowed ~65000. Also changing TCPTimedWaitDelay will mean that used number can become available faster. Once again all this stuff is in KB.
Now, all that being said, I'm afraid I think your clients have made the wrong choice getting the big box. For frontend boxes the way to go is mulitple frontend servers for sure. I personally don't think the MS single process multiple thread model is all that good, although it can be made to work at least reasonably hard. Oh, BTW, you'll need an MS license for each of those front end boxes
Thank you whole heartedly for pointing this out *AND* making it clear why. I love little bits of entamology(sp, too lazy to look it up :) )
Don't worry, someone else will do it for you, this is /. you're reading, after all. BTW, you've confused the term with this word.
Got time? Spend some of it coding or testing
I currently work for a company that has quite a few MySQL databases in production, dating back to '97. Currently we have 7 production MySQL database servers, each server during a 'typical' hour during a workday (they're only utilised 8 hours a day, it runs a business application) executes somewhere between 400,000 and 1,000,000 queries an hour (thats each server, total queries per hour would be around 3,500,000).
The only problem we've *ever* had with these machines have been hardware faults, or operating system level (they run linux) faults. Either disks going down or the entire machines going down.
Do you mean <i>"reliability"</i> has come about in in the last decade? or were you meaning the last one or two years? Because if you do mean its improved in the very recent past, I feel you should put less faith in off-hand anecdotal evidence.
A little overkill never hurt anybody.
Something doesn't add up.
Slashdot quality declines as the number of hot grits posts decreases. - Provolt's Law, Apr-09-2005
Since the original question related to handling 100+ concurrent requests, the service is likely an Internet-facing web site. In that arena, most companies do ditch Windows, even if they're using Exchange, etc. on their internal company servers. A "ditch Windows" answer is simply sharing the prevailing wisdom. If there's some reason why they can't ditch Windows in this situation, they should have said so in the question, since that's the obvious answer to expect.
"Moon is a harsh mistress" would be Heinlein book where TANSTAAFL originated.
Man, there's a lot talk here but no answers for your questions..
.Net has great performance, especially on Win2003, certainly more than you're citing with those benchmarks, but again, it's crucial that you're not running SQL Server on the same box.
.Net isn't just about web services, it's just designed to work very well with them. SOAP is not an ideal solution for anything except cross-platform and/or cross-country communication, and yes, best done async.
Are you actually running the SQL Server on the same box as IIS? If that's a constraint then you'll always be getting crappy performance. A database server and a web server are fundementally different in how they use a computer's resources, so you'll always be down a few points for doing this, regardless of platform.
Also, you seem to be citing some pretty high clock speeds for those crummy benchmarks. I'd just say that there's definately something wrong in the equation unless you're talking about the collective speed (all processors combined).
SOAP is a big performance drag, but I don't understand why you'd be using SOAP as a staple of your architecture if you've only one box to work with.
Here's an idea, depending on those constraints. If you only have one box to toy with, and your db activity is primarily read-instensive, consider using XML flat files for multiple small data repositories. Because we're just talking to the file system, and it's hierarchical, this trick proves to be quite fast if your data model is friendly to it. I'm not sure what you're doing or what your database is facilitating, but if it happens that you're activity is more write-intensive than read-intensive, you may be out of luck, especially if you're set on using a message queue between db and websvr.
Anyway, I do think you're numbers are a bit odd. I'd expect to get much better performance with the clock speeds you're citing. Consider keeping the database on the dual proc box and moving the web server to a cheap single and compare performance. Again, because you have such a slim margin for overhead, you'd better make _sure_ you optimize that SQL box with an expert's eye, and re-evaluate how and how often you're communicating between tiers (chatty vs. chunky). Anyway, maybe these are some things to think about.