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

[Marek Habersack]

On Wed, 22 Nov 2006 23:10:52 +0100, Marek Habersack
<grendel at caudium.net> scribbled:

> On Wed, 22 Nov 2006 16:49:49 -0500, Miguel de Icaza
> <miguel at ximian.com> scribbled:
> 
> [snip]
> >     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.
> ASP.NET 2 uses XML-based Browser database stored by MS.NET in a
> subdirectory of its CONFIG folder, browser.ini being deprecated. Also,
> the user can put .browser files (utilizing the same XML format) in
> ~/App_Browsers and they get compiled whenever the application is
> loaded. I plan to work on support for the App_Browsers and the XML
> definition files in the near future. Since the definition files are
> loaded once during the application startup and whenever a change to
> any of the definition files is detected the app is reloaded, we can
> cache the database in HttpApplicationFactory.InitType at the cost of
> using some more memory. We could keep them in a (generic) SortedList
> and populate in such a way where we would not use any wildcard/regex
> matches, just full string match. That would probably increase the
> performance dramatically.
To make the description less chaotic, here's what I was thinking about
implementing the support. The XML files that define browsers are pretty
complex, but in general, they rely on regular expressions. During the
application startup time we'd compile all the expressions, store them
in some structure (it would need to be hierarchic, since browser
matching can be nested) and set up an ApplicationDomain-wide cache for
already matched browser UAs. The UA cache could be a SortedList,
and we would use the full UAs to look up the browser capabilities. That
way, as the browsers visit the site, the cache would provide
faster access to the capabilities, until the application would have to
be restarted. It would certainly be some improvement.
Of course, finding out how to avoid loading the database every time
would be the best improvement.

best regards,

marek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20061122/96859569/attachment.bin