Phil, On 17 Feb 2014, at 10:13, [email protected] 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
