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.

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.

Kevin Schroeder was asked recently (as a part of a training class) about the amount of memory Magento actually uses during its execution. Magento is a widely-used e-commerce platform built in PHP.

Now, I know what you’re supposed to set it at, but I’ve never measured actual usage. So I gave some bullcrap answer about how it really depends on a bunch of things and that I really shouldn’t give a precise answer. But the individual persisted and I was forced to put my tail between my legs and admit that I didn’t know. So I promised that I would take a look and here are my results.

He briefly mentions how he tested the memory usage of the code overall by adding an event to several spots in the application and using memory_get_usage. Using the sample Magento data he worked his way through the site and tracked the events/memory usage on the various page of the site including:

• Main category page
• Category page with images
• Simple product page
• Add to Cart

Each of these has a graph showing the memory usage at each stage. Additionally, he's graphed them all together to compare the overall memory consumption.He finishes off the post with a few summary items and conclusions from his results.

In this new post to his blog Joshua Thijssen describes something that can help when processing large amounts of data (like, in his example, the text of a book) to search through the information and find if a certain piece of data is in the set - a bloom filter.

Most of my co-workers never really heard of bloom filters, and I’m continuously need to explain what they are, what their purpose is and why it’s a better solution than other ones. So let’s do an introduction on bloom filters. [...] Bloom filters have the property of being exceptionally fast AND exceptionally small compared to other structures but it comes with a price: it MIGHT be possible that our bloom filter thinks that an element is inside our set, when it really isn’t. Luckily, the reverse is not possible: when a bloom filter says something is NOT in the set, you are 100% sure that it isn’t part of the set.

He explains how the filter works, noting how it's better for memory consumption and how it's possible for it to give a "maybe" response instead of ab absolute "yes" or "no". He also points out a PHP extension, bloomy that takes the hard work out of it for you.

On the UMumble blog there's a recent post looking at memory consumption in PHP applications - what PHP does for you when managing how it uses your system's memory and what you need to worry about in your code.

There is a widespread view that the ordinary PHP developer does not need to control memory management, but "controlling" and "knowing" are slightly different concepts. I will try to throw light upon some aspects of memory management when working with variables and arrays, and some interesting pitfalls of the internal optimization of PHP. As you can see, the optimization is good, but if you do not know exactly how it is optimized, you might meet the pitfalls, which can make you pretty nervous.

They talk about some of the basics - how variables are stored in hash tables and how this helps memory consumption - as well as using the memory_get_usage method to find your current consumption. This is show for both regular strings and arrays, comparing larger data (and assigning it multiple times) to simpler structures. They also mention how PHP handles memory usage in passing by reference and copying of values.