We are releasing a new stable minor version of the Tideways PHP extension 5.1 today, which will include a few new features that we have been writing about before and a few new ones that we have cooked up in the last few weeks.
PHP isn't typically thought of as a solution when creating worker or background processes, jobs that typically can last for an extended period. These can be tasks such as image processing, file repair, and mass email batch jobs. Typically, PHP is linked with HTTP requests, requests which are short in duration and stateless in nature. However, just because of this enduring association, it doesn't mean that PHP can't be used for background processes. On the contrary.
We have just released the PHP Extension version 5.0.62 which includes a new feature, instrumentation for GraphQL queries made using the webonyx/graphql-php package, the most widespread GraphQL server package for PHP, for example by Magento 2.
The PHP INI setting memory_limit is important to configure right for two reasons. To help you finding the right memory_limit setting Tideways now offers two additional ways to see the maximum memory in use.
PHP-FPM (or Fast Process Manager) offers several advantages over mod_php, with two of the most notable being that it is more flexible to configure and currently the preferred mode of running PHP by many in the community. However, if you're using your package manager's default configuration settings, then you're likely not getting the most out of it.
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.
