Simplifying HTTP requests observability with Blackfire

The applications we are building today are becoming increasingly distributed, and as a result, our approach to managing these applications has had to evolve. 

Especially considering distributed applications rely on multiple external HTTP requests to multiple microservices. I mean, how do you optimize performance across so many elements? 

Using Blackfire, there are several features available that are engineered to help you optimize your distributed applications effortlessly. Let’s get into the details! 

Blackfire Monitoring

With Blackfire Monitoring, as soon as it’s activated, you can monitor all of your environment’s HTTP requests in one place without any further configuration needed.

It provides you with a complete breakdown of the transactions’ response time per service, allowing you to identify the most impactful easily. As well as allowing you to analyze and pinpoint all of the transactions triggering the HTTP request in the first place.

The Health Report even states the most important degrading services (HTTP requests, SQL Queries, Redis, and more) by relying on historical data. This is one of the many ways Blackfire Monitoring makes visible what was hidden before.

Accessing HTTP Request Metadata in a Profile

In a profile, the HTTP tab contains a list of all of the HTTP requests the profiled script has made. By clicking on a URL in the list, you can view the Request Metadata, which provides more information on how that specific request was handled.

Need to edit the request metadata? No problem. The Blackfire HTTP Title field within the HTTP Request Metadata can be customized by adding the X-Blackfire-HTTP-Query-Title header to the request. This can be handy for scripts relying heavily on external web services, as the title could provide a helpful context.

You can also locate the function triggering an HTTP Request by pasting the URL requested into the search bar of the callgraph. This is a useful, lesser-known feature that can enable you to save a lot of time debugging and/or optimizing pages, as it removes the painful process of finding the part of the codebase responsible for a specific request. This even works as well with SQL queries and performance metrics.

Profiling all requests

The Browser extension – available for Chrome and Firefox – provides a “Profile all requests” option. Once activated, all the front-end XHR requests are profiled until the recording session is terminated. This is a convenient way of exploring the performance of the less accessible pages of one application, such as form submissions or paginations. Although, there is still the possibility to profile cURL requests via the Blackfire CLI.

Distributed profiling

By profiling a script that relies on external web services, you also profile the HTTP requests within that script as well. As long as they run on a server with Blackfire enabled and with the same credentials. This is called distributed profiling, and here’s how it helps. 

Distributed profiling works no matter the language used to handle those requests – PHP, Python, and Go- at the time of writing. Also, if those web services rely on other web services, those requests will also be recursively profiled. 

This is a very powerful feature but a resource-consuming one. This is why our browser extension offers a ‘Disable distributed profiling’ option to give you back control over where your resources are being distributed. Hopefully, following this article, you’re feeling ready to get out there and start debugging and optimizing your HTTP requests and web services. Well, don’t be shy – make sure you share with us how you’re using Blackfire Monitoring to do more.

Happy Performance Optimization!