Neil Mukerji
Technical post alert!
In a break from our usual feature and hospitality industry related posts, this is a technical topic for those interested in what goes on under the hood at Kobas. We’ve got some engineering news, and I’ll start with covering the benefits for our clients and their customers, before digging a little deeper into the details.
The news
I’m really pleased to announce that as of today, Kobas Cloud, Customer Loyalty portals and EPoS systems are running on the latest stable version of PHP – version 7.
How does this help Kobas clients and their customers?
The most tangible and immediate benefit for everyone is a significant performance increase. Alexandru, one of our software engineers, ran some really interesting benchmark tests on our of our report endpoints. He used Xdebug and Webgrind to repeatedly generate the information required to present a Kobas report.
Over a series of runs on a test harness, using our previous version of PHP, version 5.6, the endpoint took an average of 582 milliseconds to respond. He then uninstalled PHP 5.6 and installed version 7.0, and repeated the tests. The new average time was 371 milliseconds.
That’s a 36% reduction in time taken to process that report. It’s getting on for twice as fast!
This isn’t the whole story, as these times include time spent searching for information in the database. That of course can be optimised and improved too, but it is true to say that all aspects of Kobas are now noticeably quicker.
The other advantages
Here’s where this article gets a little more technical. I’ve had my eye on this latest version of PHP because it contains some improvements that I believe will help us to produce more robust and standards compliant software. My highlights are strict scalar type and return declarations, as to my mind these will help us to produce very clear and focussed software structures that will be naturally amenable to automated testing. Those interested can check out more information on these and the bounty of other improvements available in PHP version 7.
Swinging this back around to a Kobas client perspective, all this means that our core server language has improved to allow our engineers to write cleaner, neater and more robust code. That means that it’ll be quicker and easier for us to maintain our code, extend our platform, and push new features through quality assurance (QA).
How difficult was the upgrade to PHP 7?
I can imagine there are many CTOs out there faced with this challenge. We spent a while reviewing the backward incompatible changes listed in the migration notes and improving our codebases to be compatible with both PHP 5.6 and PHP 7.
Fortunately we didn’t fall foul of the majority of changes; for instance we typically haven’t used the list() method much. Our chosen framework, Silex, is based on Symfony which achieved PHP 7 compliance in August 2015.
We got tripped up a little by the changes to customer exception handlers, and by the removal of emulated Alternative PHP Cache (APC), but those were simple enough to iron out.
From there we upgraded a staging environment to PHP 7 and started testing. Once the automated tests passed in PHP 7 we let our QA team get involved. We started developing and testing new features and bug fixes on both PHP 5.6 and PHP 7 environments.
To upgrade our Cloud and Loyalty platforms we then used AWS magic to spawn extra EC2 instances, upgraded them to PHP 7, and swapped them through the load balancer until we were purely PHP 7. Kobas EPoS venue servers were updated during venue close hours.
All these updates were implemented using YUM and the Webtatic repository. We have initially chosen to use the mod_php Apache extension over the FastCGI Process Manager (FPM) purely to minimise the magnitude of our change. FPM certainly promises increased performance if we want to investigate it in future.
Was the transition to PHP 7 in production smooth?
Fairly. A couple of things stand out that are worth guarding against.
1) PHP 7 now includes E_STRICT level warnings in E_ALL which meant that our monitoring systems started to pick up a bunch of advisories. Naturally we are pushing forwards through this problem by improving our code so that it no longer triggers these warnings, rather than attempting to suppress them.
2) PHP 7, through Apache (httpd), attempts to access RAM more directly than its predecessors. SELinux by default prevents this. After much deliberating and consulting we enabled the httpd_execmem SELinux boolean. There remained a persistent niggle with regards to the hugetlbfs page file, and so far as we could tell this is something that is pending with the RHEL and CentOS teams:
https://bugzilla.redhat.com/show_bug.cgi?id=1319442
https://bugs.centos.org/view.php?id=10741
Again following yet more deliberation and consultation we have applied the following SELinux policy to permit this.
module php7 1.0;
require {
type httpd_t;
type hugetlbfs_t;
class file { write read };
}
#============= httpd_t ==============
allow httpd_t hugetlbfs_t:file { write read };
Conclusion
Overall it is great to stay on top of technology like this and I’d encourage other teams to move to PHP 7 if they can. Engineers will love the new features and your users (or hosting budget!) will love the extra performance. We’ve already got our eyes on the PHP 7.1 deprecations list to ensure we stay on top of the game.
