Hi all,
Been looking at this thread very briefly but there was something that stuck in my mind - you mentioned that you were struggling at around 10 concurrent users?
I remember a few months back I saw a similar problem in our own heavy Ext.NET 1.x solution. It turned in our case to be the use of session. In particular, our components use ASHX ajax requests for grid and similar components. The ASHXs that were handling the requests for grid data use IRequireSessionState. This turned out to kill performance/throughput.
IIRC, any request to a page that requires session state is effectively serialized. So all the grid ashx requests to get data (let alone updating data) were all being blocked from one another because of access to session state. Refactoring to not require session state for these requests increased throughput significantly.
I can't remember exactly the number (and it depends on the application of course) but from a limit of 10 or so requests as a maximum it went up to hundreds. In our particular case, I was also able to implement server side data request caching, so we could effectively get 1000s of requests per second being handled, at low concurrency load tests, like 5 or 10 concurrent users being simulated. I can't remember what it was for higher concurrent users. I'll try to dig out the information - it has been a few months...!
Although in my case it was using ASHX for direct methods, Grid/Store requests etc, I think this could apply to most ASP.NET applications, though you would need to test to verify. I recently compared using ASHX vs ASP.NET MVC Controllers vs ASP.NET Web API for DirectMethods and Grid Store handling and found they were all similar in performance - none of them required session, for example, and in effect they were pure AJAX requests, not DirectEvents or ASP.NET Web Form event/post backs etc. More info here:
http://www.onenaught.com/posts/559/e...eb-api-or-ashx Although unfortunately no code samples, as I suppose it also depends on your specific application requirements and functionality.
My preference to developing Ext.NET apps is to have the page request build whatever Ext.NET components are needed, but virtually everything else (getting data, adding components directly onto the page dynamically etc etc) is all done via AJAX (ASHX in Ext.NET 1.x but increasingly MVC as I port my app to Ext.NET 3.x). The other thing, if at all possible is to cache, cache, cache (if cache invalidation is feasible - that can be hard!).
In terms of hardware, I used Windows Server 2012, SQL Server on the same box (as it was my own dev box), with quad core processors, and about 16gb ram. So I think in a production environment our throughput is even higher. But a lot of this I suppose depends on your specific application and what it is trying to do?
What might be a good thing to try is to isolate the problem: for example, maybe try to create a standalone page or cut down application that is independent of your current solution to mimic the core of your functionality that seems to suffer, to help isolate it from everything else, and try to load test that. Perhaps the code for such a page can be posted here so that others can also analyse?
In terms of what load testing tools to use. I think anything with reasonable pedigree should be okay. In my case I used WestWind's WebSurge load test tool:
http://websurge.west-wind.com/ - it has a nice interface to capture/tweak the requests you want to measure and load test.
If I can find some time this week (might be tough with some deadlines looking), maybe I will try to use it to run through some of the examples in the Examples Explorer for 1.x...?
Otherwise, without knowing more about how your app works, it could be anything... Either Ext.NET or not...
I don't know if that is much help...?
