To view parent comment, click here.
To read all comments associated with this story, please click here.
I'm not sure that's a valid comparison. The application I spoke of was *quite* large and had several very complicated features requiring some very gnarly SQL to perform. One might say there was a design problem but as w/ all RDBMS-based solutions - you can't constantly change your data-model to adapt to every use-case as the system grows and changes in use.
Eventually we moved some of the features that turned out to be *mostly* read-only and that had very large queries to Crystal Reports, leaving the editing features in place. The performance increased considerably on those features. At the warehouse there were several PocketPC based applications used to scan and track inventory - as the folks at the warehouse got busier and busier, the system dragged on even further...making the web users suffer even more.
I'm not sure you can compare the portal solution you mention w/ the application we dealt with - I'd dare say the complexity level was many times more in comparison.
Aside from performance problems, a system based on copious amounts of ADO.NET data-access code, stored procedures, and ASP.NET turned out to be highly resistent to change. It was not fun to change & maintain as it grew. However, these problems went away as we moved to an EJB3-based solution w/ JPA. It performs and changes can be made many times easier.




Member since:
2005-07-06
It slowed considerably w/ five users, ground to a halt at twelve and began failing w/ exceptions and/or timeouts.
Our current systems, built w/ Java EE handle this effortlessly...and after being stress-tested w/ JMeter...will effortlessly scale to dozens of users in a non-clustered environment (if not more.)
I dare to say that there was something wrong which was not dued to .NET. We have portals which are entirely DB-based (and hence, every access is multiple database queries) and can handle 2000/4000 users per day without any hassle and without bogging the machine down. That's is so true that we have them hosted in shared hosting plans.
While I don't know details so I cannot comment about your figures, 5 users or 12 users is way too low (and while SQL2000 is not SQL2005, that's a Ent-level db solution).