This is part 5 of a 6 part series looking at the some of the wonderful features of PHP 5.5 and why it might remain a dominate web language for the future. This series was originally written for the Software Developer’s Journal.
One of the main criticisms of PHP has always been “it is sloooowwww” or “slower than ______” (fill in the blank with some other trendy language). While sometimes this is the case because of the language, it is often more the case from bad programming. Which in any language could slow it down. But to help with this, the PHP community has decided to implement a caching mechanism called OPcache. This change will allow some dynamically generated pages act more static by compiling the script and caching it. We talk about it more in this part of the series below.
We all know how important it is for the web to be fast and responsive. Newly bound into PHP 5.5 is OPcache (aka Zend OPcache) which allows you to easily compile and cache PHP scripts to then be rendered on a moment’s notice. This is perfect for scripts that you know are going to end up with the same result no matter how many times they are run. This is a new feature designed to help with the pillar of performance we mentioned earlier.
As with any caching mechanism it is important that you find the right balance between serving up a fresh copy of a script versus a cached one. An instance where OPcache could be really useful is for projects like a historical stock price ticker script.
Let’s say for a moment you are in charge of developing a stock ticker which will show several years worth of end of day stock prices. You are going to create a PHP script which will render this info as JSON to a front end using JavaScript. The JS will pull this information into an HTML5 stock chart to show it graphed visually to the user. The prices for the last 3 years are fixed in time. They will rarely change. The only time they would change is when the end of the trading day is reached. So you want to set up your PHP script to be cached. That way when thousands of visitors are looking at it, you are not re-compiling the code each time to feed the chart. You can then set the cache to expire every hour. That way when the end of the trading day is reached, the new end of day price will be added, the script will be recompiled on its hourly schedule and the cache is refreshed for the next hour’s worth of traffic.
Why is this huge? Well, it means that you can compile complex or slow scripts, stuff them in cache and serve them up in milliseconds. The end result is that your site is much faster and more responsive right where it counts. Faster sites mean a better experience for the end user and that could lead to a happier, and perhaps more profitable, future buyer.
Where would this be a hindrance? Well, if the page is truly dynamic, where each time it is requested it is likely to be different, then you wouldn’t want to cache it. Otherwise the info you are displaying may be stale and would have the opposite effect on the user. Who wants to visit a stale site and see a ticker which is not showing accurate information?
To help guide you on the best way to use this, I recommend you read up about the advantages of caching web graphics or handling browser caches. The advantages to caching scripts are very similar.
In our last part of the series we talk a bit about where PHP might go next. We briefly talk about a couple proposal features mentioned and I offer a few thoughts on them.
Thanks again for reading! 🙂
