Home Accessibility Courses Twitter The Mouth Facebook Resources Site Map About Us Contact
For 2023 (and 2024 ...) - we are now fully retired from IT training.
We have made many, many friends over 25 years of teaching about Python, Tcl, Perl, PHP, Lua, Java, C and C++ - and MySQL, Linux and Solaris/SunOS too. Our training notes are now very much out of date, but due to upward compatability most of our examples remain operational and even relevant ad you are welcome to make us if them "as seen" and at your own risk.

Lisa and I (Graham) now live in what was our training centre in Melksham - happy to meet with former delegates here - but do check ahead before coming round. We are far from inactive - rather, enjoying the times that we are retired but still healthy enough in mind and body to be active!

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

Back to
Our day trip by train from Swindon, Chippenham and Melksham to Weymouth
Previous and next
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
4759 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, 96 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., 2024: 48 Spa Road • Melksham, Wiltshire • United Kingdom • SN12 7NY
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: Sun Oct 11 16:07:41 2020 • BUILD SYSTEM: JelliaJamb