Google adds QUIC protocol to latest Chrome build, delivering HTTP over UDP

Google adds QUIC protocol to latest Chrome build, delivering HTTP over UDP

Here are the QUIC highlights Google wants to emphasize right now:

  • High security similar to TLS.
  • Fast (often 0-RTT) connectivity similar to TLS Snapstart combined with TCP Fast Open.
  • Packet pacing to reduce packet loss.
  • Packet error correction to reduce retransmission latency.
  • UDP transport to avoid TCP head-of-line blocking.
  • A connection identifier to reduce reconnections for mobile clients.
  • A pluggable congestion control mechanism.

In other words, QUIC is yet another protocol that Google is building to help speed up the Web. It has already done so notably with its SPDY protocol, which is now the foundation of the upcoming HTTP 2.0 protocol.

Apache2 vs Nginx for PHP application

Apache2 vs Nginx for PHP application

The conclusion is that it doesn’t matter which server you are going to chose. The real performance wins are purely on PHP side. Using an accelerator with caching can multiply the number of requests your infrastructure can maintain.

Configuring the Apache MPM on Fedora

Configuring the Apache MPM on Fedora

If you take nothing else away from this article, let it be that you should tailor your MPM’s MaxClients setting so that your web server won’t try to allocate more resources than you have available. Better that a visitor wait a moment for a connection than that the server should dip into swap for more memory and bring the entire virtual machine to a crawl.

SPL – Standard PHP Library

I’ve been looking at SPL for some time now.  On one hand, it’s a new addition to PHP core (since version 5.3), so I know how to work without it.  On the other hand, it provides standardized solutions for common problems, and that should be enough reason to start using it.  However, today I came across an interesting article that provides even more reason to use SPL.

In this post I want to investigate the memory usage of PHP arrays (and values in general) using the following script as an example, which creates 100000 unique integer array elements and measures the resulting memory usage:

$startMemory = memory_get_usage();
$array = range(1, 100000);
echo memory_get_usage() - $startMemory, ' bytes';

How much would you expect it to be? Simple, one integer is 8 bytes (on a 64 bit unix machine and using the long type) and you got 100000 integers, so you obviously will need 800000 bytes. That’s something like 0.76 MBs.

Now try and run the above code. You can do it online if you want. This gives me 14649024 bytes. Yes, you heard right, that’s 13.97 MB – eightteen times more than we estimated.

[…]

But if you do want to save memory you could consider using an SplFixedArray for large, static arrays.

Have a look a this modified script:

$startMemory = memory_get_usage();
$array = new SplFixedArray(100000);
for ($i = 0; $i < 100000; ++$i) {
    $array[$i] = $i;
}
echo memory_get_usage() - $startMemory, ' bytes';

It basically does the same thing, but if you run it, you’ll notice that it uses “only” 5600640 bytes. That’s 56 bytes per element and thus much less than the 144 bytes per element a normal array uses. This is because a fixed array doesn’t need the bucket structure: So it only requires one zval (48 bytes) and one pointer (8 bytes) for each element, giving us the observed 56 bytes.

For years I’ve been suffering from PHP’s memory hunger. I’ve had to optimize the code around smaller memory footprints, unset variables, and do all sorts of other messy things, that I normally wouldn’t have in a high-level programming language like PHP. With SPL, it seems, there is more help on the horizon.