php[architect] magazine has republished an article from their January 2018 issue by Jeremy Dorn that covers PHP sessions in-depth.

HP Sessions are often taken for granted. A session is a magic array which persists across page loads and holds user-specific data. It’s a fantastic and integral part of most web applications. But when misused, sessions can cause substantial security holes, performance and scalability problems, and data corruption. A deep understanding of sessions is vital to production web development in PHP.

The article covers various topics around PHP sessions and their use including security, performance and scalability. It also covers a few additional topics like serialization of data, session locking and intelligent auto-merging of sessions on the backend. Check out the full article for descriptions of each and some code examples to help show them in action.

The QaFoo blog has written up an interesting post looking at languages and scalability and some of the constraints that can come along with them.

Micro-Services or any set of small services are common again right now. While it can make a lot of sense to use a dedicated service for a well defined problem those services are sometimes used just to play with a different server software. While it is pretty obvious for most that selecting the right database is important the same is true for selecting the right language (virtual machine) for the job.

There are different types of services or server applications where different types of virtual machines (executing the opcodes / bytecode of the compiled source code) make more or less sense. What are the criteria we should base such a decision on and which language should we choose when?

As their primary work is related to PHP, they focus in on it. They talk about why PHP has become such a popular language (the "LCoDC$SS" acronym) and why it fits in with HTTP's statelessness perfectly. On the flip side, they also talk about when it doesn't make sense to use PHP - mostly centering around what would take long-running PHP processes. They then compare this to a similar setup with other languages like Node.js, Go and Java (and how well those scale themselves).

In a new post to his site (also posted on the Zend Developer Zone) Alejandro Celaya looks at scalability with Zend Expressive, a lightweight framework from Zend, the creators of the Zend Framework.

I've been working with some different frameworks lately. One of them is Zend Expressive, and I've come to the conclusion that I don't need to choose between different frameworks; depending on the project, Expressive always fits my needs and scales from small projects to bigger applications.

He starts off by looking at the "microframework approach" that Zend Expressive takes, making it easier to get up and running for smaller applications. He points out that this setup is fine when the application is small, but what happens as it grows - it just wouldn't scale well and be manageable. He talks about the setup he uses for larger scale applications, moving the configuration to dynamic config files and making use of more complex dependency injection. He also talks some about modularity in applications, the "middleware paradigm" and how he set up controller-style dispatching (versus just the default closures method).

In his new post Michael Kimsal shares some of his thoughts about framework benchmarking especially in the context of speed.

I’ve followed the techempower benchmarks, and every now and then I check out benchmarks of various projects (usually PHP) to see what the relative state of things are. Inevitably, someone points out that “these aren’t testing anything ‘real world’ – they’re useless!”. Usually it’s from someone who’s favorite framework has ‘lost’. I used to think along the same lines; namely that “hello world” benchmarks don’t measure anything useful. I don’t hold quite the same position anymore, and I’ll explain why.

He goes on to talk about the purpose of using a framework and what kind of functionality they should provide. The usefulness of a framework is measured in what tools it provides and how easy it makes them to use. Benchmarks are only about speed, performance and overhead.

What those benchmark results are telling you is “this is about the fastest this framework’s request cycle can be invoked while doing essentially nothing”. [...] These benchmarks are largely about establishing that baseline expectation of performance. I’d say that they’re not always necessarily presented that way, but this is largely the fault of the readers.

He refutes some of the common arguments about increasing performance of an application using a framework (like "just throw hardware at it"). He points out that, even with other improvements, it may come to a point where your framework of choice has become too slow and you need to move on. Think about maintainability too, though, and what you're switching from or to when considering making a move.

Along with their recent announcement about returning to the world of print, [php]architect has also released their October issue. This issue includes articles like:

• Automating Resource Concatenation, Optimization, and Caching
• Zend Server: Not Just a PHP Stack
• App Engine on PHP: An Introduction
• PHP and Varnish: Getting the Best from Your Web Servers

There's also a new column introduced by Aaron Saray talking about some things you can do to remove the fear of "ever showing your code again". You can pick up this issue (the last digital-only one) directly from the [php]architect site.

The DPC Radio site has posted their latest recoding from last year's Dutch PHP Conference (2012) with Thijs Feryn's talk Scalability Issues: Cure First, Prevent Later.

The "it works on my machine" mentality has resulted in numerous face palm moments. This is even more painful when a your app is under heavy load due to a marketing campaign. With some minimal code changes and some smart utilities, you can maximize your scalability and performance. Keywords: Varnish, PHP-FPM, Nginx, APC, CDN, Gearman, Memcached and a proper server setup. I'll show you how you can make a slow app with a crappy code base go mighty fast on one and even multiple servers. The focus of this talk is to cure first and eventually learn and prevent.

You can listen to this latest episode either through the in-page player or by downloading the full mp3. You can also subscribe to their feed to get the latest podcasts episodes as they're released.

Hugh Williams has a new post with his recap of the "PHP at Scale" panel from this year's PHP UK Conference.

The good news was that Rasmus and Nikolay couldn’t see any reasons why PHP was particularly challenging. What we saw were general challenges in scaling applications to large traffic volumes – and that’s pretty much where the panel discussion went. Here's a few key points from the discussion.

Highlighted points included: removing bottlenecks to help performance (simple in theory, hard in practice), the fact that PHP should never be the bottleneck, the "odd direction" of HipHop, challenges/growing pains in moving from startup to a large web property. There was also a less technical discussion about "scaling teams" and finding the right (motivated) people to do the job.

On the PHPFog blog there's a recent post explaining their service in a bit more detail and how it provides the PHP applications out there with a huge amount of scalability that a traditional virtual server can't.

PHP Fog is a new type of hosting provider for PHP applications developers to build applications the good old-fashioned way but with easy scaling, reliability, speed, and easy deployment/management compared to traditional shared/dedicated hosting.

They look at a few situations where scalability can play a key role - traffic surge, growth leads to performance degradation and underutilized servers - and how the answers to these issues are best described as "scaling up", "scaling out" or scaling down", all things that more traditional hosting doesn't do well. Cloud-based platforms, like PHPFog (or Orchestra) can give you that high availability you need, so no matter the situation.

On StackOverflow a question was asked about how to tweak and tune the performance of a Kohana-powered website. The result was a detailed answer from Pascal Martin that can be applied to just about any kind of web application out there, not just ones written in PHP.

Here are some points that come to my mind when talking about performances, scalability, PHP, ...First of all, there are many aspects/questions that are to consider : configuration of the server (both PHP, MySQL, and system) ; you might get more help about that on serverfault, I suppose, PHP code, database queries, using or not your webserver? Can you use any kind of caching mechanism ? Or do you need always more that up to date data on the website ?

He goes on to give tips about using a reverse proxy (like Varnish), using an opcode cache, caching data as well, profiling and optimizing SQL queries. He finishes it off with a more specific look at Kohana and how you can use some of its built in tools to accomplish these same goals.

On the Ibuildings techPortal today there's a new post by Sam de Freyssinet about a slight modification to a well-known pattern (MVC) by adding some scalability - the Hierarchical-Model-View-Controller pattern.

It can also be very costly in time and resources to re-architect software that not scaled well. Ideally applications should grow organically as required and without large sums of money being exchanged in the process. [...] The Hierarchical-Model-View-Controller (HMVC) pattern is a direct extension to the MVC pattern that manages to solve many of the scalability issues already mentioned [in this post].

He talks about the benefits of the HMVC style and how its multiple parts work together and how it promotes code reuse more than the traditional MVC pattern. Some sample code is included so you can get your hands dirty with more than just the concepts behind the pattern including a more real-world example, their service (Gazouillement) that works similarly to twitter.