In PHP,
What are the Advantage and Disadvantage of Caching in Web Development In PHP, how does it affect Database?
In PHP, What are the Advantage and Disadvantage of Caching in Web Development In
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Caching works in many different ways, but for PHP specifically I can think of a few ways;
Database calls; they are slow, require computation, and can be quite intensive. If you’ve got repeated calls, caching the query is golden. There’s two levels; at the PHP side where you control the cache, and at the database side where they do.
Running PHP code means the webserver calls the PHP interpreter, it parses the code, and the run it. A PHP cacher can cache the parsing part, and go straight for the running part. THen there’s the next generation of directly compiling PHP code to C, and run it from there (like Facebook does).
Computations; if you’re doing math or heavy lifting of repeated operation, you can cache the result instead of calculate it every time.
Advantages;
Disadvantages;
I’ll only deal with the disadvantages here;
First, stale data; this means that when you use cached content/data you are at risk of presenting old data that’s no longer relevant to the new situation. If you’ve cached a query of products, but in the mean time the product manager has delete four products, the users will get listings to products that don’t exists. There’s a great deal of complexity in figuring out how to deal with this, but mostly it’s about creating hashes/identifiers for caches that mean something to the state of the data in the cache, or business logic that resets the cache (or updates, or appends) with the new data bits. This is a complicated field, and depends very much on your requirements.
Then overhead is all the business logic you use to make sure your data is somewhere between being fast and being stale, which lead to complexity, and complexity leads to more code that you need to maintain and understand. You’ll easily lose oversight of where data exists in the caching complex, at what level, and how to fix the stale data if you get it. It can easily get out of hand, so instead of doing caching on complex logic you revert to simple timestamps, and just say that a query is cached for a minute or so, and hope for the best (which, admittedly, can be quite effective and not too crazy). You could give your cache life-times (say, it will live X minutes in the cache) vs. access (it will live for 10 requests) vs. timed (it will live until 10pm) and variations thereof. The more variation, the more complexity, of course.
However, having said that, caching can turn a bog of a system into quite a snappy little vixen without too much effort or complexity. A little can get you a long way, and writing systems that use caching as a core component is something I’d recommend.