February 13, 2006 at 1:35 pm
My question arose from reading this article on the asp.net PRO site:
Writing Scalable AJAX Web Applications
The article is about optimizing your site and page design for AJAX applications, where each page may generate multiple asynchronous requests as opposed to standard web pages which are processed synchronously as a single request for each page. The authors offer a few tips for optimizing performance, since any inefficiencies will be mutliplied across multiple requests for each page. The first suggestion is to implement a custom HttpHandler class to return only the necessary XML for the AJAX request instead of using a full .aspx page. Next the authors talk about using a single XML file as the datasource, and for each request the handler loads the XML file into an XMLDocument, which results in "an abysmal 25 Requests per Second (RPS) being served up" using Microsoft Application Center Test (ACT). They then replace the XML file with an XMLDocument loaded into the application cache, which improves the same ACT test from 25 RPS to 300 RPS. This is a very impressive improvement in application performance!
My question, though, is if anyone has tried testing this scenario against using a SQL datasource. What is affecting performance the most? Is it the actual file I/O process of reading the XML file from the disk, which is much slower than accessing data stored in memory? Is it because of file locking, which would cause requests to be processed synchronously, thus losing all the efficiency of asynchronous calls which is one of the primary benefits of AJAX? Or is it the overhead of reading the XML data into an XMLDocument?
This could have serious performance implications for developers creating sites which implement AJAX (or any similar asynchronous, XML-based framework). Does a sitemap (or other similar data) stored in the application cache as an XMLDocument perform better than querying a database? What about the new SQL Server 2005 feature of native XML content as a field type? Does that eliminate the overhead of reading the data into an XMLDocument? If so, that would be a strong argument for replacing text/varchar fields with xml fields in your database design wherever possible. And if there's any processing required on the XML data, is it more efficient to do the processing on the database server in the query, or on the web server using your application? I haven't had enough experience yet with SQL Server 2005 to answer these questions myself, so was hoping to get feedback from those who have.
February 14, 2006 at 4:33 am
Not specifically AJAX related, but I saw some similar issues with our application.
I think the core of the problem is that the microsoft XML document manipulation routines are relatively slow. Most of the speedup issues you mention are due to not having to build up and parse the XML document on every page load.
Initially, our app got a datatable from the database and manually build up the XML document (adding nodes, etc). We switched this to having the database return an XML document (using the FOR XML directive) and noticed a large increase in performance.
My guess would be that the disk IO has very little to do with it, and most of the overhead is in the conversion of the XML text stream into an XMLDocument.
Just my $0.02
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply