Home Accessibility Courses Twitter The Mouth Facebook Resources Site Map About Us Contact
Web server efficiency - saving repetition through caches

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 articles
H307 - PHP - Web2 and caching
  [4627] Caching results in an object for efficiency - avoiding re-calculation - (2016-01-20)
  [4136] How do I post automatically from a PHP script to my Twitter account? - (2013-07-10)
  [4075] Further recent PHP examples - (2013-04-28)
  [4055] Using web services to access you data - JSON and RESTful services - (2013-03-29)
  [3999] Handling failures / absences of your backend server nicely - (2013-02-08)
  [3955] Building up from a small PHP setup to an enterprise one - (2012-12-16)
  [3458] On this day ... one PHP script with three uses - (2011-09-26)
  [3186] How to add a customised twitter feed to your site - (2011-02-27)
  [3094] Setting your user_agent in PHP - telling back servers who you are - (2010-12-18)
  [3029] PHP data sources - other web servers, large data flows, and the client (browser) - (2010-11-04)
  [2545] Scraping content for your own page via PHP - (2009-12-21)
  [2321] Uploading and Downloading files - changing names (Perl and PHP) - (2009-08-04)
  [2196] New Example - cacheing results in PHP for faster loading - (2009-05-24)
  [1995] Automated server heartbeat and health check - (2009-01-16)
  [1926] Flash (client) to PHP (server) - example - (2008-12-06)
  [1814] Javascript/HTML example, dynamic server monitor - (2008-09-28)
  [1813] Ajax - going Asyncronous and what it means - (2008-09-28)
  [1812] Starting Ajax - easy example of browser calling up server data - (2008-09-27)
  [1733] memcached - overview, installation, example of use in PHP - (2008-08-02)
  [1647] Exchange Rates - PHP with your prices in your users currency - (2008-05-19)
  [1633] Changing a screen saver from a web page (PHP, Perl, OSX) - (2008-05-06)


Back to
Our day trip by train from Swindon, Chippenham and Melksham to Weymouth
Previous and next
or
Horse's mouth home
Forward to
Snog, Marry, Avoid
Some other Articles
TransWilts meeting ...
What might you find at a tiny bed and breakfast?
The painful cost of local travel to Melksham
Snog, Marry, Avoid
Web server efficiency - saving repetition through caches
Our day trip by train from Swindon, Chippenham and Melksham to Weymouth
Weymouth vis the TransWilts - the day out today
Questions from children about Melksham Campus
Installing Lua 5.2.2 on Mac OS X 10.7.4
POETS day at Well House Manor
4749 posts, page by page
Link to page ... 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95 at 50 posts per page


This is a page archived from The Horse's Mouth at http://www.wellho.net/horse/ - the diary and writings of Graham Ellis. Every attempt was made to provide current information at the time the page was written, but things do move forward in our business - new software releases, price changes, new techniques. Please check back via our main site for current courses, prices, versions, etc - any mention of a price in "The Horse's Mouth" cannot be taken as an offer to supply at that price.

Link to Ezine home page (for reading).
Link to Blogging home page (to add comments).

You can Add a comment or ranking to this page

© WELL HOUSE CONSULTANTS LTD., 2017: 404 The Spa • Melksham, Wiltshire • United Kingdom • SN12 6QL
PH: 01144 1225 708225 • EMAIL: info@wellho.net • WEB: http://www.wellho.net • SKYPE: wellho

PAGE: http://www.wellho.net/mouth/4106_Web ... aches.html • PAGE BUILT: Sat May 27 16:49:10 2017 • BUILD SYSTEM: WomanWithCat