XML HTTP Performance and Caching
XML HTTP has gotten a lot of press lately, largely due to Google’s decision to use it for Google Suggest, among other things. Which in turn has generated a lot of attention and led to a quite rapid adoption.
It’s even spun a new term, Ajax - which I for one believe is quite silly as there is nothing new about it (and I’m obliviously not alone).
Microsoft first introduced XML HTTP in Internet Explorer 5.0, and Mozilla has supported it for quite some time now.
Over at WebFX we’ve been using it since late 2001, when Erik unleashed the xTree extension xLoadTree that fetches the content of folders as they are expanded.
Never the less it’s exciting to see all new the functionality that’s made possible using it, not to mention how it can be applied to enhance the user experience by creating a more responsive, more interactive, interface.
More then anything XML HTTP has enabled developers to make background HTTP requests a lot easier, and a lot faster. It does, however, raise a whole lot of questions; How much faster? Is it always faster? How about caching?
I’ve been asking myself those questions for some time and finally decided that it should be fairly easy to determine with a few simple tests.
What to test?
The basic question I wanted to answer was ‘How fast is XML HTTP compared to regular requests?’. Before XML HTTP was introduced the most popular way to make a background http request was to use a hidden frame or a hidden iframe. So thats what I tested it against. To make it more interesting I also decided to do all tests both in Internet Explorer and in Mozilla Firefox to see how their implementations compared to each other.
I also wanted to test if XML HTTP requests where cached, and thus decided to run each test twice, once where I would repeatedly request the same file and one where I would request unique files. If the files where cached the first run would complete much faster (as only the first request would actually be processed) but if they where not both would take about the same amount of time.
To further see the effect of caching I decided to run all test three times, with different sized files, as caching is most beneficial for large files.
Running the test
I created a script that would request a file first using XML HTTP in asynchronous mode, then in synchronous mode and finally using a hidden Iframe. Each file would be requested ten times and the average value would be returned. The same test would then be executed again, but with ten unique files instead of ten identical ones, to measure the effect of browser caching.
All those test where executed with three different files, a small 1 kB file, a 10 kB one and a fairly large 100 kB file, and they where repeated five times, taking the average value from all runs.
Results
The tables below show the number of milliseconds per request for the different request methods. Its the average value computed by dividing the total execution time by the number of requests.
Conclusions
This clearly demonstrates that XML HTTP is a lot faster than using a hidden iframe for small requests, most likely due to less overhead. As the filesize is increased the advantage obviously shrinks, as the majority of the time is spent transferring the data instead of handling the request.
Another thing that can be seen is that Mozilla does not cache the data received using XML HTTP, explaining why the classic iframe method is so much faster for large files in Mozilla.
Internet Explorer on the other hand caches data received using XML HTTP in synchronous mode, but not in asynchronous mode, which is some what surprising.
Notes
All tests performed over a 512 kb dsl line. The script used is available upon request.
Internet Explorer version 6.0 sp2 and Mozilla Firefox 1.0.2 where used for all tests, both under Windows XP.
The stylish graphs where created by Jakob at Neod, they look so much better than anything I would have been able to produce, thanks!
扫一扫
2209
到【灌水乐园】发言
April 3rd, 2005 at 03:14
Hi there,
Intressting test, really. Though there are some concerns that should be enlightened, and in my opinion the comparison isn’t in right context. Correct me if I am wrong:
1. There are overhead in IE that makes it perhaps slower but the speed is gained when scripting. The XML Dom in IE is much more powerfull in than FF, because IE validates and creates DOM immediatelly. And the data is scriptable. Methods like SelectSingleNode and SelectNodes are embedded, which are very powerfull when scripting against XML. Now in FF, I haven’t found any signs that this is supported. The only solution is to create these methods by script, this is doable but to what performance cost? Very high, especially when handling bigger data files as in your test.
The API in FF reminds more of an event based API rather then DOM based API, which may explain the speed. But than again, the performance is lost when scripting against it. Downloading data is meaningless without “working” with it. Which is what, if I understand your test correctly, your test prooves: FF gets it faster…but thats it.
2. Exploring data in the API is very painful in FF, and each node has to be tested, otherwise calls will produce errors. The DOM in IE is more straightforward.
3. For me, so far IE hasn’t cached data in synchronous mode, Which I hoped it would but it haven’t…
Now I am not pro or anti IE, but there are features that doesnt get correct recognition. The scripting engine is superior in FF but as in IE, with the good, the bad follows…
Sincerely,
/hbi
April 3rd, 2005 at 22:38
I always considered iframe loading to be asynchronous.
Håkan: Mozilla supports the DOM3 XPath module which is actually more powerful than MSXML. Any XPath result can be returned, not only DOM nodes. It is fairly trivial to implement selectNodes and selectSingleNode in both XML and HTML DOMs. Another downside here is that the COM bridge in IE is a lot slower than Mozilla’s XPCOM. I’ve created a js script that reads about a meg of XML and generates about a meg of js code and it realy brings IE and WSH to its knees (more than 20 minutes in MSXML/JScript compared to a few seconds in Mozilla).
April 4th, 2005 at 17:48
Erik: For this test I implemented a very simple iframe loader that used a single frame only, and thus where unable to process multiple parallel requests; thats why I’ve (somewhat incorrectly) labeled it synchronous.
Håkan: The question I tried to answer here was simply how fast xml http is compared to other means of receiving data, and as such it does not take the processing time into account (as that would be pretty much constant, no matter how the data was received). The speed advantage mozilla showed over internet explorer for asynchronous xml http requests is negligible, and in all other tests internet explorer has the advantage.
What took my be surprise was the caching, or lack there of. IE caching synchronous but not asynchronous requests struck me as especially odd. Somehow I expected mozilla to cache xml http, as it’s implemented as a part of the browser, and ie not to, as it’s implemented as an external activex component, but that proved to be an incorrect assumption.
April 4th, 2005 at 20:13
Hey there,
About the iframe loading; No doubt, I have never claimed otherwise. Iframe loading is asynchronous. This is what Emil writes:
“Internet Explorer on the other hand caches data received using XML HTTP in synchronous mode, but not in asynchronous mode…”
How did he accomplish this?
I am not the best programmer but I try to monitor my solutions performances. Challenger for instance, when loaded, the Memory Usage is less than even this blog and a little higher than when FF starts up (with no default url). Open and close windows in Challenger and monitor the usage. In my opinon, there is differense on scripting for the web and low-level programming. I think applying low-level programming fashion in webcontext is totally wrong and it does result in poor performance.
I dont think the selectNodes-function is that trivial. See, that was my first thought too, but really its not that trivial. Firefox scriptengine is great but now I will test it myself. The test will read and outputt 10 RSS-feeds. Both IE and FF must manage feeds independently feed-verion. For this, I will write a selectNodes function but I am instressted in your trivial-solution.
Emil,
Your test, did it inlcude posting files? Because I am intressted in how the performance is compared between XML Http and Iframes. If not, perhaps some addition to your test script can illuminate some performance differences.
Until next time, best regards,
hbi
April 4th, 2005 at 23:18
We did an MSXML emulation for Mozilla in Bindows.
There is a project on source forge that does something similar called Sarissa.
April 6th, 2005 at 09:22
Håkan: I tested GET operations only. I could, however, run them again, using POST, if you’re interested in that…
April 7th, 2005 at 13:28
Hi,
I am very intressted and I’ll owe you one.
Tia,
hbi
April 14th, 2005 at 00:45
Hey guys,
I am interested with the test scripts used in these tests.
Could you send me the files in your spare time?
Thanks in advance.
April 21st, 2005 at 15:38
I was trying to use this method to set several session variables, and ran into what I considered a caching issue in IE (while using either synchronous or asynchronous mode). (Of course its more than possible that the issue is my understanding of the way IE caches its pages).
When passing “new”(having not been called before) URL variables to the page via the XMLHTTP object it works as expected in both browsers (with the server side variables being set up correctly). As soon as you start to duplicate calls to the page with the same URL variables IE begins to return information from a cached version rather than by requerying the page. Trying to find a solution to this led me to your page and the asynchronous/synchronous issue. I’m going to run some more tests on this to verify the issue, but I was just curious if you had run into this even with asynchronous mode?
-james
April 22nd, 2005 at 08:56
James: The behavior your describing coincides with my results for synchronous requests, in internet explorer; If the same URI is requested multiple times it’s taken from the cache, and it doesn’t even bother to do a conditional request (a GET with the If-Modified-Since or If-None-Match header).
This is not something XML HTTP specific, IE is known to cache things a bit too aggressively at times.
The simplest solution that guarantees all requests to be processed, rather than served by the cache, is to make them unique, for instance by appending a sequence number or a timestamp.
I have not observed this behavior for asyncronous requests however, actually I havn’t been able to get IE to cache those requests at all, even when desired.
June 15th, 2005 at 06:32
I know this is an old thread but as regards the cache issue, I have found that sending no-cache headers is quite effective. Using the appropriate etiquette (line-feeds, etc), printing to the server headers: “Expires: Tue, 25 Jan 2000 12:00:00 GMT”, “Last-Modified: (current
time) ”, ”Cache-Control: no-cache”, “Pragma: no-cache” works for me on Apache/IE. Incorrect server headers are a problem in many areas unless you send them explicitly…
June 15th, 2005 at 06:41
Emil said: “The simplest solution that guarantees all requests to be processed, rather than served by the cache, is to make them unique, for instance by appending a sequence number or a timestamp” …. the point of my previous post being in my experience appeasing IE one needn’t fill the cache with things which shouldn’t be cached if the correct headers are sent in the first place- does this work in all browsers? As far I’ve seen.
June 15th, 2005 at 09:18
john: You are absolutely correct, all modern browsers seem to respect the cache and last modified headers, however many proxies don’t, and unfortunately many of us are behind proxies
Another, perhaps more obvious, solution is to use POST, as post requests cannot , per the specification, be cached, and most browsers and proxies seems to adhere to that.
September 5th, 2005 at 18:40
Here’s my implymentation of selectNodes and selectSingleNode of Firefox / Mozilla
url : http://km0ti0n.blunted.co.uk/mozXPath/
October 13th, 2005 at 17:25
Benchmarking XHR vs. IFRAME, and a Neat Hack
Now that so many toolkits abstract away the transport used to make Ajaxian requests, one might wonder whether it matters if XHR or a hidden IFRAME is used to communicate with a server. Emil Eklund tackled that question way back…
February 28th, 2006 at 07:32
[…] On the other hand you can achieve highly interactive rich web applications that are responsive and appear really fast. While it is debatable as to whether an AJAX based application is really faster, the user feels a sense of immediacy because they are given active feedback while data is exchanged in the background. If you are an early adopter and can handle the browser compatibility issues, and are willing to learn some more skills, then AJAX is for you. It may be prudent to start off AJAX-ifying a small portion or component of your application first. We all love technology, but just remember the purpose of AJAX is to enhance your user’s experience and not hinder it. […]
April 13th, 2006 at 00:38
Hi. I have one problem with xml & flash. I use xml to display only text in flash file. But when i put this files on my ftp server and second time when i make some changes on that text in xml, my browsvers: IE, Mozila and Opera read my old xml file from cache. No from ftp server. Please for help.
May 25th, 2006 at 10:19
Nice Post!
never tested with such scripts, but surely would be interseted in having them and runnning on my programs.
Thanks in advance.
~Shaurabh Bharti
June 12th, 2006 at 22:21
Does your test script do the asynchronous XMLHttpRequests in sequence, each one waiting for the previous one to complete (readyState == 4) before starting the next?
I ask because if there is overlap, that would defeat caching and that would explain IE appearing to cache only synchronous requests.
Even if you wait for readyState == 4, maybe IE takes a short time to commit the received file to cache. Adding a fixed time delay after readyState == 4 would check for that.
June 12th, 2006 at 22:38
Jamie Lokier > It did, there was a 10 ms delay between the requests.
June 22nd, 2006 at 13:34
Listing A—read2array method of BigFileReader.java
/**
* Reads a file storing intermediate data into an array.
* @param file the file to be read
* @return a file data
*/
public byte[] read2array(String file) throws Exception {
InputStream in = null;
byte[] out = new byte[0];
try{
in = new BufferedInputStream(new FileInputStream(file));
// the length of a buffer can vary
int bufLen = 20000*1024;
byte[] buf = new byte[bufLen];
byte[] tmp = null;
int len = 0;
while((len = in.read(buf,0,bufLen)) != -1){
// extend array
tmp = new byte[out.length + len];
// copy data
System.arraycopy(out,0,tmp,0,out.length);
System.arraycopy(buf,0,tmp,out.length,len);
out = tmp;
tmp = null;
}
}finally{
// always close the stream
if (in != null) try{ in.close();}catch (Exception e){}
}
return out;
}
July 15th, 2006 at 07:49
The reason that synchronous use of XMLHTTP successfully checks the cache may be due to event bubbling within the IE engine. On a synchronous call IE is free to take it’s time for request 1 before going on to request 2. At the beginning of request 2, request 1 has fully completed, and request 2 processing takes this into account.
August 17th, 2006 at 20:59
Hi there,
Great article have you wrotten Emil. But by now, i do have a question about your testing case, specially at Firefox browser: I have trying to make a synchronous post request to server side - using XMLHTTPRequest object -, but at this browser, it is bugy, as a have looking at the web and found some information on Bugzilla site [bug id 313646]. So, how do you passthru this issue?
Best regards,
Fernando