Actually, speed is irrelevant to your problem. Your problem is entirely about caching.
You should look up caching in Wikipedia or someplace to learn more, but here's a capsule summary relevant for your situation. Often when you load a web page, you're not actually loading that page, but loading a copy of it someone has squirreled away from before. It happens all over the place. Your web browser does it. Your internet service provider might be doing it to control how much traffic goes over their wires (and limit costs related to sending traffic over the networks of other companies). Big websites do it to serve pages to users more quickly and efficiently.
It can be subtle and hard to detect, but usually it doesn't matter, unless you're trying to do something extremely time sensitive, like buying concert tickets. A web page with somebody's baby pictures isn't going to change every second (well, most of the time), so if you get the original or a copy some middleman has stashed away, you won't notice the difference.
As it happens, what you unintentionally did was set up an experiment exposing the seams in this scheme. By firing up two browsers, you cached the page twice: once in Firefox, and once in AOL. Each browser maintains an internal cache of the pages you read. Normally people don't know this is going on, because they only use one browser at a time, so when the browser fakes you out by serving a page from cache when you click "Reload", they're none the wiser. By starting two browsers, you got a second opinion.
Caching is done by giving every web page an expiration date. To make a long story short, there's a vagueness in the way the expiration date is defined which may allow different browsers to track expiration dates down to the minute or down to the second. Normally this would seem like a trivial distinction, but in your case it makes all the difference in the world.
I would like to offer my compliments to "Mr Ed" for suggesting Fasterfox, the Firefox add-on. I've given it a try and although I've just downloaded it and haven't tried ordering any tickets with it, it seems like it would do what you'd want it to do. It appears that FasterFox does a lot of stuff, most of its functionality like pre-loading hyperlinks won't help you with your ticket problem. It looks like your best options with Fasterfox are either to set it to "Turbo Charged" mode or to simply wipe your browser's cache with each load of whatever web page you're using to order tickets.
Actually, it would appear that even in Turbo Charged mode Fasterfox is still relying on its local browser cache, because if you pick a random static page on a site that's pretty far away and click "Reload" without wiping the cache each time, it runs faster than if you click "Reload", then click on Fasterfox logo and clear the cache, then click on "Reload" again. I believe that in this case for ticket ordering wiping the cache is better, because you're forcing the browser to hit that website every time.
It's worth remembering that this is actually very bad behavior under most circumstances. Caches are good. Your browser runs faster and things happen quicker. If you were to wipe your cache every time you hit any web page, web browsing would slow to a crawl. I can't overemphasize that ticket ordering is a situation that's very different from most web surfing, and the stuff I'm talking about here is only for use in specific situations, and not to be done all the time.
*** WARNING: GEEKINESS BELOW ***
If you really want to get into the technical nitty gritty behind what's going on, go to the World Wide Web consortium and read up on the HyperText Transfer Protocol (HTTP). That's the way browsers and web servers talk to each other and get web pages. You can get that from the World Wid Web Consortium website (http://www.w3.org) or you can get the RFC from the Internet Engineering Task Force, the folks generally responsible for all the Internet standards.
In particular, whenever a browser asks for a web page, it will make requests and include various options in what are called "headers", like in email. In fact, they're formatted just like email headers. Whenever a server delivers a page, it uses headers as well. It's in a document with the boring sounding name of RFC 2616. The headers you're interested in are the "Cache-Control" and "Expires" headers. Particularly the "Expires" header, because that's the expiration date I'm talking about.
If you read the document, in section 3.3.1 on page 20 you'll find a definition of HTTP date formats, and in there time is always defined down to the second. However, when you go down to section 14.21 covering the "Expires" header, it says:
"The format is an absolute date and time as defined by HTTP-date in section 3.3.1; it MUST be in RFC 1123 date format"
If you go look for RFC 1123, it's actually a general requirements document describing basic requirements for Internet hosts. It doesn't cover HTTP, but it does cover a number of other protocols including email. If you dig around in the email specs (RFC 822), you'll find a much looser definition of the date, which allows either two- for four-digit years as well as time defined either as just hours and minutes or hours and minutes and seconds. Section 5.2.14 of RFC 1123 tightens up this definition, which is my guess as the reason for the citation. However, that tightening of the definition is limited to the year (it has to be four digits long), but says nothing about the date.
What does all this mean? Basically, it's technically legal for web caches to store expiration dates down to the minute or down to the second. That may sound like a pedantically useless distinction, and it almost always is. However, when you're buying tickets, things change a bit. Consider the following scenario: Your web page has an expiration time of 12:00. Browser A at 11:59:16 says: "The web page expires at 12:00, so I need to go back in one minute, or sixty seconds." Browser B at 11:59:32 says: "The web page expires at 12:00:00, so I need to go back in 28 seconds." The poor soul using Browser A checked first, but will end up waiting longer.
It's hard to know exactly what happened, but my guess is that caching is your most likely culprit.
2007-02-19 03:53:43
·
answer #1
·
answered by Ralph S 3
·
0⤊
0⤋