On the SitePoint PHP blog, there's a tutorial posted showing you how to deal with large files without "killing your server". In this case, it's not about the upload process but about the handling of large files on the server side.

It’s not often that we, as PHP developers, need to worry about memory management. The PHP engine does a stellar job of cleaning up after us, and the web server model of short-lived execution contexts means even the sloppiest code has no long-lasting effects.

There are rare times when we may need to step outside of this comfortable boundary — like when we’re trying to run Composer for a large project on the smallest VPS we can create, or when we need to read large files on an equally small server. It’s the latter problem we’ll look at in this tutorial.

They start off by describing how they plan to measure the success of the improved file handling, mostly around the memory usage required to work with the file. It then gets into some of the options available including:

• reading files line by line
• piping between files
• using filters

The last option, the filters, seems to be the best one. He uses this one and customizes the handling with different configurations and custom protocols. All related code is included in the post and is avaialble on GitHub.

In this new tutorial on the TopTal.com site author Agustin Villalba takes an in-depth look at how objects and references are handled in memory by the PHP language.

In this article, I will talk about how object and variable references are controlled in memory, since this is an issue that can generate discussion and differing opinions. One question to ponder is: “By default, are objects passed by reference or by copy in PHP?” I’m going to talk first about what references are not in PHP; secondly, I’ll discuss what they are, and finally, I will examine how the garbage collector works in PHP.

He starts with a quick comparison between objects and references (since they're slightly different). He then covers what things are and aren't references in PHP and some examples showing what they are in either case. Code examples and visuals are included showing how things relate. The post wraps up with a look at how garbage collection works with objects/references and a few closing thoughts about how the collector chooses which to clean up.

Hayden James has a post on his site sharing a method he's found for getting better performance out of PHP-FPM with the help of a configuration change. In this tutorial he shows how to use the pm static setting to squeeze the best performance out of your web server.

Lets take a very quick look at how best to setup PHP-FPM for high throughput, low latency and a more stable use of CPU and memory. By default, most setups have PHP-FPM’s PM (process manager) string set to dynamic and there’s also the common advice to use ondemand if you suffer from available memory issues.

He starts by defining the three "pm" settings and what they do: dynamic, ondemand and static. He then talks some about how the PHP-FPM process manager is similar to CPUFreq Governor and the settings it allows. Finally he gets into talking about the "pm static" handling, how it relates to available memory and when it makes more sense to use "dynamic" over "static".

On the Hackernoon.com site there's a recent post from Paolo Agostinetto showing you how to debug your PHP application with a different tool that most might use: strace.

Every once in a while it happens that you have a tricky bug, and when it does you risk to lose hours or even days fixing it.

[...] Yet, sometimes there is that one bug that makes you lose your shit after a whole afternoon spent looking for the root cause. In my experience, bugs that I introduce are generally very quick and easy to spot and fix. But the real challenge is finding bugs in other people’s code like third party libraries, PHP extensions or even PHP itself.

He then talks about a time when his situation was a bit different - he was getting 500 errors from his code that weren't being caught correctly by error handling. He found that Apache was out-of-memory-ing but debugging the exact cause (a suspect Doctrine query) would take more time. Instead he turned to strace and, with a bit of hunting in the resulting output, he tracked the issue down to XDebug being enabled (and a setting that was generating a memory leak).

The Scotch.io blog has posted a tutorial that wants to introduce you to and help you understand a feature recently added to the PHP language: generators. In this new article author Samuel Oloruntoba walks you through some of the basics and offers advice on when to use this helpful feature.

When it comes to driving, speed is not everything. But on the web, speed makes all the difference. The faster your application, the better the user experience. Well, this article is on PHP Generators, so why are we talking about speed? As you are soon about to find out, generators make a huge difference on speed and memory management.

He starts off by explaining what generators are and gives a simple code example showing how they can replace a standard loop (without some of the memory overhead). He uses a for and foreach loop to show a memory overflow caused by it trying to reach the highest integer allowed in the config. To help solve this, he makes use of generators, a much more memory efficient method that only returns the latest value requested and doesn't keep the remainder in memory. He then answers the question of why you might need to even use generators, how to return keys and send values into the generator. He also offers a word of advice on using them - mostly to not overuse them as it's still possible to have issues (like the memory one above).

Christian Weiske has a post to his site with a reminder about a common misconception that can happen because of the wording in a standard PHP message about memory exhaustion.

The indieweb.org wiki has a page about Wordpress with a Criticism section. ?

One of those "issues" listed is Fatal Error memory exhausted [...but] I removed that section because it's nonsense to list a server configuration issue as Criticism.

While the admins reverted the change to put the message back, Christian clarified what meaning of the error message to help clarify the situation. In the case if the example message, the "32 bytes" it mentions is not the amount of total memory it's trying to allocate, it's the amount it last tried and failed at. Christian also points out the role that PHP's own memory_limit setting has on when this message might pop up.

The Laravel News Podcast has released their latest episode, Episode #13 hosted by PHP and Laravel community member Eric L. Barnes.

In this episode, we talk about Laravel Exception Reporter, Chrome Bandwidth limiter, Chrome extension to generate Laravel tests, Jigsaw, Helpspot Vault, Fixing MySql Memory, Sparkwatch, and Taxes.

You can listen to this latest episode either using the in-page audio player or by subscribing either through iTunes or their RSS feed.

In his new post to his site Zeev Suraski talks about the momentum growing behind PHP 7 and some of the recent articles about companies making the move and the overall impression of the new version.

We’re now a few months since PHP 7 came out, and if you’ve been following what’s going on in the PHP world, things are looking pretty exciting! [...] First, InfoWorld gave PHP 7 the 2016 Technology of the Year Award, which is quite remarkable. Remarkable is also how InfoWorld chose to describe the performance gains that are promised by PHP 7 – and I absolutely agree.

[...] As more and more people are trying PHP 7 out, we’re seeing more and more evidence that the promise of 2x performance is being realized, big time. Most recently, Badoo published an article detailing their experience migrating for PHP 5.6 to 7.0

He gets into a bit more detail about the numbers that Badoo published and gives a quick "thank you" to Dmitry Stogov for helping to spearhead the effort to get PHP 7 out the door from Zend. Finally, he points out that there's a Zend Server version that already runs on PHP 7 if you'd like to try it out.

The Symfony Finland has shared some benchmarks of the latest versions of the Symfony framework (simple applications) on three current environments to see the differences: PHP 5.6, HHVM 3.11 and PHP 7.0.1.

Since the first functional versions of PHP 7.0.0 were made available, there have been a number of benchmarks comparing PHP 5.6, HHVM and PHP 7. [...] The recently released eZ Platform is a CMS built on the Symfony framework. It's a good representation of a modern PHP application with complex functionalities and no legacy code from the 2000's. Thus making a good candidate benchmarks for testing an application built with the Symfony Framework (version 2.7.8).

So let's see how an application built with the Symfony2 framework fares on PHP 5.6, HHVM 3.11 and PHP 7.0.1.

He starts by describing the test setup including the default installation of the eZ platform and how it was configured/set up. He then shares the results, showing memory usage and response times for each of the three different platforms. There's even results from different parts of the application: the front page and the "Top Stories" and "Projects" pages. The results also include the findings for the number of requests per second both with and without the Symfony Proxy included in the platform.

In this post to his site Julien Pauli looks at the concept of "huge pages" and how it relates to some of the behind the scenes work done in PHP 7 to improve memory usage.

Memory paging is a way Operating Systems manage userland process memory. Each process memory access is virtual, and the OS together with the hardware MMU must translate that address into a physical address used to access the data in main memory (RAM).

Paging memory is dividing memory in chunks of fixed size, called pages. [...] Why use huge pages? The concept is easy. If we make the OS Kernel use bigger page sizes, that means that more data can be accessed into one single page. That also means that we'll suffer from less TLB miss, once the page translation is stored into the TLB, because one translation will now be valid for more data.

He briefly covers how some updated memory handling and opcode restructuring helps PHP 7 perform even better, especially when it comes to the OPCache handling. He talks about the changes made in the extension specifically to support the "huge pages" idea, complete with code examples (in C) of how this was accomplished.