Native FastCGI support in Phalcon

I would like to speed up Phalcon web apps even further by embedding a FastCGI functionality into Phalcon. See The end goal is to keep the application running indefinitely (vs being initialized and then killed for every request) which should make it super fast. However I struggle a bit with where to start. Any tips are greatly appreciated!


use cache for the whole response ( redis/ memcache )

anyways ...

make the app runing as a service ( constantly ) like a cli app, make the application accept some object ( $request ) as an aguments from a stream with opening socket connections and serve the user the response.

What i just wrore will boost your app speed by 1000% probably, however by implementing that you will create tons of bugs for sure.

Better use cache and load balancer and server the content from different machines ( same applies for database )

p.s. make sure your bottleneck is the php code, not something else. Also run profiler on your app and polish it to perfection.

edited May '17

IMHO, this should be solved at the core PHP level, if any. Application as a service approach. Like @Izopi4a said, it would introduce many bugs the other way around.

P.S. This extension does not support PHP7, and it hasn't been updated for 2+ years....

edited May '17

The newer and keep updated repository with similar concept(application bootstraped once and stay for all the time in memory) achieved other way -

Though it doesn't support phalcon, it would require changes in phalcon and how di/request/response stuff works.

This is really nice, but it has it downsides and problems, but for instance symfony + php-pm have similar performance to phalcon.

Though keep in mind how phalcon already works(already whole code base stays in memory as an compiled extensions) - things like those won't give any big performance boost. It will only give performance boost for your php ocde, compiled code performance will stay same.

It might even get slower - due to memory leaks which will happen on things like this.

Thank you for your great answer @Jurigag. There will be problems for sure with this approach, at least initially, but nothing too dramatic. Look at the Python world: "web app as a service" concept has been there since stone age. I think it is just silly to initialize and kill the framework for every request in 2017. Even though, in case of Phalcon (which is awesome), the framework stays in memory and is already fast enough, it is still being initialized and cleaned up on every request. Then, in a typical, complex enough web app there will be several other PHP libraries/frameworks loaded and initialized using auto loader. These are all dozens (if not hundreds) milliseconds wasted.

Memory leaks can be fixed. Again if we look at uwsgi or any other app service for Python - it is not really a problem there (I'm speaking from experience of having a Python web app running for almost a year without being restarted).

I think it is convincing enough. Anybody wants to participate? :)