PHP
Article

Appserver – a Production-Ready PHP-Based Server

By Scott Molinari

Mastering Appserver

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 Community Edition is licensed under the Open Source License 3.0. The TechDivsion team also offer a Professional Edition and an Enterprise Edition too.

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).

ScreenShot

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">info@appserver.io</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 :9080/example, like 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!

  • Joeri Sebrechts

    This article makes quite a convincing case for stateful application servers, the application server design that is common in the java world. Such an app server is the last marker on the road of turning PHP into Java. As a counterpoint, I’d like to make my own case why stateful application servers can be a poor design for high-performance systems.

    The fundamental issue with stateful application servers is that they require the programmer to reason about program correctness in multi-threading and multi-machine scenario’s. What happens when an application server node keels over and its state is lost? Can that state be reconstructed and the request be restarted? Is it acceptable to expose the problem to the user as an error message? Or, just try reasoning about a code upgrade where the application server needs to be restarted to discard the object state in memory. Stateful application servers optimize for the machine, reducing overhead in memory and process management, at the expense of introducing more cognitive overhead for the programmer. Things execute faster, but they take longer to write correctly. In practice things end up being written incorrectly, and an unreliable system results. Or to put it differently, state across requests is the enemy of high-performance systems that scale reliably and easily, because it complicates the design of the code, and state in the application server doubly so, because application servers unlike databases are not designed to reliably manage this state across nodes in the cluster.

    State belongs in a database, designed for the purpose of persisting data in a scalable and high-performance way (which may exclude some popular database choices). Any attempt to reliably keep state in an application server will just end up reinventing the failover logic and performance tricks of purpose-built databases poorly. Every request to the server should build up the world from scratch because that is the only way in which requests can be restarted in a reliable way when an app server node falls over. If individual requests are slow due to the overhead of building up the world for that request, the solution is not to share the world between requests, but to reduce the size of the world. Use less code, build simpler systems.

    You might not be convinced, but I hope at the very least I’ve made the case that stateful application servers are not necessarily an automatic improvement on the design of PHP. They may be a step back. The question is only one of degree: how often are they a step back; and how big a step is it?

    • Tùng Red

      Totally agree with you. I had moved to Java because I liked the way it’s execute the app code as the article told above. Later, I realized that it’s introduced a lot of overhead to me. Instead of caring about how making our app better, I consumed a lot of time to care about multi-threaded scenarios, memory leaks. HHVM are using a similar kind of execution strategy for production mode and it’s more battle tested.

      There are a lot of optimization methods to improve the performance of PHP apps without moving to this programming paradigm.

      Nice comment (y)

    • http://www.skooppa.com s.molinari

      Thank you for the concise comment.

      I’d like to slightly disagree with your perspective. I only say slightly, because I can’t completely disagree with what you are saying, as it does have merit. State in the server has its complexity and complications. It isn’t terribly evil and also doesn’t mean a step backwards either IMHO.

      Can we agree that state has to be stored somewhere, and if it is in the memory of the server itself, it is the fastest place to retrieve it? If a caching system dies too, the cache is also lost. So, the smart developer would only store state in the server or in a cache, which can be lost and it not be a total loss for the application’s functionality. The cached data just needs to be rebuilt.

      Appserver also has features, which deal with sharing of state across appservers, like checking to see if a stateful bean is on the same server or on a different server. So, this is a bit of the cognitive load you mentioned yes. But, it is the same as asking if cached state has been stored in a cache. The thinking is a just bit different. Oh, and there is nothing to stop you from using an external cache either. And you should most definitely still use a database for the state that must persist safely.

      Can you also agree with me, that asynchronous functionality within PHP is a problem needing a solution? This is why, for instance, PHP7 is getting better asynchronous I/O capabilities. This is the realm of performance improvement the devs I mentioned in the article are looking for and appserver delivers. I’d say that is a clear step forwards.

      Would you also agree, it is impossible to “thread out” PHP work within the context of an Nginx or Apache worker? The thread they are on or the thread that is given, is the thread you get as a PHP developer and often the work required of the thread could be much better split over multiple threads? I think, if this weren’t the case, then pthreads would never have been invented. Appserver is a logical extension of that threading capability. Something you won’t find anywhere else.

      Lastly, as I mentioned above, appserver does take some of the cognitive load, or rather “bottles it” into a handy server system and off the hands of the developer. I cannot deny there is an added cognitive load for the developer. It is what I meant with, “With great power, comes great responsibility!” :) So you are absolutely right about the cognitive load. However, I’d say the cognitive load is fairly close to what you have, like with any of the bigger PHP frameworks. It’s just that some of the consequences of missing knowledge or doing things wrong can be worse with appserver, than what you would have should you be missing knowledge or should you do things wrong with a framework. There are most definitely do’s and don’ts with appserver, which need the developer’s fullest attention. I’ll be sure to point out some of the critical don’ts in my next article.

      Thanks again for your insight!

      Scott

      • Joeri Sebrechts

        I don’t disagree with much of what you said. I’m sure appserver eases the complexity of doing multi-threaded programming with PHP. I think we have a difference of opinion on whether you should be doing multi-threaded programming in PHP at all. I’ve dabbled enough with threads in Java to know that it quickly exceeds my capacity to reason out how the system works. That’s one of the reasons that I prefer PHP to Java for writing web applications. The concurrency model is simple enough that I don’t have to spend much time thinking about it, even when involving sessions (which I’m stepping away from, because they’re just another form of state on the app server and more trouble than they’re worth).

        For me the appropriate concurrency model is the one adopted by JavaScript: isolated workers handling messages asynchronously yet serially (inside each worker). It’s true that PHP is not ideal right now. You can use workers handling messages, and I do, but there is no standard for the interface (there’s a job for PSR here), and unlike JavaScript you can’t dispatch something asynchronously within the same process (well you can, but it’s so ugly to do that I don’t). I would like to see PHP introduce some facilities for async programming, but do it like JavaScript (async,but not multi-threaded).

        I would also agree with the notion that with the big PHP frameworks introducing much complexity anyway, and with so much cached data present in most apps, the use of persistent logic in an app server doesn’t complicate things very much beyond that. However, I think the design of the big PHP frameworks is optimized for running in an app server and that this in turn creates the need for cached data. They need to load big class libraries before they can handle a request, hundreds or even thousands of classes. That design is excellent for Java, but not for PHP. Because every request is so slow to execute, caching becomes all but mandatory, which then produces the need for even more code to handle those caches. A framework design optimized for PHP instead of Java could do away with much of the complexity and most of the need for caching. But this is where I veer off into armchair critic territory, so I should probably shut up until I have code to share to make my case for me.

        • http://www.skooppa.com s.molinari

          On the messaging PSR. Check this out. https://github.com/appserver-io-psr/pms

          The devs at techdivision created a standard for messaging first, then built the interface, and it is what the client dev needs to know about to use appserver’s message queue.

          http://appserver.io/get-started/documentation/1.0/message-queue.html

          You sound like the perfect candidate to fire up appserver and play with it some. :-) I know for sure you’ll have ideas and find deficiencies and have possibly new views, which the appserver dev team would love to know about. I’ve been following and interacting with them over the past few weeks and they are very open and willing to work with anyone who is also willing to be constructive and supportive to them too. I love it, when there is a positive aura around any PHP project trying to break the PHP or web development “molds”.

          Scott

        • http://www.skooppa.com s.molinari

          About the messaging PSR, check this out!

          https://github.com/appserver-io-psr/pms/blob/master/src/AppserverIo/Psr/Pms/MessageInterface.php

          The appserver dev team obviously had the same inclination as you do about this subject. :-)

          http://appserver.io/get-started/documentation/1.0/message-queue.html

          You might want to give appserver a spin. You seem like a perfect candidate to run it through the ringer, as you seem quite knowledgeable and open and can do a lot with it, to then give some really good feedback to the dev team to improve it. I’ve been working with them for the past few weeks and they are really super supportive and open for suggestions. I would say, they have a great understanding about what OSS is all about. :-)

          Scott

      • Joeri Sebrechts

        I don’t disagree with much of what you said. I’m sure appserver eases the complexity of doing multi-threaded programming with PHP. I think we have a difference of opinion on whether you should be doing multi-threaded programming in PHP at all. I’ve dabbled enough with threads in Java to know that it quickly exceeds my capacity to reason out how the system works. That’s one of the reasons that I prefer PHP to Java for writing web applications. The concurrency model is simple enough that I don’t have to spend much time thinking about it, even when involving sessions (which I’m stepping away from, because they’re just another form of state on the app server and more trouble than they’re worth).

        For me the appropriate concurrency model is the one adopted by JavaScript: isolated workers handling messages asynchronously yet serially (inside each worker). It’s true that PHP is not ideal right now. You can use workers handling messages, and I do, but there is no standard for the interface (there’s a job for PSR here), and unlike JavaScript you can’t dispatch something asynchronously within the same process (well you can, but it’s so ugly to do that I don’t). I would like to see PHP introduce some facilities for async programming, but do it like JavaScript (async,but not multi-threaded).

        I would also agree with the notion that with the big PHP frameworks introducing much complexity anyway, and with so much cached data present in most apps, the use of persistent logic in an app server doesn’t complicate things very much beyond that. However, I think the design of the big PHP frameworks is optimized for running in an app server and that this in turn creates the need for cached data. They need to load big class libraries before they can handle a request, hundreds or even thousands of classes. That design is excellent for Java, but not for PHP. Because every request is so slow to execute, caching becomes all but mandatory, which then produces the need for even more code to handle those caches. A framework design optimized for PHP instead of Java could do away with much of the complexity and most of the need for caching. But this is where I veer off into armchair critic territory, so I should probably shut up until I have code to share to make my case for me.

  • Nikola B.

    This article is one of the reasons I lost my trust in Sitepoint completely. The application you’re promoting isn’t any kind of paradigm changing application. The way I see it, a few guys got together and solved the problem they had without thinking “Hey, could it be that other people had this problem and they solved it in a different way?” and they used pthreads extension to have a little bit fun while doing it. An enterprise organization that uses PHP application that’s actually built-in into the web server is nonexistent or its CTO should be replaced. Here are the reasons:

    – the HTTP parser that appserver uses – where’s the proof it’s resilient to classic attack vectors?
    – why would an enterprise use untested server without clustering capabilities versus free ones that work and are proven to work?
    – why would I build in an application into the server itself? It just sounds nasty, much like mod_php is.
    – where’s the text on how appserver optimizes frequently accessed files, such as nginx does?
    – why did you incorrectly state how php-fpm operates? There is virtually 0 gain in performance if one uses php-fpm vs this app. FPM doesn’t do what you wrote *for every request*. It’s actually much smarter than the author leads us to believe
    – there is no paradigm shift here. What exists is just another application whose security cannot be confirmed due to the fact no security auditing has been done on it. There is also no gain doing this. There are web servers such as Mongrel2 that ARE shifting the paradigm.
    – at the point where I need to scale, what do I do with this appserver? nginx lets me round-robin a request to a pool of FPMs, but in appserver’s case I have to do what exactly? Load balancing before requests reach it? DNS round-robin? What about high availability?

    This appserver looks like something fun to play with, but to use it for enterprise? Let’s be serious – in an enterprise environment, it’s rarely performance that matters. The focus is more on high availability and most of all – security.

    Even though the guys behind this project did a lot of work, what’s the point? They solved a problem that didn’t exist. This kind of architecture is what we had back in 90s – let’s couple everything together and come up with a bad reason why we did it. I’m sorry but this product looks like a “hey, we heard of pthreads and did something with it”.

    I apologize if my comment is rude, but that’s how I view the facts. There is exactly 0 reasons to use appserver, no matter what anyone says.

    • http://www.bitfalls.com/ Bruno Skvorc

      > This article is one of the reasons I lost my trust in Sitepoint completely.

      Harsh. What are the other reasons?

      • Rasmus Schultz

        I for one do not share the excitement, but this does nothing to my trust in Sitepoint – I don’t agree with everything they post, but I think, neither does any developer with opinions of his own; perspective is always useful, and you get that if you listen to different points of view, even when you disagree.

        And I do see this as “paradigm changing” *in the PHP world*, though obviously it’s not a new paradigm to someone who has worked with Java or other platforms that implement a similar paradigm. I also can’t say that this is a paradigm I want – it’s alluring at first, and probably more so to strictly-PHP developers who may have felt a degree of “envy” having had no exposure to that paradigm; my gut feeling is, most of those people will learn a painful lesson, though there’s no saying that’s a bad thing, again, perspective: the more the better, and I won’t discourage Sitepoint from promoting experience.

        It’s also very possible that other (more experienced) developers will be able to solve scalability problems with this, at an acceptable (for them) cost of complexity, some may well have problems they could not solve under the constraints of the normal stateless PHP world paradigm.

        I hope not to be one of those people. I for one enjoy the stateless nature of PHP, and have often wished for that in other languages that don’t have it – I find that it is a very natural fit for the stateless nature of HTTP. The performance and scalability implications are well known to everyone, it’s usually a very well-informed choice, not usually something that crops up as a surprise to anyone late in a project.

        I don’t think anyone’s trying to say this paradigm as “the new PHP”, it’s just different – it has a different set of qualities and a different set of problems. Having one more option that substantially differs from existing options, is a good thing.

        • http://www.bitfalls.com/ Bruno Skvorc

          > neither does any developer with opinions of his own; perspective is always useful, and you get that if you listen to different points of view, even when you disagree

          My thoughts exactly. We’re not claiming to know the one true answer to all questions. We merely do our best to extensively test, analyze and demonstrate as many new technologies as possible, helping others decide whether or not those technologies are worth the effort for them. Some posts will be enthusiastic, others less so, but they’re all just facts with some opinions wrapped around them, not wishful thinking or attempts at mind control.

        • http://www.bitfalls.com/ Bruno Skvorc

          > neither does any developer with opinions of his own; perspective is always useful, and you get that if you listen to different points of view, even when you disagree

          My thoughts exactly. We’re not claiming to know the one true answer to all questions. We merely do our best to extensively test, analyze and demonstrate as many new technologies as possible, helping others decide whether or not those technologies are worth the effort for them. Some posts will be enthusiastic, others less so, but they’re all just facts with some opinions wrapped around them, not wishful thinking or attempts at mind control.

      • Rasmus Schultz

        I for one do not share the excitement, but this does nothing to my trust in Sitepoint – I don’t agree with everything they post, but I think, neither does any developer with opinions of his own; perspective is always useful, and you get that if you listen to different points of view, even when you disagree.

        And I do see this as “paradigm changing” *in the PHP world*, though obviously it’s not a new paradigm to someone who has worked with Java or other platforms that implement a similar paradigm. I also can’t say that this is a paradigm I want – it’s alluring at first, and probably more so to strictly-PHP developers who may have felt a degree of “envy” having had no exposure to that paradigm; my gut feeling is, most of those people will learn a painful lesson, though there’s no saying that’s a bad thing, again, perspective: the more the better, and I won’t discourage Sitepoint from promoting experience.

        It’s also very possible that other (more experienced) developers will be able to solve scalability problems with this, at an acceptable (for them) cost of complexity, some may well have problems they could not solve under the constraints of the normal stateless PHP world paradigm.

        I hope not to be one of those people. I for one enjoy the stateless nature of PHP, and have often wished for that in other languages that don’t have it – I find that it is a very natural fit for the stateless nature of HTTP. The performance and scalability implications are well known to everyone, it’s usually a very well-informed choice, not usually something that crops up as a surprise to anyone late in a project.

        I don’t think anyone’s trying to say this paradigm as “the new PHP”, it’s just different – it has a different set of qualities and a different set of problems. Having one more option that substantially differs from existing options, is a good thing.

      • Rasmus Schultz

        I for one do not share the excitement, but this does nothing to my trust in Sitepoint – I don’t agree with everything they post, but I think, neither does any developer with opinions of his own; perspective is always useful, and you get that if you listen to different points of view, even when you disagree.

        And I do see this as “paradigm changing” *in the PHP world*, though obviously it’s not a new paradigm to someone who has worked with Java or other platforms that implement a similar paradigm. I also can’t say that this is a paradigm I want – it’s alluring at first, and probably more so to strictly-PHP developers who may have felt a degree of “envy” having had no exposure to that paradigm; my gut feeling is, most of those people will learn a painful lesson, though there’s no saying that’s a bad thing, again, perspective: the more the better, and I won’t discourage Sitepoint from promoting experience.

        It’s also very possible that other (more experienced) developers will be able to solve scalability problems with this, at an acceptable (for them) cost of complexity, some may well have problems they could not solve under the constraints of the normal stateless PHP world paradigm.

        I hope not to be one of those people. I for one enjoy the stateless nature of PHP, and have often wished for that in other languages that don’t have it – I find that it is a very natural fit for the stateless nature of HTTP. The performance and scalability implications are well known to everyone, it’s usually a very well-informed choice, not usually something that crops up as a surprise to anyone late in a project.

        I don’t think anyone’s trying to say this paradigm as “the new PHP”, it’s just different – it has a different set of qualities and a different set of problems. Having one more option that substantially differs from existing options, is a good thing.

      • Rasmus Schultz

        I for one do not share the excitement, but this does nothing to my trust in Sitepoint – I don’t agree with everything they post, but I think, neither does any developer with opinions of his own; perspective is always useful, and you get that if you listen to different points of view, even when you disagree.

        And I do see this as “paradigm changing” *in the PHP world*, though obviously it’s not a new paradigm to someone who has worked with Java or other platforms that implement a similar paradigm. I also can’t say that this is a paradigm I want – it’s alluring at first, and probably more so to strictly-PHP developers who may have felt a degree of “envy” having had no exposure to that paradigm; my gut feeling is, most of those people will learn a painful lesson, though there’s no saying that’s a bad thing, again, perspective: the more the better, and I won’t discourage Sitepoint from promoting experience.

        It’s also very possible that other (more experienced) developers will be able to solve scalability problems with this, at an acceptable (for them) cost of complexity, some may well have problems they could not solve under the constraints of the normal stateless PHP world paradigm.

        I hope not to be one of those people. I for one enjoy the stateless nature of PHP, and have often wished for that in other languages that don’t have it – I find that it is a very natural fit for the stateless nature of HTTP. The performance and scalability implications are well known to everyone, it’s usually a very well-informed choice, not usually something that crops up as a surprise to anyone late in a project.

        I don’t think anyone’s trying to say this paradigm as “the new PHP”, it’s just different – it has a different set of qualities and a different set of problems. Having one more option that substantially differs from existing options, is a good thing.

      • Rasmus Schultz

        I for one do not share the excitement, but this does nothing to my trust in Sitepoint – I don’t agree with everything they post, but I think, neither does any developer with opinions of his own; perspective is always useful, and you get that if you listen to different points of view, even when you disagree.

        And I do see this as “paradigm changing” *in the PHP world*, though obviously it’s not a new paradigm to someone who has worked with Java or other platforms that implement a similar paradigm. I also can’t say that this is a paradigm I want – it’s alluring at first, and probably more so to strictly-PHP developers who may have felt a degree of “envy” having had no exposure to that paradigm; my gut feeling is, most of those people will learn a painful lesson, though there’s no saying that’s a bad thing, again, perspective: the more the better, and I won’t discourage Sitepoint from promoting experience.

        It’s also very possible that other (more experienced) developers will be able to solve scalability problems with this, at an acceptable (for them) cost of complexity, some may well have problems they could not solve under the constraints of the normal stateless PHP world paradigm.

        I hope not to be one of those people. I for one enjoy the stateless nature of PHP, and have often wished for that in other languages that don’t have it – I find that it is a very natural fit for the stateless nature of HTTP. The performance and scalability implications are well known to everyone, it’s usually a very well-informed choice, not usually something that crops up as a surprise to anyone late in a project.

        I don’t think anyone’s trying to say this paradigm as “the new PHP”, it’s just different – it has a different set of qualities and a different set of problems. Having one more option that substantially differs from existing options, is a good thing.

      • Nikola B.

        Bruno, the other reasons I don’t trust Sitepoint is because of a simple fact – people with insufficient knowledge write about topics that they don’t really know about. This spreads false knowledge, and that’s more dangerous than ignorance.

    • Tim Wagner

      Hi Nikola,

      first of all, you are kind of rude and i can’t understand the reason therefore!

      I don’t want to go into details, but we still faced a lot of problems since we’re working with PHP and enterprise applications build upon it. What about long running import processes, asynchronous message processing, caching and all that kind of stuff we had to deal with in our daily business. In our opinion PHP frameworks try to copy Java frameworks more and more, but PHP doesn’t provide the necessary infrastructure. The result is, that frameworks get bigger and bigger and as a result, slower ans slower. HHVM is a good deal, but within the next 2 years the performance boost will be lost by new features provided by the those frameworks. We think it’s time for a new infrastructure solution that also covers middleware functionality and give the frameworks the chance to simply implement fast framework functionality without taking care of a HTTP foundation implementation.

      But i’ll come back to the issues you addressed

      – give us the proof it is NOT resilent against classic attack vectors! If we can find any problems, we’ll fix it and hopefully others help us, because it’s open source

      – you don’t have to build the application into the server, we provide interfaces and applications a strictly separated from the server. But you’re able to use the advantages of stateful application programming. If you don’t like it, keep using the integrated PHP-FPM and you’re all set up

      – we’re not nginx and don’t compare with it, so we don’t optimize frequently accessed files, we only set the correct response headers and we’re still fast with that

      – we can’t seen anything wrong with the PHP-FPM explanation here, please tell us what PHP-FPM is doing so much smarter

      – for sure there is a paradigm shift here, maybe you don’t want so see it and obviously you don’t want to use it. This is still o. k. with us!

      – with the upcoming 1.1 we’ve load balancing functionality built-in, so have a look at the next version

      For sure it is fun to play with it, and that’s amazing we think :). You’re right, performance is not the only feature that matters. The next releases will address high availability. If there are any security issues, it’ll be nice if you can tell us all about.

      We also view the facts, and see many reasons to use appserver.io, beside this, it’s fun using it! I’ve never heard anything about Mongrel2 and someone using it in combination with PHP, but for sure it’ll also be an interesting project and i can’t see any need to talk rude about it!

  • gggeek

    Kind of agree with the other commenters. This looks a lot like a reimplementation of the java application server, only done in php.
    1. it comes with all the problems that that platform has
    2. why not go for existing and proven app servers if that is what best fits the needs of your particular app?

    • Nikola B.

      That’s what bothers me as well – it’s not a paradigm changing software, yet it’s advertised as if it is.

    • http://www.skooppa.com s.molinari

      Could you please note what other app servers there are please?

      Scott

      • gggeek

        I might be lost in translation here… the same wikipedia page which mentions appserver.io has about a dozen app servers just in Java – https://en.wikipedia.org/wiki/Application_server
        Or do you specifically mean ‘php application server’ ?

    • Tim Wagner

      In our business (e-commerce and content-commerce) nearly all enterprise systems are built upon Java solutions, mainly using application servers. So i don’t think, that the Java plattform still has those problems. But PHP tries to copy the best stuff from Java (language, frameworks, libraries) since years and tries to port it to PHP ignoring that Java has a brilliant JVM that allows a lot of stuff that is hard to integrate into the PHP ecosystem.

  • http://www.skooppa.com s.molinari

    Thanks for the comments. I’ll be sure to address them in the upcoming parts as best as possible. For PHP, appserver’s architecture is a paradigm change for sure. Whether or not it is a positive one can and should be up for discussion and I welcome it actually.

    Scott

    • Nikola B.

      It isn’t, I don’t know why you persist in thinking it is. Are you up to speed with current technologies? You can’t call something paradigm change if it goes backwards. This project is PHP going backwards. Architecture? It’s just like Apache with mod_php, except entire thing is PHP.

      • http://www.skooppa.com s.molinari

        I am sorry you see it that way. I’ll do my best to show you there is more to appserver in the later articles.

        Scott

      • Rasmus Schultz

        A paradigm shift doesn’t have to go forwards or backwards, it just means a fundamental shift in approach and underlying assumptions. I don’t see this shift as going forwards or backwards – it’s different, that’s all. It will be better in some ways, and worse in other ways, so which you choose is going to depend on requirements.

        One thing I do see as risky, is that this is “new and shiny” in PHP land, and a lot of people are going to hurl themselves into it, without even analyzing their own requirements first, to determine if it’s really a better or worse fit specifically for their domain! But this is a risk with anything new – if we let risk deter us from trying new things, we’d never try anything new at all.

        I already know this paradigm, it’s merits, and it’s drawbacks, and I for one will sail clear around it, as it doesn’t address any problems for me in my daily work. But it may well address different problems that others are facing. I suppose that’s why both paradigms are still alive and well in the wild.

    • Nikola B.

      It isn’t, I don’t know why you persist in thinking it is. Are you up to speed with current technologies? You can’t call something paradigm change if it goes backwards. This project is PHP going backwards. Architecture? It’s just like Apache with mod_php, except entire thing is PHP.

    • Nikola B.

      It isn’t, I don’t know why you persist in thinking it is. Are you up to speed with current technologies? You can’t call something paradigm change if it goes backwards. This project is PHP going backwards. Architecture? It’s just like Apache with mod_php, except entire thing is PHP.

    • Alex Rock Ancelet

      So, is this faster than Apache or Nginx? Can it execute multiple apps at once hence handle multiple hosts/vhosts ? How do you deploy an app based on a framework with AppServer? Can you benchmark and compare performances between the actual most used configurations for a simple app (like the Symfony demo application, for example, if you use a framework)? How do you plug this to a cache server like Varnish? Redis? How do you handle cache at all?

      These are questions that should be answered before saying AppServer is awesome.

      On the paper, your project sounds awesome, but if it does not revolutionize anything, and is not better than any actual solution, it’s unfortunately worthless :/

      • http://www.skooppa.com s.molinari

        Thanks for the questions. I’ll do my best to cover them in the next parts.

        Scott

      • http://www.skooppa.com s.molinari

        Actually, I’ll answer some of them now. :-)

        Appserver can be used just like any other web server behind Varnish or any other HTTP cache of your choice. You can also connect to anything PHP can connect to for any persistence purposes. In this respect, appserver is just like any other PHP environment. There is a significant difference. With appserver you can “thread out” work across multiple server connections. This is an ability I need to learn myself, but it is there and promises a boost in performance for operations like mass input of data into a database. The ability to spread work asynchronously is actually what caught my attention with appserver.

        And caching can be handled directly in the server itself (or servers) with appserver. It doesn’t have to be loaded out into an external cache at all. I think this can be seen as one of the advantages of appserver actually. But, as Joeri mentioned above, you need to be careful of certain things with this new ability. This is what I’ll cover in the next article.

        Scott

  • http://www.skooppa.com s.molinari

    Yes, PHP.

    Scott

  • Rasmus Schultz

    > we’re not nginx and don’t compare with it

    But you do, on the front page of the website? – there’s a comparison matrix featuring NGINX, Apache, and several others.

    > for sure there is a paradigm shift here

    I agree, it’s clearly a shift, and I think that describes it much more accurately than “revolution”, which is the word used to promote it on the front page of the website. There is nothing revolutionary, to the web world, about bringing an existing, well-known paradigm to PHP; though, arguably, the paradigm is new to PHP, it’s fairly analogous to, say, a car brand introducing an electric vehicle – it’s been done, and I don’t think anybody would call that a “revolution”, though it’s certainly a shift to that brand.

    I do think what you’re doing here is interesting, probably even important, but using words like “revolution” is over-selling it. You could have picked a raft of other languages where this paradigm has been around probably for much longer than the stateless paradigm.

    • Tim Wagner

      Hi Rasmus,

      you’re right, we’ve a comparison matrix on our web page. We try to figure out what the difference is between the systems, because it’s kind of difficult to explain the application server idea in the PHP world and to show people what can be reasons to use one. We don’t want to compare with nginx or apache, they are webservers, although we also have one, this is not our main purpose.

      Again, you’re right ;) We use that word in our website and i’m not completely happy with that. Because i know for sure, it’s not a revolution in the web world, but it may be a revolution in the PHP ecosystem, once it’ll be accepted and used for things it makes sense for. We’ll think about that “revolutionary” word and probably replace it with one that better fits what it is.

    • Tim Wagner

      Hi Rasmus,

      you’re right, we’ve a comparison matrix on our web page. We try to figure out what the difference is between the systems, because it’s kind of difficult to explain the application server idea in the PHP world and to show people what can be reasons to use one. We don’t want to compare with nginx or apache, they are webservers, although we also have one, this is not our main purpose.

      Again, you’re right ;) We use that word in our website and i’m not completely happy with that. Because i know for sure, it’s not a revolution in the web world, but it may be a revolution in the PHP ecosystem, once it’ll be accepted and used for things it makes sense for. We’ll think about that “revolutionary” word and probably replace it with one that better fits what it is.

  • Rasmus Schultz

    > we’re not nginx and don’t compare with it

    But you do, on the front page of the website? – there’s a comparison matrix featuring NGINX, Apache, and several others.

    > for sure there is a paradigm shift here

    I agree, it’s clearly a shift, and I think that describes it much more accurately than “revolution”, which is the word used to promote it on the front page of the website. There is nothing revolutionary, to the web world, about bringing an existing, well-known paradigm to PHP; though, arguably, the paradigm is new to PHP, it’s fairly analogous to, say, a car brand introducing an electric vehicle – it’s been done, and I don’t think anybody would call that a “revolution”, though it’s certainly a shift to that brand.

    I do think what you’re doing here is interesting, probably even important, but using words like “revolution” is over-selling it. You could have picked a raft of other languages where this paradigm has been around probably for much longer than the stateless paradigm.

  • Mark Fox

    This is great news for PHP. As described the right kind of apps will see a huge benefit to resource reuse. Thanks for reporting.

  • http://www.bitfalls.com/ Bruno Skvorc
  • Nikola B.

    Tim, it’s not my intent to make you feel bad about your product and I’m not rude. I am stating my opinion on the matter, I can’t control how this text affects you since you can’t see my face nor feel my thoughts while writing this. If anything offended you – I sincerely apologize.

    The bottom line is that you are not aware of all the software that’s available, but you labelled your product as if you *are* aware of all that’s available and now this article is advertising it as a new, great thingy that solves a lot of issues. What happens then is – people come along and use your product which in reality, is inferior to what we can use.

    I’ll refer to your points as well.

    1) It’s not me who has to prove to you that you are resilient to HTTP attack vectors. It’s YOU who are supposed to prove that to ME. I am your potential customer. Trust me, there will be many who will ask you the same thing. You can either try to take what I wrote and utilize it for yourself – or you can leave it and have a potential real customer skip on your product. You talk about Java and enterprise, but this would be the very first thing you’d fail the audit on. You can’t get to enterprise world that easily, especially without common tests proving your app doesn’t fail at things such as this.

    2) If I don’t have to build my app in into your appserver, then what’s the point of it? What problem does it solve for me? What’s the point in using your server at all then?

    3) You are not nginx, but you do compare with it. You wrote your server in PHP, and of course you cannot easily maintain file descriptors or many other things that similar web servers do (I didn’t get to that part of your code, but I didn’t see any type of event loop). They deal with one thing and one thing only (at least nginx, not talking about Apache here) and they do it good – especially nginx.

    4) Paradigm change – no, there isn’t paradigm change here. You are not doing anything new. You might be thinking you are, but I’m telling you you are not. Others told you that as well. You can refuse to read or trust us, or defend yourself by attacking but stop for one second and really think about it – what’s new? What paradigm is changed?

    To me, it looks like that there are a few guys who got their hands on the pthreads extension for PHP and this project came about as something you found interesting to work on while playing with threads. I commend you for your hard work. You are apparently able to create software. The only “problem” is that software you created was created to solve problems you guys faced. Did you even bother to do market research and check what other people use to solve similar problems? Since you avoided the answer to my question about your HTTP parser – don’t you agree with me that a potential user, like me, is free to conclude you haven’t done your research?

    I’m not challenging your abilities, intellect, knowledge or anything else here. You are definitely, without mistake, people who are able to program properly. It’s just that your choice of problem you will solve with all that knowledge was poor.

    I would just like to reflect on the day-to-day things you mentioned.

    – “What about long running import processes”

    What about them? I use supervisord to have my process supervised in case it exits with an error. I run it in background. I also have a job queue that I can persist anywhere (select any RDBS, NoSQL or whatever storage you like). I can use Laravel / Lumen to quickly create PHP code require to do the job I want, focusing on the task and task only. I have a framework that lets me write the code, that lets me connect to the storage layer and then I have tools like supervisord that let me manage how the process runs and exits. Both tools do their job and they do it properly. supervisord is a tool known by many sys admins, so usually I can just create the code dealing with the task and a sys admin can take care of the process using their own knowledge. Is it the same with appserver and sysadmins?

    – “asynchronous message processing”

    What about it? Again, ZeroMQ + Supervisord = I can now do async processing on almost unlimited number of machines. Again, two tools that do their job extremely well, with extremely simple interface, and extremely quick learning curve.

    – “In our opinion PHP frameworks try to copy Java frameworks more and more,”

    That’s not true at all. The only framework that PHP copied is Ruby on Rails. These are now opinions and not facts so I probably shouldn’t even comment on that.

    – “the result is, that frameworks get bigger and bigger and as a result, slower ans slower”

    Again this isn’t true. Let’s take a look at Laravel first and then at Lumen. That fact alone makes your statement untrue.

    – “HHVM is a good deal”

    HHVM is just another product with awesome advertisement, a cult following but in reality it’s a piece of shit of a product. The only good thing that came out of that is that PHP team got off their asses and made PHP 7. Facts for HHVM being crap: owned by Facebook, team of mediocre developers, huge amount of bugs, CLI interface nearly useless – all of that would be ok if it worked. It just doesn’t work properly. If I could drop it in instead Zend engine, and if it worked (even with extension incompatibility) – it would be great. But it isn’t working and that’s it.

    – “but within the next 2 years the performance boost will be lost by new features provided by the those frameworks”

    These are also opinions, nothing you stated there is backed up by facts. That’s just not true. The only thing that will happen (most likely, and this is my opinion) is that people using PHP will have other interfaces at their disposal – for async processing (I use LibEv to control the processes, extension for that is available since forever). For threading we got pthreads. If anything is needed – we’re free to code it on our own via extensions.

    Now, had you gone down this route: created a framework/environment that’s able to “speak” an arbitrary number of protocols with the intent to let us create code that immediately returns the result (via HTTP, WS or whatever) or works with it in the background – now that would be something great! And essentially, appserver is exactly that! I would never use it as HTTP server. I would always place it behind nginx or some other tested http frontend. What your app seems to be potentially great at is being an async task processing framework and that’s exactly how I would advertise it as. It being able to serve traffic over HTTP would just be an added benefit.

    Anyway, good luck to you and your team, I’ll keep an eye on the changes you do.

    • Tim Wagner

      Hi Nikola, thanks for your adjustment, i’ll not feel bad about our product, believe me. I really like constructive criticism, but i think it should be on a respectful level, thats all.

      For sure we can’t be aware of all the software out there, and i don’t think we labeled that we are. If you got the feeling, it would be interesting where we do that? This article written by Scott Molinari is a brief introduction to appserver.io, multithreading and a description how to install it. I can’s see any advertisment, simply i like it (thanks again to Scott). I my opinion it doesn’t tell the reader, that appserver.io “is a new great thingy that solves a lot of issues”, instead i think everyone can understand, that it adds new opportunities to the PHP ecosystem, and that’s exactly what we think. You may think it is inferior what they can use, we don’t think so. We think, we’ve built an application server for PHP that is a solid base and provides the necessary services for writing high performance web applications without the need to use third party tools. Exactly that is what we see as one of the biggest advantages and this is a reason why we’re focusing on it. You may see that as a weakness, and we still can be okay with that. We never say, that there are no other options to write good web applications with PHP, so it’s up to the developers to decide what solution fits their needs in the best way. We only want to give him all the information that is necessary to make his decision.

      1. I’ll agree with you that security is one of the major topics we’ve to care about. Meanwhile we’ve about several thousand downloads and didn’t heard of any security issues. I’ll request a sprint that is all about security during one of the next weeks. After that we can be sure to be resilent to all HTTP attack vectors.

      2. You’re free to define it as you want, but, as i explained it in my previous comment, we strictly separated application server and applications by providing interfaces to take care the application is not coupled with the application server itself. In contrast to a usual webserver an application can have a state which allows developers to have objects in memory, for example by using session beans. Additionally there is no language break, if you use the services provided by appserver.io, as everything is written in PHP.

      3. Again, we don’t want to compare with nginx and Apache as they simply are webservers and we provide an application server for PHP. We’ve a comparison matrix on our website that explains, what additional features appserver.io provides. nginx and Apache are doing their job quite well, also when someone wants to use PHP-FPM or HHVM. We implemented a webserver, because it makes no sense to deliver static files by a servlet or something like that. We’ve no problem to handle file descriptors in a proper way, for sure there will be always optimisations we can work on. Our webserver is a necessary part of the application server to provide standalone functionality, that, as i described before, is something what we’re focusing on. We want to provide an application server that enables PHP developers writing software in PHP, JS and CSS, nothing else.

      4. We think from stateless to stateful is a paradigm change, not in the web at all, but for sure in the PHP ecosystem. Some told us, it’ll not be possible to write an application server in pure PHP, some told us, that it is not a paradigm change, other do tell us it is for sure. Finally it doesn’t matter, important is, that it works. So i think, we’ve a different point of view, but i can be okay with your view.

      I don’t know if appserver.io may solve any problems you have, but maybe you don’t have any problems, so there is no need to fix them ;). As a mid-range service provider for PHP based content and ecommerce solutions, we are using PHP sind version 3. We’ve implemented a whole bunch of ecommerce systems and we also see another whole bunch of ecommerce systems written by third party service providers. Our own problems with PHP, i described some of them in my last comment, are the same problems these third party service providers had with their systems what leads us to start implementing appserver.io. The only reason, we can’t start earlier is, that Joe Watkins released his necessary pthreads library in 2012 first.

      For sure there are other good, even very good solutions that enables a developer to solve problems with long running processes, caching or asynchronous message processing. But you may have to deal with other languages, other systems and finally other configurations, which results in something like tool or system orchestration. Instead of that we want to provide all the services, necessary to implement applications, simply with PHP, no other language nor any other configuration, which is one of the strengh of Java in my opinion by the way. Beside of that we gave our commitment, that appserver.io should also run on Windows, where supervisord and many other tools are not available. Looking for alternatives can be tricky sometimes. When i look at laravel, i see a very solid, easy to use and comfortable framework, awesome work for sure! But if i have a look at some performance benchmarks, e. g. http://blog.a-way-out.net/blog/2015/03/27/php-framework-benchmark/ and follow statements of the community https://laracasts.com/discuss/channels/general-discussion/php-framework-benchmarks-for-2015 i think i’m right in what i explained. HHVM has nothing to do with appserver.io, but for sure, it can still be a very good deal for many systems that meanwhile lacks performance. For my point of view it doesn’t matter if Facebook or any other company owned it, it’s open source and everybody can be part of it. PHP7 and HHVM will actually help many frameworks to hide their bootstrapping overhead, but i’m sure this give-away will be consumed within the next two years. That’s what i’m convinced about, but maybe it will not come true. Generally i think, that the diversity of solution in the PHP ecosystem is one of it’s strength and a reason why it became so famous during the last years. appserver.io is simply a new way to implement software using PHP and i’m sure other systems with the same aims and targets will follow, maybe they find another way to make it work. If they’ll find their place in the ecosystem is not up to me, but to the developers out there.

      Finally i appreciate, that you came to an conclusion, that, indeed not completely covers my opinion, but gives me a good and acceptable outline how you classify appserver.io. Again, thanks for that!

Recommended
Sponsors
Because We Like You
Free Ebooks!

Grab SitePoint's top 10 web dev and design ebooks, completely free!

Get the latest in PHP, once a week, for free.