In a recent post to the Hackernoon site, Sergii Shanin shares his take on the "PHP is dead" conversations and posts out there with the expected "Viva le PHP!" (long live PHP!) following it.

The fracas over Gutenberg and WordPress is the latest installment in the death of PHP. Take a deep breath everybody. Let’s ignore the trolls and take a look at what Mark Twain, Fidel Castro and PHP have in common?—?and more to the point, why PHP is still a reasonable choice for startups and small businesses.

t looks like ‘PHP is dead’ blog posts started cropping up in 2011 (let me know if you find older ones). If you search around Medium and the coding bootcamps that are popping up like mushrooms, the only common denominator is that everyone hates on PHP or simply ignores it. Apparently, it’s impossible to code in PHP with an oiled beard and ironic t-shirt while drinking overpriced coffee.

He shares two of the most wide-spread myths about PHP - that it's slow and that it can't scale - and dispels them. He then goes through some types projects where PHP "shines" including content driven websites and e-commerce sites. He shares some the "business sense" around choosing PHP, the perspective senior PHP developers bring to teams and projects, and the seeming "nine lives" of PHP.

On the "Oh Dear!" service's blog there's a recent post covering the use of queues in a Laravel application and how to size and scale them to most effectively use the resources you have.

Laravel offers a convenient way to create asynchronous background tasks using its queues. We utilize those heavily at Oh Dear! for all our monitoring jobs and in this post we'll share some of our lessons learned and what we consider to be best practices.

The post starts out with an introduction to queues and their handling in Laravel applications, pushing jobs into workers to be executed. While a simple single-worker queue can handle a decent amount of work, problems can arise as the work grows larger. He mentions splitting up the work as a potential solution and defines the differences between "fast" and "slow" jobs to act as a dividing line for the queues. He also makes the suggestion of single-purpose queues based on types and, finally, mixing in the idea of a better user experience through immediate feedback.

In this new Medium.com post Andrew McLagan shows you some strategies you can use to scale your Laravel application horizontally with the help of Docker and a relatively simple configuration.

Homestead was created by Taylor [Otwell] to ease creation of PHP development environments, it offers developers a consistent environment across projects and is fully compatible with the Laravel ecosphere.

[...] Docker is basically programmable infrastructure, or more simply: Docker lets you create a server environment for your project from a configuration file. [...] I will demonstrate the power of the Docker ecosystem through another tool called Docker Compose a container orchestration tool built upon Docker. This tool enables us to start multiple Docker containers at once from a single configuration file, rather then starting each container individually.

He shows you how to get the required tools installed including a fresh Laravel installation. He then includes the Docker YAML configuration to create the environment, setting up a load balancer, Redis, MySQL and a HHVM instance. He then creates the docker machine to tie all of the pieces together as a VirtualBox VM instance. With this setup up and running, you can then test a URL to be sure the Laravel install is up and running correctly. He then gets to the horizontal scaling part and talks about docker's "scale" functionality making it simple to set up multiple "web" container instances to handle the incoming requests.

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.

On CoderWall.com there's a post sharing some findings about how RockThePost.com scaled PHP to 30,000 concurrent users on Amazon EC2 instances.

RockThePost.com is a LAMP stack hosted on Ec2. We're preparing to be featured in an email which will be sent to ~1M investors... all at the same time. For our 2 person engineering department, that meant we had to do a quick sanity check to see just how many people we can support concurrently.

They have a list of five suggestions/opinions on what has helped them scale out to this level including using Varnish for caching, turning on APC (PHP opcode caching) and using a c1.xlarge EC2 instance. They used Google Analytics and Siege to run their load testing on the "exterior" of the site.

Gonzalo Ayuso has posted yet another helpful Silex hint for those using this microframework and wanting to scale up their applications past the prototype stage - an extension to allow route definition in a YAML configuration.

My idea is to store this information within a Service Container (we will use Symfony’s DIC). For example here we can [define] our routes.yml. [...] We need to implement one Extension for the alias “routes”. We only will implement the needed functions for YAML files in this example.

He includes the code for the extension ("SilexRouteExtension") that can be used to parse the "routes.yml" file to inject the custom routing into your application. This includes the pattern to match, the controller to route it to and the target method. You can also set some requirements like the request method (in this case "GET").

James Fuller has posted a guide to scaling your web application using the nginx web server, memcached, PHP-FPM and APC caching.

We sell an educational product that serves a predictable 15,000 requests per minute for 10+ hours/day, every day. Instead of Apache, we use nginx with PHP-FPM to handle this traffic. This is becoming a very popular setup for many companies with non-trivial traffic, but I have also found success with it in my small 256MB Ram VPS. For various reasons, nginx does a better job with memory and concurrent connection handling than Apache. In this post, I want to talk about some of the reasons you might want to go with this setup.

He talks about some of the efficiency gains that memcache and nginx can give you pretty easily and some of the common uses for nginx, including using it as a reverse proxy. He talks some about Apache's typical request handling and shows the difference between that and how nginx does its "never block, finish fast" handling. He fits in the other pieces - PHP-FPM, memcached and APC - showing how each of them offers their own types of performance gains for different areas of the application.

On DeveloperWorld today there's a new article talking about performance concerns and PHP application (and how your data source might be the problem).

The power of PHP and an RDBMS is the ability to nail the major features of an application with cheaply paid developers in a record amount of time. Unfortunately, the default runtime environment used by PHP is simply an unscalable mess. [...] The truth is that if you have enough servers and enough database servers, you don't have contention. [...] As it turns out, there's a modern solution to the problem: the cloud plus NoSQL. Cloud infrastructure gives us the ability to spin up enough servers, and a NoSQL database enables us to shard our data effectively.

They talk some about why they think PHP's runtine environment is "a dog" based on the non-native pooling of database connections and the lack of a thread-safe environment.

The bottom line: PHP applications are a load on the database due to the constraints of the concurrency model.

He points to the cloud architecture and NoSQL databases as solutions to the scalability problem, providing more scalable resources and flexible data sources.

SitePoint's PHPMaster has a new post today, the third part of a series helping you get your application from "zero to cloud" on an Amazon EC2 setup. In this latest post they wrap things up by showing how to set up the full lamp stack on the remote server. Here's part one and two that lead up to this latest part.

This is the final article in a three part series focused on setting up EC2 as a sandbox for application developers. I assume you have an AWS account with Amazon; if you don’t, please read Part 1 to learn how easy it is to sign up. I also assume you have configured your development environment and installed an AMI; if you haven’t, please read Part 2. In this installment, we’ll learn how to install Apache, MySQL and PHP in our running AMI, and then clone the AMI to make our own.

Included in the post are all the commands you'll need to get the packages installed for PHP, MySQL, Apache 2, PEAR and the PHP command line binary. With all of that installed, they show you how to create an AMI (Amazon Machine Image) to make it easier to scale in the future.

In a new post Justin Carmony looks at what it means to me a "middle-scale website" and has some recommendations for anyone working with their applications and considering things like scalability, overcompensation and finding real results through profiling.

Hopefully at some point, your website is going to get a lot of traffic. Yay, you’ve reached your goal of getting good traffic, but it is soon followed by issues with performance and load. I like to call these the growing pains of a website. So as a web developer, I suddenly have the epiphany of "Hey, I need to scale my website!" What follows next is the biggest mistake a web developer can make: They start looking at articles on how Google scales, or maybe how Facebook manages all of their traffic. This is a mistake! To be brutally honest, you are not Google. You are not Facebook. You are not Twitter. You are a website that receives less than 0.000001% of the traffic that some of the major websites receive.

He includes a "reality check" of the setup behind a popular social site, StackExchange, with comments from their own post about their infrastructure. He talks about things included in a move to "middle-scale" like adding caching, performance tweaking, moving to a multiple server model and using replication.