Multithreaded app server written in PHP(appserver.io)
appserver.io
Multithreaded app server written in PHP
http://www.appserver.io/
7 comments
Why?
I mean isn't one of the main great things that you just place your php files in the apache/nginex web folder and run.
Because people should have alternatives to multiprocess Web servers in memory hungry languages. Threads have a stigma among dynamic languages but when they are abstracted nicely they can give you a lot of performance for very little headache. Memory isn't cheap when you're renting it.
[deleted]
[deleted]
The font is not very easy to read on Chrome 31.0.1650.63 on Windows 7. Screenshot: http://i.imgur.com/3hBHzPn.png
edit: Adding -webkit-text-stroke: 0.5px; to the body CSS helps.
edit: Adding -webkit-text-stroke: 0.5px; to the body CSS helps.
Does it work on HHVM? (HipHop-PHP JIT from FB)
What are advantages of this thing against apache or nginx? Is it faster? Handles more concurent request? Or does it exists just for the sake of writing server in PHP?
One of the advantages obviously IS, that it will be faster than ngix (Apache is too slow to really compare it) because it allows you to hold objects persistent in memory what no other web server actually can. So we have Magento running within the application server, and had awesome performance improvements around 50 % (means about 100 ms for a category page instead of 150 ms on nginx). As it is multithreaded (not forked) AND faster, it also allows you to handle more concurrent requests.
But that is only one thing, because a application server, beside the web server (what is only one component and maybe will run behing a nginx that delivers static content like pictures, CSS or JS), provides you with additionally services like a message queue or a time service that will be very helpful in nearly any bigger PHP project.
A very interesting thing will be to combine appserver.io and HHVM to improve performance. If this will be possible, we think it will make the servlet container part of appserver.io for sure the fastest webserver available.
As the appserver.io is completely written in PHP it allows you and any other PHP developer to help fixing bugs or to improve it by adding new enhancements like HTTP 2.0 protocol in the future. With such a big community, like the PHP community is, we can be much faster to improve appserver.io than waiting for Apache or nginx to came up with new features. These are the main reasons why we think that PHP community should have their own application server for PHP written in pure PHP.
But that is only one thing, because a application server, beside the web server (what is only one component and maybe will run behing a nginx that delivers static content like pictures, CSS or JS), provides you with additionally services like a message queue or a time service that will be very helpful in nearly any bigger PHP project.
A very interesting thing will be to combine appserver.io and HHVM to improve performance. If this will be possible, we think it will make the servlet container part of appserver.io for sure the fastest webserver available.
As the appserver.io is completely written in PHP it allows you and any other PHP developer to help fixing bugs or to improve it by adding new enhancements like HTTP 2.0 protocol in the future. With such a big community, like the PHP community is, we can be much faster to improve appserver.io than waiting for Apache or nginx to came up with new features. These are the main reasons why we think that PHP community should have their own application server for PHP written in pure PHP.
It's an application server, not a web server. You would run this behind a web server. E.g. web server takes HTTP request, distills information from the request and passes it on to the app server for processing.
I wrote a preforking webserver in PHP once [1], it was a lot of fun! Especially since there wasn't really anything apart from FastCGI and mod_php. I have always been wondering why there weren't more PHP webservers written in PHP, maybe because FastCGI and mod_php were just good enough for everybody? Contrast that to the Ruby community, where there are more than a dozen decent webservers, implementing varying concurrency models.
Very interesting project!
[1] https://github.com/lgierth/pint
Very interesting project!
[1] https://github.com/lgierth/pint
It's probably a mix of (1) "If it works, don't fix it" and (2) "I don't give a shit."
(1) Because Apache has had mod_php for ages, and there's FastCGI/FPM for everything else. If you already have something written in C that works out of the box, there's little incentive to write an alternative in a slower language. Besides, until recently, PHP has been woefully inadequate for writing daemons, with all those memory leaks and crappy error handling. Even nowadays, there's a lot of stigma against writing daemons in PHP (usually by people who still think in terms of PHP 5.2).
(2) Because the majority of PHP programmers are not interested in writing anything other than plain old PHP scripts accessed with a browser. This might be a result of the fact that almost everyone has standardized on either mod_php or FastCGI/FPM. When something is taken for granted for such a long time, you tend not to think about how the lower layers works at all. At least in some circles, it's not unusual to encounter "experienced" PHP programmers who are surprised to learn that they can run a PHP script from the CLI and keep it running for many days.
(1) Because Apache has had mod_php for ages, and there's FastCGI/FPM for everything else. If you already have something written in C that works out of the box, there's little incentive to write an alternative in a slower language. Besides, until recently, PHP has been woefully inadequate for writing daemons, with all those memory leaks and crappy error handling. Even nowadays, there's a lot of stigma against writing daemons in PHP (usually by people who still think in terms of PHP 5.2).
(2) Because the majority of PHP programmers are not interested in writing anything other than plain old PHP scripts accessed with a browser. This might be a result of the fact that almost everyone has standardized on either mod_php or FastCGI/FPM. When something is taken for granted for such a long time, you tend not to think about how the lower layers works at all. At least in some circles, it's not unusual to encounter "experienced" PHP programmers who are surprised to learn that they can run a PHP script from the CLI and keep it running for many days.
Good point. Gives stuff to think about.