PHP 8.0 and performance optimization with Tideways

In this interview, Benjamin Eberlei, founder and CEO of Tideways, talks about the innovations in the product and gives important tips with regard to PHP 8.0.

Please introduce yourself and your company briefly

I am Benjamin and founder of the company Tideways. Tideways is a software for measuring the performance of PHP systems, e.g. shop systems like Magento, Shopware or Symfony applications. With Tideways you can check how fast individual pages are, which errors occur and also get tips on how to fix performance problems.

The company has now been around since 2016 - so we'll be celebrating our anniversary next year.

Why did you specialise in the performance measurement of PHP systems?

I worked in a company where we helped larger shop customers to do load tests and performance analyses. This was mainly in the course of preparing for Black Friday and the Christmas business, for example, or for shop relaunches. We checked whether the (new shop) could absorb the expected volume in terms of performance. However, we always had the problem that we could find out how much load the shop could handle, but could not say in detail if it could not. Above all, we could not explain what the reasons were for a lack of performance.

We then started to look at how we could theoretically find solutions to this problem and came across a few helpful open source tools during our research. We then made small prototypes based on these and from this came the idea of turning this into a product - Tideways.

How many people were you when you started and how did you develop?

At the time, I worked for the company Qafoo, which did e-commerce consulting in the area of PHP. Together with Qafoo, I then founded Tideways, where I am the only active managing director and shareholder. Currently there are seven of us.

What does Tideways do exactly?

Tideways is an extension for PHP that you install on your own server. Tideways then hooks into the various interfaces that PHP provides. You can then use it to measure performance and check for errors.

We collect this data from every page view, so whenever a visitor goes to the shop, Tideways measures the following:

• How fast was the page load?
• Which parts were fast in the process?
• Which parts were slow?

Tideways does this not only for database queries and other functions of the shop system, but also at the interfaces to third-party providers. We check every single area for its speed.

All this data is then aggregated in an intermediate process we call "Tideways Daemon" and sent to our backend. In the backend, the data is then processed, prepared accordingly and made available to the user. For this purpose, the client uses our web interface, where one can access the corresponding data, which is continuously streamed from the client application to the backend.

However, this access is not live, so it is not real-time data. However, it is very close to what is happening at the moment.

Can the customer solve his performance problems with Tideways?

If the customer notices that his site is getting slower, he can enter his dashboard and get an overview of what the performance loss could be because we make the problems visible with our software. For a number of problems, we can even suggest concrete solutions. But of course the software is too complex to do this completely automatically.

How is Tideways different from other profilers?

At the time we created Tideways, there was only New Relic - Blackfire came out shortly after. One of the reasons we developed Tideways is that New Relic didn't meet our requirements.

New Relic itself doesn't have a really good profiler, because you can't control it in as much detail as you can with our software. With us, the client has a lot of control over the profiler to find out what exactly is causing the performance drop. With New Relic, on the other hand, there is no possibility of personal influence, because the system works completely automatically and thus takes away the decision of what is displayed.

In contrast, Blackfire is also a profiler, where you also have a lot of control over the data you want to see. But in Blackfire it is always necessary that the developer triggers the collection of data, it is not automated per se. There are also automated processes in Blackfire but in principle they never measure the data of real users. It is more or less the case that Blackfire or the developer accesses the server from the outside, triggers the profiler and then the performance that the developer or Blackfire has seen becomes visible. So the performance of real users is not measured.

However, our philosophy is that you have to look at what real users see, i.e. you have to see the performance based on real data. Because if you don't do that, you can never be sure that the data you collect corresponds to reality, which is not very promising.

Our idea was therefore to develop a "new" New Relic. That is, we wanted continuous monitoring, the measurement of each individual request and the aggregation of the data so that we could show the overall performance of the application. And - very importantly - the developer should be able to "take over" the profiler if desired and collect detailed data about individual page points.

This is what makes Tideways special: we have combined the monitoring aspect of New Relic with the profiling aspect of Blackfire.

Another special feature is certainly that we have focused on PHP, while the other profilers also support other languages. At first glance, this may seem an unusual decision on our part, but writing a profiler requires an extremely specialised knowledge of the corresponding language. And we have this high level of expertise in PHP - and would not necessarily meet our own requirements in the other languages.

In addition, from a market perspective, we deal with e-commerce companies in the SME sector and less with DAX companies or large corporations. In our experience, the majority of these companies use PHP and since this market is very large, we don't necessarily see the need to expand our software to include other programming languages.

Speaking of languages: 50 per cent of our customers are from Germany and the other 50 per cent are from all over the world. And that really means everywhere. In fact, I think we now have at least one customer on every continent.

What distinguishes us from other profilers is our focus on measuring application performance. Other tools sometimes also measure server performance: how much memory does the server have, how much CPU and RAM is used, etc. Our mutual customers can of course benefit from the fact that maxcluster does these server-side performance measurements. I can therefore understand that some users wish to have a tool that can do everything, but in my experience these "all-rounders" are unfortunately not really good across the board. And that can mean that you can't get to the bottom of a problem with this tool because the last 5 to 10 percent of detail is missing.

(Note: *A comparison between the profiling tools mentioned can be found in our blog series*: https://maxcluster.de/en/blog/2017/04/identifying-bottlenecks-profiler-blogseries)

Why did you become a contributor to PHP 8.0?

The biggest project I am still involved in and one of the main contributors is Doctrine. This is a database abstraction, i.e. a library for accessing databases.

But I've actually been involved in various open source projects since 2008, and they were always written in PHP. I also did a lot of work on the Symfony framework. Through my work at Tideways, I also learned how to change PHP as a language.

PHP is written in C, which is a different programming language that is much more complex. As a user of PHP - Tideways itself uses PHP - and through my work on open source projects, I kept coming across features that I thought would also be interesting in PHP itself. And that's when I started looking at how I could contribute them.

Through my work on Tideways, I already knew some of the PHP developers who continuously contribute to PHP, and this gave me a bit of an introduction to trying my hand at it. About two years ago, I started to contribute the first change. It wasn't exactly small, but it gave me the opportunity to try things out a bit. Thomas Weinert and I added new functions to an existing interface, the DOM XML interface. By the way, this is already available for PHP 8.0. After that, I contributed a larger feature together with Martin Schröder: Attributes.

The exciting thing about PHP is that it is a democratic open source project. This means that all contributors have the option of whether or not changes are made. This in turn means that as a contributor I have to describe my planned change, develop a prototype and create a design document, and only then can I release it for voting. The proposal is then often discussed for several weeks and then a vote is taken on whether this change will actually be accepted or rejected after all. This sometimes has a real political component and of course you have to find yourself in this process first.

This process, which can sometimes take weeks, naturally only applies to new features. When it comes to fixing bugs, the procedure is much faster.

But there are two reasons why I am working specifically on PHP now. Firstly, the work can be seen as a strategic investment for our company. Because Tideways correlates so strongly with PHP, it is simply important for us to know how it works. And of course, networking with other contributors prevents us from losing touch and thus our livelihood.

On the other hand, the development of PHP is simply interesting and exciting for me, because it is - at least for me - a great challenge. It's difficult and you have to be careful, but in return you reach a lot more people because PHP is simply used by a lot of people. But it's also nice that I acquire knowledge that I can use in my company, so that I now also have the opportunity to develop projects during my working hours.

How do you rate the new features in PHP 8.0?

You can divide the changes into different groups and basically PHP 8.0 continues what PHP 7 started five years ago. It's about the language getting more features to enable better typing, so that when you have a variable, you can better describe what type it is.

In PHP 8.0 there is the new feature "Union Types", in my opinion a very big feature of PHP 8.0 (Note: This and more features are covered in detail in our PHP 8.0 blog article) and was one of the first RFCs that was accepted by the contributor more than 1.5 years ago. There are also a number of other, smaller RFCs that also improve typing.

And already in PHP 7, a number of old features that were either little or not used at all, or had inconsistencies, were started to be removed. PHP 8.0 takes this even further. Inconsistencies in the language have been removed and the language has been given much better internal documentation about what types of individual functions are accepted and returned. Everything was made more consistent and some legacy issues were really cleaned up. Conversely, this also means that very old code will not be easy to migrate to PHP 8.0

Does PHP 8.0 make it easier for beginners?

At first I didn't think so, but now I believe it too.

PHP was always meant to be a language that developers could easily get into. And that is also the case. However, it is easy to "shoot yourself in the foot". There are always little things where you can quickly and unintentionally build in a security gap because you don't know in detail what exactly you should be doing. By the way, I don't think that's so bad in principle, because you can learn from it.

Now the language is certainly a bit more complicated and not as forgiving. For a beginner, this means that he may encounter problems more quickly that he has to fix. But now there is much better documentation and overall much fewer inconsistencies, so it is even easier to learn PHP.

With the new version, some things have actually been solved that gave PHP a bad reputation among programmers of other languages. This process was started with PHP 7 and will continue with PHP 8 and clearly. And of course one goal - even if it has never been stated because the system is so democratic and no one controls it - is to attract young people to it. Otherwise, at some point only "old people" would be programming in it and not develop much new stuff, so the language would be developed less and less. I think that there are many things in PHP 8.0 that will lead to young developers being excited about using this language - and perhaps not looking so bad to their friends ;-).

What do you think about the JIT compiler?

For me, this belongs to the second group of new features, or the second big block is the just-in-time compiler (JIT compiler). In principle, it is also one of the features why a major version was released and not another version of PHP 7.

In my opinion, this is a very exciting feature and I am curious to see how people will use it and what experience will be gathered. It is important to remember that this is now the first release and the PHP developers need feedback on how the JIT compiler works in real applications.

Initial tests have shown that the performance improvements of applications running on the web, such as Magento shops or Shopware shops with Symfony applications, will be very small. But this can of course improve in the future.

In fact, the main use case for the JIT compiler is currently console-driven applications, i.e. applications that do a lot of mathematical calculations and process a lot of data.

Probably many think that the JIT can simply process a lot of data, but it is important to know that the processing in the JIT compiler must be done via PHP. This means that you would need PHP code that becomes faster so that faster processing is also possible. For example, if I have a library that processes images, this code is usually written in C. This is sometimes fifty times faster. This is sometimes already fifty times faster than PHP and will not become faster even with the JIT. The same applies to applications for database queries, which are also not written in PHP code - they do not become faster through the JIT compiler.

I therefore believe that there will be a longer phase at the beginning in which one has to try out which applications will benefit from the JIT at all. And then this feedback urgently needs to go back to the developers who are working on the JIT in order to improve it.

With a just-in-time compiler, it's like this: The way PHP works now, the code is executed on a virtual machine at runtime, which of course brings certain performance qualities. The JIT compiler recognises PHP code that can be improved by taking it out of the virtual machine and translating it into more machine-like code. You have to think of it as PHP is at a very high level and there are many layers underneath that are faster. So the goal is to find exactly the right building blocks that make the construct faster, because only then will it also be more performant.

With regard to performance, however, there is another problem, and this arises when the code is changed from PHP to JIT code and vice versa. This is more or less like a translation interface. The difficult task of the JIT is to find the right parts for optimisation so that the performance gain is not cancelled out by the "JIT translations".

And I think that is the main difficulty in developing a JIT: you can only improve it if you now try it out with real data and evaluate that data. But that also means that this is an iterative optimisation process and you start with a not-so-perfect solution that will continue to improve over time and will then also be useful for significantly more users. The first big step has been taken: the JIT compiler is available and can already carry out the first translations.

In my opinion, this first step is already impressive, because it really is a massive project. And you have to bear in mind as a user that when you switched from PHP 5 to PHP 7, there was more or less a 50% increase in performance, from which everyone benefited for free. With the JIT, it won't be free, because to improve the performance that much, you have to invest a lot of work, calibrate it well and also try out a lot.

Have you had to make any changes to Tideways in relation to PHP 8.0?

We released our new version in mid-November, which already supports PHP 8.0.

Our biggest project with this release is related to the JIT compiler, because it was not possible to do performance measurements of the code that goes through the JIT.

You have to imagine it like this: PHP is the virtual machine and the JIT is a complete, second PHP implementation that sits next to it. But of course the JIT works with a completely different mechanism, so all the interfaces we used in Tideways no longer work. Whether performance measurement or error detection, everything no longer exists in the "new JIT world".

So we have had to develop new APis that make it possible to measure both "judged" and "non-judged" code - regular, old code - with the same interfaces. Our customers can therefore rely on valid data even with PHP 8.0.

Do you have three important tips for using PHP?

As already described, the latest PHP versions have many new features and syntax. Of course, this is very beneficial, because the code is tighter, shorter, but also more secure. But what do you do with all the old code?

At Tideways, and in other projects I have been involved with, we have started to automate a lot of code changes. This process is of course driven by a few tools that have been developed, some of which I can recommend here:

• The first, simplest and probably best known is the PHP Code Sniffer. This has been around for a long time, but it can now automate changes better and better. For example, you can use it to adapt existing code to the new, modern formatting styles. In addition, you can introduce individual, new features, or convert code that is used as features into new features without breaking it.
• The second is a library that pushes this even further - Rector. With it, you have the possibility to say very specifically that you want to completely replace certain written code in your own code base with a new, better and more modern syntax. You can thus migrate code that uses old features completely to the new version - and most of it automatically. Of course, you still have to check this, but migration is now very safe.
• And my third recommendation is tools that already use the modern features and stronger typing to automatically detect bugs and errors. These tools check whether the type I return in one place is also compatible with functions elsewhere. This information did not exist in PHP in the past, but is now available. In the past, the error would have become apparent at some point and caused the programme to crash. The new tools now detect these errors automatically in advance, just by reading the code. There are two or three well-known tools: Psalm, phpstan and PhanAnd . Die machen im Großen und Ganzen dasselbe und unterscheiden sich nur minimal voneinander. Wir nutzen diese bei Tideways auch schon automatisiert und stellen fest, dass damit sehr viele Fehler erkannt werden. All of these tools have basically only been made possible by the new modern features of PHP and the strong typing.

As a partner of Tideways, the current software can be configured in our Managed Centre with just a few clicks. Should you have any queries or require further information, please feel free to contact our service department on 05251/414130 or by e-mail support@maxcluster.de.

Published on 14.12.2020 | NM