October 21, 2002 at 9:05 am
About a year ago someone asked about SQL Server performance while processing XML but it seemed that there weren't too many people using XML with SQL Server yet. I imagine that there are more folks out there now using XML...
From a performance standpoint, is it better to push the data to an ASP or COM to turn it into XML, or to have SQL Server output the XML? We are about to begin working with XML output and don't know which way to go... Are there any other criteria we should be evaluating?
October 21, 2002 at 11:26 am
I've only been using XML with SQL Server 2K for a short time, but I've found that it definitely has some minor (in my case) performance disadvantages.
It all depends on what you will be doing with the data. In my case, I am posting a template query to IIS, which includes a reference to an XSL stylesheet that converts the XML to XHTML. For a query that is returning 8000 rows of data with 15 columns, the XSL transformation can take several seconds, whereas an ADO query in ASP takes noticeably less time.
Obviously this delay will vary depending on your hardware, network and recordset size.
XML is great.... but you should evaluate whether or not it is absolutely necessary for your application. If you are not actually using the XML for anything, why convert to it? Without a better understanding of how you are using the data, its hard to judge.
October 21, 2002 at 3:09 pm
I have done a detailed examination of the OPENXML for the book below, but not looked at the FOR XML part.
You can put the XML processing on the client side, but all sources I have seen have said this has no noticeable benefit. My first thinking is that removing unwanted processing from the server is sensible.
Simon Sabin
Co-author of SQL Server 2000 XML Distilled
http://www.amazon.co.uk/exec/obidos/ASIN/1904347088
Simon Sabin
SQL Server MVP
http://sqlblogcasts.com/blogs/simons
October 21, 2002 at 4:21 pm
I agree with Simonsabin. When you consider the scalability in Sql Server, comparing scalability in IIS, ANYTHING I can move off my Sql Servers is preferable if in fact there is little difference to the end user. I can tell you from experience that there is definately overhead incurred on the Sql Server with outputting XML. I couldn't speak to the overhead on the IIS system, but it scales much better, and cheaper.
If your not gonna help, Please move to the side, because if your not helping the situation, your hurting it....
October 22, 2002 at 2:32 am
To clarify out intent in using XML: we are hoping that the use of XML will help us with session time-outs when a user is filling out a lengthy form. Our hope is that if we can push an entire multi-part form down to the client, they can work on it at their leisure (as long as they don't close the browser). If their session has timed out, my understanding is that we can then redirect the user to re-login and then take them back to the ASP page to process the entire form as one. Otherwise, the user has to fill out a page of the form and then move on to the next page of the form, verify the entire entry and then submit before their session times out. Some of these forms involve 5-7 pages, so we have a time issue. We were also planning to use XSL for client-side validation. We are also hoping to reduce our overall number of trips back to the server. As long as the network can handle the one large initial package we should be okay. Lastly, our government client is moving toward XML for data transfer between websites.
My main question was whether to have the XML constructed on the ASP side or on the SQL Server side...but, given the above scenario, is this sound thinking at all?
October 22, 2002 at 8:43 am
Have you extended the Session timeout parameter in your global.asa file, or are you using the standard 20 minute timeout?
The timeout value is in minutes, so determine the longest time you'll need and extend it to that time. This assumes that your webserver can scale to handle all those active sessions of course.
You could simply *gasp* use cookies to store the logon info and user state at the time the session ends. Then load the info and allow the user to proceed when they reconnect...
Or you could create a hidden *gasp* frame that uses a META tag to refresh a few minutes before the Session timeout.
Your choice.
Andy
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply