A thousand to one is an impressive increase in performance. And at times it can be achieved in web based applications if you employ caching.
Let's say that a user asks about... current train running on our First Great Western Coffee Shop
site. They'll get a diagram like the one that's to the side here. Another user asks for the same information... gets the same diagram. Fair enough - it's not likely to have changed within a few seconds.
But the data for the original query isn't stored on our system - it's sourced from elsewhere such as Network Rail, and it's needlessly repetitive for it to be called up and recalculated, perhaps identically, for the second requester. And it's not just two people - I have 19 people looking at present, and it can rise to over a hundred people at times.
Best to get the information once and store it - "Cache" it - for a limited time - perhaps 2 or 3 minutes for this particular data set; perhaps half an hour for tomorrow's weather forecast, perhaps no more than 10 seconds for breaking news.
But where to store it? There are a number of places - staring from the user's end
1. Cache at browser
2. Squid / Varnish Cache
3. Page application - Front Cache (complete page)
4. Page application - Middle Cache (components)
5. Page application - Back cache (results from services)
6. Very Back end in service layer
Which of these should you use? Each / any / ALL are valid.
1. User's browsers store images and other data, and it's worthwhile signalling that an image or slowmoving page element doesn't need to be reloaded every time.
2. A Varnish or Squid server takes requests of the web server and stores a copy before sending out to the browser. It sits in front of your regular server or server farm, and means that identical
incoming requests can be answered with "one I prepared earlier". Code must be carefully written (and look up etags) to ensure that the request is identical not only in terms of URL, but also parameters, browser, cookies, and geographic region to ensure a correct feed
3. The web server main layer may also store a completed response just to resend it if required. Where there's load balancing / clustering, this may be less efficient that using Squid / Varnish as each system will have a copy
4. Intermediate calculations within the main layer that are useful from one request to the next may be stored.
5. Where you're pulling in a feed, store the feed results for an appropriate time... don't keep asking. Again, speeds things up / reduces work and requests. Also avoids irritating the feed supplier ;-)
6. And - subject for another day - there's the whole business of caching database responses / service layer responses too.
The graphic you saw at the top is generated from a feed that's cached in our server, and indeed we cache the completed image too - we're using (1), (3) and (5). And it's possible that (6) is in use too by our feed supplier. There may be a couple of minutes delay in the updates as we've got some quite long timings set, but it gives a pretty good general impression - telling me as I write that there's an issue with a train between Gatwick and Reading, but across the rest of the South West, no big problems. (written 2013-05-30, updated 2013-06-08)
Associated topics are indexed as below, or enter http://melksh.am/nnnn for individual articlesH307 - PHP - Web2 and caching 
Changing a screen saver from a web page (PHP, Perl, OSX) - (2008-05-06) 
Exchange Rates - PHP with your prices in your users currency - (2008-05-19) 
memcached - overview, installation, example of use in PHP - (2008-08-02) 
Starting Ajax - easy example of browser calling up server data - (2008-09-27) 
Ajax - going Asyncronous and what it means - (2008-09-28) 
Flash (client) to PHP (server) - example - (2008-12-06) 
Automated server heartbeat and health check - (2009-01-16) 
New Example - cacheing results in PHP for faster loading - (2009-05-24) 
Uploading and Downloading files - changing names (Perl and PHP) - (2009-08-04) 
Scraping content for your own page via PHP - (2009-12-21) 
PHP data sources - other web servers, large data flows, and the client (browser) - (2010-11-04) 
Setting your user_agent in PHP - telling back servers who you are - (2010-12-18) 
How to add a customised twitter feed to your site - (2011-02-27) 
On this day ... one PHP script with three uses - (2011-09-26) 
Building up from a small PHP setup to an enterprise one - (2012-12-16) 
Handling failures / absences of your backend server nicely - (2013-02-08) 
Using web services to access you data - JSON and RESTful services - (2013-03-29) 
Further recent PHP examples - (2013-04-28) 
How do I post automatically from a PHP script to my Twitter account? - (2013-07-10) 
Caching results in an object for efficiency - avoiding re-calculation - (2016-01-20)
Some other Articles
TransWilts meeting ...What might you find at a tiny bed and breakfast?The painful cost of local travel to MelkshamSnog, Marry, AvoidWeb server efficiency - saving repetition through cachesOur day trip by train from Swindon, Chippenham and Melksham to WeymouthWeymouth vis the TransWilts - the day out todayQuestions from children about Melksham CampusInstalling Lua 5.2.2 on Mac OS X 10.7.4POETS day at Well House Manor