Phil, On 17 Feb 2014, at 10:13, phil@highoctane.be wrote:
2- Process vs on-request
PHP-based solutions mostly have the request->apache->mod_php->scripts->db and back roundtrip. When there is no client, there is no CPU, no nothing used. This allows to pile on users in a shared hosting as there is usually not that much traffic.
With the current Pharo+Seaside combo for example, we do have an always running pharo process taking away CPU cycles. That's not too good for shared hosting and platforms like EC2 where we pay based on that.
As my thinking goes, I find interesting to have a FastCGI interface for pure Pharo (until we possibly have a mod_pharo) so that pharo becomes a first class scripting option for simple web applications. With the new command line and environment access, that's not that hard to do.
FastCGI is a long running process as well, right ? It would not be unthinkable to boot a new image when needed and shut it down when it is idle for some time. It takes less then half a second: root@stfx:~# time ./pharo Pharo.image printVersion [version] 3.0 #30203 real 0m0.379s user 0m0.148s sys 0m0.028s Lots of intelligent things could be done, I am just not sure we should compete in this space as I doubt there is any money to be made. Sven