It has been just over a year and a half since the team at TechDivisionGmbH were interviewed here on Sitepoint about their paradigm changing PHP application server system called appserver.io. At the time of the interview, appserver was just breaking out as an alpha. Since then, a lot has happened and appserver is now GA as a production system, currently in version 1.0.6, with version 1.1.0 on the horizon.
You’re probably asking, “Why is appserver paradigm changing?”
The answer is, because it tackles the last frontier of PHP application development: high performance for large applications from a server resource optimization and collaboration perspective. This is the realm of PHP development which a good number of professional PHP developers have been calling for, like Manuel Lemos in his “PHP7 Features and Release Date” blog (see the section about a “Standalone Multi-threading Web Server”) and Fabien Potencier, father of Symfony, in his presentation “My Take on PHP”, where he notes he is also working on such an application server solution himself. Well, look no longer Fabien, we already have a really good solution with appsever.io.
Appserver Still Needs the Developer
Although the potential is within appserver to offer more performance and better collaboration between webservers in a web application environment, it cannot do it alone. It also requires new thinking from the PHP developer. It is this different perspective on solving problems, which we will dive into, with this 3 part series.
In this first part, we will go through very high level concepts that make appserver special and get you started with your first installation. In Part 2, we will go over the components appserver offers out-of-the-box in detail. And finally, in part 3, we will run with some use cases given to us through the example app provided in the installation package.
The overall goal of this series will be to get your perspective opened to the new world of a possibly more performant application system with PHP and appserver and how it requires changes in development thinking and in some cases workflow.
Threads and Threading
You might understand threading as the technology which allows modern computers to do multiple things at once. This is correct and where the term “multi-tasking” actually comes from.
Threading or multitasking in the PHP world is actually quite rare. In the days when PHP was created, threading in computers wasn’t really much of a concern. PHP has stayed in line with its single-threaded architecture, also called “shared nothing” architecture, even to this day.
What most people don’t realize, however, is that PHP is actually built to also support multitasking. This gem of functionality was basically unknown until Joe Watkins created pthreads, a powerful PHP extension which allows a developer to build threaded applications in PHP. It is this functionality, among other important features, which appserver implements to support the development of threaded applications.
Still, you might be like me and wondering why this threading stuff makes any kind of difference for a PHP application. For that, we must actually take a look at a bird’s eye view of today’s webserver technology.
The Standard PHP Web Server Scenario
For us PHP developers, in the context of webservers, the thought of threading is far from our minds. That’s because the webservers and/or PHP process managers themselves are actually doing that work. You might be saying, “Great! That is one less problem for me to worry about” and you’d be absolutely correct in saying that. However, this handling of threading at the webserver / PHP process management level comes with a pretty big cost. Below is an animation of the current way PHP runs its processes with a webserver like Nginx.
The threading is done by duplicating, building, and destroying the same things over and over again, for each request the server receives. You might be thinking, this doesn’t look so bad, right? To see the real cost, we actually have to dive in a bit deeper and get into the “build/destroy” part of the process.
This image shows what a normal, usually larger application supported by some MVC framework must do for every single call made to it. We can argue about the sequence of events. However, what is important to notice is, there is a lot of work being done only to be completely destroyed after the response is sent. As mentioned above, this is a lot of duplicated and wasted effort for the machine. This waste = lost performance!
Now let’s look at an appserver scenario from that bird’s eye view.
The Appserver Scenario
As you can see, nothing all too different. However, with appserver, the webserver is written in PHP and is an integrated part of the app. Now you have one less worry and, if necessary, you have more control over what is happening within the webserver. Also due to the webserver being integrated, a common part of modern PHP frameworks that deals with the HTTP requests and responses is basically put into its proper place in the stack, within the webserver itself.
This alone would be a great improvement over the standard webserver, however, it gets even better. Let’s look at the next level down, as we did earlier.
Notice how certain parts of the programming are no longer destroyed. What is destroyed or not is now in the developer’s hands. It means the developer can, for instance, allow the bootstrapping process to stay “threaded” and never have to be rebuilt for each request. The bootstrapped app is always ready to go.
A Difference in Thinking
When the difference appserver makes went “click” in my mind, this is about how I felt (click to view).
Having fun? Oh yes! And the most important part of the movie is what God says after this scene.
Parting your soup is not a miracle, Bruce. It’s a magic trick. A single mom who’s working two jobs and still finds time to take her kid to soccer practice, that’s a miracle. A teenager who says “no” to drugs and “yes” to an education, that’s a miracle. People want me to do everything for them. But what they don’t realize is they have the power. You want to see a miracle, son? Be the miracle.
Ok, maybe that is a bit melodramatic, but for sure, the “miracle” or the ability to make parts of your program basically persist within the server itself is a powerful tool to add performance to your applications. It allows you, as the PHP developer, to think differently about how an application can work better and faster. Though, as the rule goes…
With great power comes great responsibility.
In other words, although you may have new powers at hand with appserver, you must also understand the meaning of those powers, how to use it and also the possible bad side-effects that can happen, when you aren’t careful. We’ll get into these things in more detail in the later parts of the series.
For now, let’s get you up and running with an appserver instance.
Installation and Getting Started
Appserver comes ready to install for a good number of operating systems. A recommended approach to local development is to use a Vagrant VM built with Virtualbox. Or you could run with Bruno’s quick tip to build his homestead box. We will be installing the Debian Wheezy version of appserver and you will actually only need the running OS.
After you have installed the VM and it is running, SSH into it and carry out these commands as the super-user.
echo "deb http://deb.appserver.io/ wheezy main" > /etc/apt/sources.list.d/appserver.list wget http://deb.appserver.io/appserver.gpg -O - | apt-key add - apt-get update apt-get install appserver-dist
The installation process is just as simple with the other OSes too.
No matter which method you used to install appserver, you should be up and running with appserver. The installation routine automatically starts the appserver process after installation is complete. To check this quickly, enter the following.
service appserver status
You should see a running appserver.
[ ok ] appserver is running.
A small note: If you reboot your VM, appserver will not run automatically. If you’d like to have it running at reboot, you need to set up the service to start at boot time. With Debian, you can carry out this command.
update-rc.d appserver defaults
If you want appserver to actually serve up your web applications in general, you can also change appserver’s listening port to
80. To do this, you now need to make a simple change to the core configuration file in appserver. Go to /opt/appserver/etc/appserver and you will find a file called appserver.xml. This is the core configuration file for the webserver, much like Apache’s httpd.conf or Nginx’s nginx.conf files.
Open it up in your favorite editor and find these lines.
<server name="http" .... <param name="admin" type="string">email@example.com</param> <param name="transport" type="string">tcp</param> <param name="address" type="string">0.0.0.0</param> <param name="port" type="integer">9080</param>
If you are just experimenting, it would be best to leave the port as is. This way, you can play with appserver next to any other PHP projects.
There is a lot more you can do with the webserver and this configuration file. We’ll be going over some of the possibilities in the later posts.
If you did make any changes to the configuration file, you’ll need to restart appserver in order for the changes to take effect.
service appserver restart
If all went well, you should be able to enter your VM’s IP address with
http://10.10.10.10:9080/example, and you should see the starting page of the example app already installed in appserver.
That’s it! You now have a running appserver. In the next part of the series, we will dig into the features of appserver and see what it offers out of the box. Stay tuned for more!
Scott has been supporting customers using powerful PHP applications like Wordpress, vBulletin and Xenforo in his spare time for over 13 years. His company (also ran as a hobby) was the distributor for the German version of vBulletin for 12 of those years. The past year and a half, he's been taking on more of the developer roll and is now learning about new technologies for his new project Skooppa.com. His goal at Sitepoint is to share these new technologies with the PHP community.