[Mono-aspnet-list] mod_mono parallel requests dont’t run in parallel
grendel at twistedcode.net
Wed Oct 14 09:23:41 EDT 2009
> using jquery ($.get(..) ) I call 3 times the same ASP.NET MVC controller
> method in one go. Since the responses are handled asynchronously, the
> requests go out almost in parallel.
> I know they go off in parallel, because I pass in the client's current time
> as a parameter, but they seem to be processed (serverside) one after the
> other. To proof this, I response out the start and end time in my controller
> routine. In VS2008, using the little debug webserver, it works perfectly in
> parallel (same start time). But running mod_mono on Apache, I never get the
> calls to start in parallel.
> The processing of the individual calls takes some time (about a second to
> call an external sevice), so i can see the delay very clearly, i'm not
> talking about milliseconds.
> The user experience on the page is not very good, the user sees the
> returning data areas one after the other instead of building up
> We develop a public website, utilizing shopping apis from amazon,ebay etc.
> Setup: Mono 2.4.latest, Linux OpenSuse 11, Virtual Server, showing 4 cpus in
> cpuinfo, Apache (running worker MPM with high performance settings), hosted
> by a professional service.
Since they are separate requests, I don't see a reason they wouldn't be handled in parallel on a
4-way machine unless there's a lock held somewhere on the way which serializes them. It's impossible
to tell what's happening for sure without having sample code which exposes the issue. Please follow
http://mono-project.com/Bugs and file a bug report for the System.Web component with attached
simple, self-contained test case which reproduces the problem.
> Any ideas ? Is this something I have to worry about ? I do worry about
> scalibility in large, when all requests are handled one after the other..
> will it scale better if the request would come from different machines
> (users) ?
We have tested Mono's ASP.NET under very high load and it scaled pretty well. Our garbage collection
is not as good as we'd wish it to be, but overall the performance was more than satisfactory.
More information about the Mono-aspnet-list