Industry analysts have been predicting the demise of PHP for years. But PHP continues to rank high in various programming language popularity indexes and it is used by almost eight out of 10 websites, powering a significant portion of the internet, from Wikipedia to content management applications like WordPress and Drupal, which have been deployed millions of times.

PHP offers an easy-to-understand programming model for web developers. It makes iterative development and debugging simple, yielding a big productivity boost. Historically, though, PHP has gotten a bad reputation for slow performance and security issues, leading to questions about its future as a programming language.

With Sentry Performance Monitoring for PHP, developers can now quickly discover performance issues with their PHP-based applications. Within minutes, they can trace issues back to a poor-performing API call or slow database query and surface trends to help them proactively prevent future performance issues, saving time and reducing costs.

Distributed tracing for PHP applications

PHP applications consist of interconnected components, such as the front end (single-page application), back end (REST API), task queue, database server, and cron job scheduler. Each can be instrumented to capture error data or crash reports, but that doesn’t provide developers with the full picture, as each piece is analyzed separately. With Sentry Performance Monitoring for PHP, distributed tracing allows developers to tie all of the data together to gain clearer insights into which services may be having a negative impact on the application’s overall performance.

A distributed trace represents the record of the entire operation that is measured or tracked, such as page load time, or an instance of a user completing some action in the application, or a cron job in the back end. And each trace consists of one or more tree-like structures called transactions, the nodes of which are called spans. In most cases, each transaction represents a single instance of a service being called, and each span within that transaction represents that service performing a single unit of work, whether that is calling a function within that service or making a call to a different service. Here’s an example trace, broken down into transactions and spans:

sentry php performance problems 01 Sentry

Because a transaction has a tree structure, top-level spans can be broken down into smaller spans, mirroring the way that one function may call a number of other, smaller functions. This is expressed using the parent-child metaphor, so that every span may be the parent span to multiple child spans. Here’s a zoomed-in view of one of the transactions from the diagram above:

Copyright © 2021 IDG Communications, Inc.