Re: [Pharo-dev] CMS status
Ha, this ease of hosting question. 1- Ease of hosting Thing is that mod_php and PHP itself are easy to compile for almost any distro. With Pharo that's not so easy (64-bit platforms requiring 32-bit libs and some dark tricks to get right [e.g. using experimental debian repos for libc, which no sane hosting company would allow]. We need to come to par with this platform ubiquity if we want to be wider spread. 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. Is there anyone using pharo in such a configuration? Phil On Mon, Feb 17, 2014 at 9:38 AM, Yuriy Tymchuk wrote: > Hi guys, > > this weekend I was unlucky enough to work with WordPress and all it's > shitty php. Now obvious question is what is the status of Pharo-based CMSes > and how they can be hosted. Right now I'm looking for a free solution. Yes, > I know that developers also want to eat, but, usually people use (for > example) WordPress, because they can put it on a free php hosting, and I > cannot promote Pharo-based solutions if you have to py for them in a first > place. Also from CMS point of view, I'm aware of Pier, but is it the best > thing that I should look into? > > Uko >
Re: [Pharo-dev] CMS status
Am 17.02.2014 um 10:13 schrieb p...@highoctane.be: > 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. > Amazons ec2 is paid based on running machine hours not on cpu cycles. Norbert
Re: [Pharo-dev] CMS status
Phil, On 17 Feb 2014, at 10:13, p...@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 real0m0.379s user0m0.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
Re: [Pharo-dev] CMS status
Am 17.02.2014 um 11:17 schrieb Sven Van Caekenberghe : > Phil, > > On 17 Feb 2014, at 10:13, p...@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. > There can always be done a lot. But let’s face it. Amazon is offering different sizes of machines that are charged differently. The smallest one is quite a pain when it comes to latency. Sometimes you will experience half a second or more as latency for a running image. And starting an image on those machines will take a lot longer. What we are talking about are really small projects. If you do the cost calculation then you might see that amazon is not a good fit for these types of applications. The business of amazon works this way because the cloud buzz makes you believe it is cheap but in most situations it is not. S3 being one of the exceptions. Small projects only consume memory and machine/cpu time but not much cycles. So how clever can your approach be if try to make it fit into a business that calculates its cost based on time and memory? :) Norbert
