In a new post to his site Cees-Jan Kiewiet shares details about the latest version of the React/Cache component for the ReactPHP library. In the tutorial he covers the library, what this update brings with it and how he's making use of it.

Recently we, ReactPHP, released 0.5 of our cache package with TTL and other PSR-16 similarities. In this post we'll go over which packages I recently updated and how I am using them in my sites.

He breaks the post up into a few different sections showing the caching in use:

• JSON and msgpack
• Redis
• Fallback
• react/http session middleware
• react/http webroot preload middleware

For each item in the list there's a bit of code showing it in action and some explanation as to what it's doing and how it helps.

On the Tuleap blog there's an article posted showing how they made the switch from RabbitMQ to Redis in their PHP application.

There are various places in Tuleap were message queues are needed but the primary one is to run jobs in background. Historically it was for all system related stuff (creating users, git/svn repositories, etc) that required special unix permissions that we were not eager to grant to a web app.

[...] More recently we add a need to share events across servers, for distributed Tuleap setup for instance. Our good old system was no longer able to deal with that because we needed a real queue management that works across servers. We choose RabbitMQ because we were looking for a queue system, PHP support quite decent and tutorials were good. However, we had to setup a quite complicated queue system.

The post outlines the exchange to exchange binding system they created and includes the code use to make the RabbitMQ-based system work. Then they introduce Redis and how, when they learned about RPOPLPUSH, decided to make the switch. The code for this replacement is also included.

Gonzalo Ayuso has a tutorial posted to his site showing you how to create a PHP application on a SAP platform that includes PostgreSQL and Redis via Cloud Foundry.

Keeping on with my study of SAP’s cloud platform (SCP) and Cloud Foundry today I’m going to build a simple PHP application. This application serves a simple Bootstrap landing page. The application uses a HTTP basic authentication. The credentials are validated against a PostgreSQL database. It also has a API to retrieve the localtimestamp from database server (just for play with a database server). I also want to play with Redis in the cloud too, so the API request will have a Time To Live (ttl) of 5 seconds. I will use a Redis service to do it.

He then walks you through the process of setting up both the platform and the application:

• creating the services in cloud foundry
• create our application (with either Silex or Lumen)
• built out the features
• running the application locally for testing
• connecting to the cloud servers for PostgreSQL and Redis
• set up logging
• set up basic authorization

Full code and configuration is included for each step of the way (with Lumen examples included because Silex is "dead").

Michelangelo van Dam has a new post to his site looking at using Redis for PHP sessions storage and changes related to the use of PHP 7.1.

In case you have missed it, PHP 7.1.0 has been released recently. Now you can’t wait to upgrade your servers to the latest and greatest PHP version ever. But hold that thought a second…

With PHP 7 lots of things have changed underneath the hood. But these changed features can also put unexpected challenges on your path. [...] One of these challenges that we faced was getting PHP 7.1 to play nice storing sessions in our Redis storage. In order to store sessions in Redis, we needed to install the Redis PHP extension that not only provides PHP functions for Redis, but also installs the PHP session handler for Redis.

When he installed the extension, the latest version (redis-3.1.0), he was given an error message about a failure to read the session data. He shares a bit of code he used to try to debug and diagnose the problem (and a Docker environment) that still resulted in the error. Ultimately they narrowed it down and discovered that it was the Redis extensions causing the problems. Downgrading it from 3.1.0 to 3.0.0 solved the issue right away.

The SitePoint PHP blog has posted a tutorial that want to help you speed up your applications with Redis, adding in caching to help reduce the overall processing load your app has to expend.

The application in question, when executing a query, runs off to Diffbot’s API and makes it query the dataset. The subset is then returned and displayed. This can take up to 5 or so seconds, depending on the busyness of Diffbot’s servers. While the situation will undoubtedly improve as they expand their computational capacity, it would be nice if a query executed once were remembered and reused for 24 hours, seeing as the collection is only refreshed that often anyway.

Considering the fact that implementing this cache costs us literally nothing (and actually reduces costs by reducing strain on the servers), adding it in is an easy win, even if it weren’t used as often as one would hope. There is no reason not to add it – it can only benefit us.

He helps you get Redis up and running as a service on the local system and installing the Predis, the PHP library you'll use to talk with Redis for setting and getting the cached information. He includes a few code snippets showing how to send the search off to the DiffBot API, return the results and push them into the cache as serialized data with a day long timeout. He also mentions the phpiredis extension to reduce some of the overhead that could be cause by using a PHP library versus an extension.

In a new post to his site Ulf Wendel shows an alternative use for the PHP Memcache functions - using them to query MySQL tables (InnoDB) in much the same way. He also tosses in Redis as another version to compare the performance against (for fetching key/value pairs).

PHP users can use two client protocols to query MySQL 5.6 and later. Not only standard SQL access but also faster key-value access to InnoDB tables is possible using the Memcache protocol. The MySQL benchmark team reports crazy figures. Of course, on hardware that makes the average PHP meetup visitor roll his eyes and say “yeah, Oracle, *yawn*…”. I’ve repeated my plain PHP benchmarks on an i3 desktop. And, I’ve added Redis to the game.

He goes through and compares a few different things with some simple benchmarks around operations per second:

• MySQL 5.6 Memcache vs. MySQL 5.7 Memcache vs. Memcache vs. SQL
• MySQL vs. Memcache vs. Redis

For each he's graphed out the results of the benchmarking with some surprising results for those that may thing MySQL isn't as suited as Redis for something like this.

DZone.com has posted the second part of a two-part series looking at increasing the performance of your PHP applications (part one is here). In this new post, he looks at a few topics including caching, session handling and asynchronous processing with Resque and Redis.

Ultimately, scalability is about the entire architecture, not some minor code optimizations. Often times people get this wrong and naively think they should focus on the edge cases. Solid architectural decisions like doing blocking work in the background via tasks, proactively caching expensive calls, and using a reverse proxy cache will get you much further than arguing about single quotes or double quotes.

He briefly recaps some of the "core principles" for optimizing applications and gets right into explaining the later ones on the list:

• Optimize sessions through memcached handling
• HTTP request/response caching
• Caching Doctrine result sets
• Caching the web service responses made with Guzzle
• Handling asynchronous processing with Resque and Redis

He includes code and configuration examples for each item, helping to flesh them out a bit more. He also makes a recommendation of using something like AppDynamics to monitor the performance of your application (disclaimer: he works for them).

On VilkomenJuist.nl there's a recent post showing you how to create a real-time notification system with PHP using Laravel, NodeJs and Redis.

Currently I am building an application where we can fill in live scores and I needed something to update all my visitors whenever a score has been updated by one of the admins. Whenever an admin updates the score via the Laravel 4 backend I fire an event and publish it to Redis. I’ve setup a simple NodeJS server which listens to Redis for incoming changes. NodeJS will redirect the message to all Socket.IO clients.

The post has all of the code and configuration you'll need to reproduce the setup. This includes the Laravel Redis config, code for the event handler and the Node server listening for the socket connection.

On PHPMaster.com today there's a new tutorial showing you how to store your application's sessions in Redis, a key/value store known for its flexible nature and speed.

PHP’s default handling of session data is probably sufficient for most applications, but sometimes a project will demand a different storage approach. Luckily, the session handling routines can be overridden either by a series of functions (in older versions of PHP) or a class with methods (in newer versions) which handle various aspects of session management. In this article we’ll learn how to create a custom session handler which implements PHP’s SessionHandlerInterface interface and stores the session data in a Redis database.

He talks some about the reasoning behind using something more than just the normal PHP session handling (including the flexibility it provides). He covers some of the basics of the session handling functionality and covers how the data itself is stored. Finally, he gets to the actual class - a Redis-specific handler that implements the SessionHandlerInterface interface.

Aleksey Korzun has posted some of the results from benchmarking he performed on various Memcached and Redis clients through PHP. His tests focused on multiple PHP client libraries, both user-land and extension based.

As some of you may know, I’m crazy about speed. So when I saw that people were happily using Predis as their choice of PHP client for Redis, I was a bit confused. Why use a client written in PHP for something that should be ‘fast’ like Redis? That kind of defeats the purpose - unless you don’t really care about response times and scalability. [...] The performance difference piqued my interest. I wanted to find out just how much performance users are sacrificing by choosing one implementation over another.

He ran his tests on VirtualBox VM instances with the same specs and the same version of PHP installed. He tested various versions of the Memcached client, Redis client, Predis and the IgBinary extension. His results (Google spreadsheet) show the requests processed using each method based on this benchmarking script.You can visit the post to see the graphs of the results too.