[Mono-dev] ASP.NET 2.0 performance discussion.

Miguel de Icaza miguel at ximian.com
Wed Nov 22 16:49:49 EST 2006


Hello,

    The other day we were looking at ASP.NET 2 vs ASP.NET performance
and we found that the difference is quite significant, our 2.x
implementation has some severe problems.

    All of this data is slower than it should be, since we were using
heap-shot (which the larger the memory consumed, the slower it would
make a process as well).

    With empty.ashx handler, we get:

	xsp: 	1252 requests per second
	xsp2:	 595 requests per second

    For a page that contains a form (session1.aspx in the samples) the
values are (this is using automatic event wiring).

	xsp:	697 requests per second
	xsp2: 	182 requests per second

    Gonzalo and myself found a few guilty components thanks to Lluis'
heap-shot tool.   A large part of the problem is that in our ASP.NET 2.0
code path, we *always* load the Http Capabilities database, because code
in HtmlForm.cs wants to determine whether to send back java script or
not.  
 
    All of the above is considering that the User Agent for ApacheBench
is not registered.   After we register UserAgent into the browscap.ini
file, we go from 182 requests per second to 332, this is by adding the
ApacheBench to the top.

    So we could improve things in a few ways:

	* We should remove the current text-based browser capabilities
	  from the system, and instead use some sort of binary format
	  that optimizes the lookup for common browser.

	  We could also avoid using System.RegularExpressions as
	  the browscaps ini just has DOS-like expressions, and we 
	  could use a lighter edition of this code.
	  
	* If we do not need to send Javascript (we do this lookup
	  always, but we could not do it, based on three booleans in
	  HtmlForm), we could save ourselves getting the capabilities
	  database each time.

     Even with this, we are still not up to the same speed levels as we
were with 1.0, and we need further research into why.

Miguel.



More information about the Mono-devel-list mailing list