Logging is an essential part of just about any PHP-based application; whether in a script or a larger application. However, how little is too little and how much is too much to log? If we don't log enough information, when something goes wrong, as it invariably does, then we won't have enough information available to determine what went wrong so that we can fix the problem. However, if we have too much information, then we'll be unable to filter out the white noise.

In this post, we're going to look at what Shared-Nothing Architecture is, along with its benefits and downsides, concerning PHP and its impact on performance. Several different languages can be used for web-based application development, most of which you are likely already familiar. The most popular of these are JavaScript, Ruby, Python, Java, Go, R, and, of course, PHP. Of these languages, however, only PHP uses a Shared-Nothing Architecture by default.

It's a fact of modern software development that aspects of our applications interact with third-party APIs. This could be for any number of reasons, with some common ones being payment processing, telecommunications, logging, and data analysis. So, since our applications rely upon third-party APIs so much, we need to ensure that we integrate with them as effectively — and defensively — as we can.

Building and deploying PHP applications on one server is a, relatively, straightforward process. However, what about deploying a PHP application across multiple servers? In this article, I'm going to discuss four key considerations to bear in mind when deploying PHP applications when doing so.

Out of the proverbial, box, PHP provides decent performance. However, there are several things that we, as PHP developers and systems administrators, can do to increase its performance even further; sometimes for almost no effort. In this post, I'm going to step through five of those ways. By the time you're finished reading, you should see at least a notable increase in the performance of your PHP application. Let's begin.

All Tideways applications with a Pro license can now create additional production Environments in addition to the one that is available by default. Configuring a second or more environments as "production" effects the retention and the traces/minute collected for these environments. By default non-production environments have just 1 day of retention and 1 trace/minute.

Thanks to PHP being an interpreted language and it that it has a garbage collector, PHP developers don't often have to think about memory management. Unlike developers in compiled languages, such as C/C++, we don't have to give that much thought to memory allocation and deallocation. However, it's helpful to have a broad understanding of how garbage collection works in PHP, along with how you can interact with it so that you can create high performing applications.

This summer we worked together with David on the performance of a Magento 2 project and found some general improvements that the whole Magento community will benefit from.

Tideways history functionality is still mostly based on the features available 4 years ago, before we introduced Services and Environments, Downstream Layers and many others. Time for a redesign of the history to include support for all the features and data that are available now. By using the UI elements from the performance overview our we also introduce a familiar look and feel, where the previous history screen used its own widgets.

The PHP community is large and diverse in their approach to build and run PHP applications. We have seen hundreds of small applications running on a handful of servers and one product running on multiple clusters and hundreds of servers across the globe. Still, we believe all PHP applications regardless of size benefit from monitoring, profiling and exception tracking functionality.