Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Davey Shafik:
Aug 24, 2015 @ 10:54:54

Davey Shafik has published a post about library he's created that's a sort of "recorder" for connections made with the Guzzle HTTP client - the Guzzle VCR.

A few days ago I pushed out a very small library to help with testing APIs using Guzzle: dshafik/guzzlehttp-vcr. [...] This is a simple middleware that records a request’s response the first time it’s made in a test, and then replays it in response to requests in subsequent runs.

The handler works by recording the responses from the API (ex: the JSON response data) and records them to files (again, JSON). A one-line call turns the "recording" on and points to a directory where the cached files should be stored. He shows how to use it in the constructor of your Guzzle client, setting it up as the "handler" for the requests. He also includes an example of a few unit tests that make use of the recording feature to check the response of a /test endpoint.

tagged: guzzle http client vcr recording response json cache handler

Link: http://daveyshafik.com/archives/69384-guzzlehttp-vcr.html

Matt Stauffer:
Login Throttling in Laravel 5.1
Aug 03, 2015 @ 08:35:57

Matt Stauffer has posted the eleventh part in his series looking at new features of the latest release of the Laravel framework (well, version 5.1). In this tutorial he shows you how to setup and configure the login throttling for your Laravel-based application with the help of the Laravel Throttle package.

Whether or not you know it, any login forms are likely to get a lot of automated login attempts. Most login forms don't stop an automated attack trying email after email, password after password, and since those aren't being logged, you might not even know it's happening.

The best solution to something like this is to halt a user from attempting logins after a certain number of failed attempts. This is called login throttling, or rate limiting. Graham Campbell wrote a great package called Laravel Throttle to address this in previous versions of Laravel, but in Laravel 5.1 Login throttling comes right out of the box.

He shows how to use the ThrottleTrait in your AuthController to have some of the "behind the scenes" work done for you. He shows you how to update your view to relay the possible error message back to the user (and includes a quick screencast of the result). He ends the post with a quick look at what the throttling functionality is doing under the covers: creating a temporary cache item based on username+IP address as a "lock" indicator. Finally, he points out two properties you can find on the auth controller to give a bit more detail on the current configuration: lockout time and max login attempts.

tagged: laravel login throttle tutorial authcontroller laravelthrottle package cache username ipaddress

Link: https://mattstauffer.co/blog/login-throttling-in-laravel-5.1

Cees-Jan Kiewiet:
Composer cache on Travis
Jul 29, 2015 @ 08:46:52

Cees-Jan Kiewiet has posted an article covering the cache directive on The popular Travis-CI continuous integration service and how it can have an effect on your builds.

Ever since the Test lowest, current, and highest possible on Travis post I wanted to dive into caching composers cache and vendor on Travis. My experiments started the day after that post.

He starts with an example of a simple .travis.yml build configuration that includes the cache directive, showing the caching of entire directories. He points out that, while this can speed up builds, it also comes with a few problems - one being that cache inconsistencies could cause unintended side effects when major changes are made. He points out that most of these risks are worth the gain, though. He's seen a gain of around 40 seconds for a normally 50 second job.

tagged: composer travisci cache configuration caveats

Link: http://blog.wyrihaximus.net/2015/07/composer-cache-on-travis/

SitePoint PHP Blog:
Speeding up Existing Apps with a Redis Cache
Jul 28, 2015 @ 10:27:06

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.

tagged: speed performance redis cache tutorial introduction predis phpiredis

Link: http://www.sitepoint.com/speeding-up-existing-apps-with-a-redis-cache/

Luciano Mammino:
6 Rules of thumb to build blazing fast web server applications
Jul 28, 2015 @ 09:48:33

Luciano Mammino has posted six tips for blazing fast web applications to his site. These tips aren't as much specific to the code (though they're related) as they are general good practices around architecture, development work and common issues.

In this post I will try to highlight some of the most common principles that you have to take under consideration when you want to achieve a great level of performance while building a web application (specifically on the backend part). I believe the concepts discussed here can be applied to any language and framework even if, due to my specific experience, I will mention some examples, design patterns, conventions and tools that are mostly used in the PHP world.

His post lists out six main rules along with some description and links to other tools for each:

  • Avoid premature optimization
  • Do the minimum amount of work to solve the problem
  • Defer the work you don't need to do immediately
  • Use cache when you can
  • Understand and avoid the N+1 query problem with relational databases
  • Prepare your app for horizontal scalability when possible

There's lots of good tools mentioned here so find one that fits your needs and helps solve the issue. There's also some good articles mentioned, giving more information about a particular topic or other perspectives on how to solve it a different way.

tagged: tips rulesofthumb fast web application optimize work cache nplusone scale horizontal

Link: http://loige.co/6-rules-of-thumb-to-build-blazing-fast-web-applications

Freek Van der Herten:
Speed up a Laravel app by caching the entire response
Jul 20, 2015 @ 08:12:55

Freek Van der Herten has written up a tutorial for his site showing the Laravel users out there how to cache their entire response to speed up the overall performance of their application.

A typical request on an dynamic PHP site can do a lot of things. It’s highly likely that a bunch database queries are performed. On complex pages executing those queries and hydrating them can slow a site down. The response time can be improved by caching the entire response. The idea is that when a user visits a certain page the app stores the rendered page.

With a little help from his package it's easy to enable. Just install the package, add the service provider and you're ready to go. All successful responses will be cached unless told otherwise and cache files will be written out to files by default. He does point out that caching like this, while handy and a nice "quick fix" shouldn't be used in place of proper application tuning methods though. He also links to two other external technologies that could be used for the same purpose: Varnish and Nginx's own cache handling.

tagged: laravel application response cache output serviceprovider package

Link: https://murze.be/2015/07/speed-up-a-laravel-app-by-caching-the-entire-response/

Essential Macro Optimizations to Improve PHP Performance
Jul 09, 2015 @ 10:19:16

The Tideways.io blog has posted a set of four macro-optimizations you can do to help improve the overall performance of your application. Note the "macro" here, not "micro", so these are larger, more platform-level changes.

This blog post describes four macro-optimizations for PHP applications that are essential to consider before investigating other possible optimizations. [...] While its fun chasing after small micro optimizations, often it is debatable if the developer time is well spent. After all I/O is the more important bottleneck in almost every application. [...] But its much more efficient to fix the big issues first. The changes I present in this post can be done quickly and their gains can be massive.

The four suggestions he makes cover different areas of a standard application:

  • Upgrade PHP to a recent version
  • Use accelerator such as APC or OPCache
  • Close Session for Writes
  • Don't run XDebug in Production

Each tip comes with a bit of background on why it's a good idea and some have links to other resources supporting the change or update proposed.

tagged: macrooptimization performance application version opcode cache session write xdebug

Link: https://tideways.io/profiler/blog/essential-macro-optimizations-to-improve-php-performance

BitExpert Blog:
Think About It: PHPExcel Performance Tweaks (Part 1)
Jul 07, 2015 @ 10:34:21

Florian Horn has posted the first part of a series of performance tweaks for using PHPExcel to work with Excel spreadsheets and CSV data.

A few weeks back I covered a small article about a CSV-Tool optimized for memory usage and additionally tweaking performance. Our performance optimization sprint contained the improvement of read file data, processing and persist it. While the file data is relatively small referred to the file size, the amount of data sets can vary between 5.000 and more then 40.000 entities on an average, but may be a lot more in some cases.

This article is the first of a three-part series and describes how we tweaked PHPExcel to run faster while reading Excel and CSV files.

In this first part of the series he goes through three different tips to improve some of the basic performance:

  • Cache Cell Index in Memory
  • Iterators and GC Optimization
  • Use Custom Read Filters

You can find out more about the PHPExcel library on the project's main page.

tagged: phpexcel performance tweak series part1 cache iterators filter

Link: https://blog.bitexpert.de/blog/think-about-it-phpexcel-performance-tweaks-part-1/

Simon Holywell:
Memoization or function cache
May 18, 2015 @ 11:09:17

Simon Holywell's latest post shares an interesting feature of PHP's static function handling that lets you cache the results of a function call to improve performance.

A little known feature of PHP’s static keyword is that it allows for memoization or function caching. This is a process whereby a functions heavy lifting can be cached so that subsequent calls are faster. It is possible to store any value in a memoized way such as arrays or even objects. This is done without any external side effects - that is to say that the code calling the function will require no changes to support memoization.

He includes an example of this in action, showing the use of a "static" keyword on a variable over two function calls. He goes through and explains how it works and the flow of the simple function. He builds this up a bit and shows the same functionality in the handling (and parsing) of a JSON document. He then gets more into the "real world" usage of this kind of static handling, pointing out that it can be very useful for caching without the need for an external service (like memcache or redis). His final example shows the caching of a function call using the same method and dependent on the arguments provided.

tagged: function cache static example tutorial memoization

Link: https://www.simonholywell.com/post/2015/05/memoization-or-function-cache/

SitePoint PHP Blog:
Exploring the Cache API in Drupal 8
Feb 26, 2015 @ 11:41:45

On the SitePoint PHP blog today there's a new tutorial (by Daniel Sipos) talking about the Drupal 8 cache and showing how to use it in an example, caching the latest post data pulled from the Drupal content.

Drupal 8 comes with many improvements over its predecessor we have grown to both love and hate. Next to prominent systems such as Views in core, configuration management or a useful translation service, there are also less known changes but that are equally important to know and use. One such improvement has been the cache API that solves many performance problems we have in Drupal 7.

They start with a basic introduction to the new cache handing and how the caches are separated out into different "bins" rather than all stored in one place. He includes sample code showing how to: save data to the cache, getting information back out and invalidating the cache to be handled by garbage collection. He also covers the cache tags, a feature that allows you to "tag" items across multiple caches and remove/invalidate them all at the same time. He wraps up the post getting into the more practical example showing the caching at work in a controller caching the contents of the posts to the Drupal site.

tagged: drupal cache drupal8 tutorial introduction improvement

Link: http://www.sitepoint.com/exploring-cache-api-drupal-8/