So what im saying is why bother having an app server for all 80 sites which would likely use a lot more than 500mb of ram, even at just 8mb per process it would be troublesome, i can let fastcgi deal with spawning and killing php processes off as the load requires. (btw, the vps runs email and a few other things too, with in 500mb).

And the greatest part, of using fast-cgi + a chroot’d wrapper, is that i have the same setup for perl, scripts, so that they stay within the same jail, along with chroot’d ftp and chroot’d ssh access. And down the track i can add ruby/python support without having to change much at all.

So to me, fastcgi or an equivalent technology is fantastic for low volume, sporadically accessed sites.

That’s fine so long as everyone still programs in just one web language. However if things start passing off requests between languages it seems like the overhead of an http server for each language type will get oppressive. Moreover, as an earlier commenter pointed out fastcgi and similar protocols can be updated to deal with specific problems they face unlike http. In particular I suspect we will eventually want to add extensions to deal with things like coordinating URL rewriting or giving other information to the server.

The model I see is a little different. The complex modules (dynamic languages etc..) will be stripped out of web server modules and each *language* will run it’s own server which will coordinate with the web server using a more powerful protocol that replaces fastcgi which lets all communication flow over some fixed number of communication mechanisms (maybe even shared memory).

Basically processes are a fairly heavyweight object and I see performance considerations pushing against their indiscriminate use. Since dynamic languages are pursuing sandboxing type facilities for other reasons (managed code etc..) and OS user level permissions are a bad fit for cgi permissions letting one process run all the ruby or python scripts won’t duplicate much effort. Coding separation and maintainability issues will drive the various languages out of the web server so the web server, e.g. so they can use different threading models. However, a desire to control how the request is processed and desire for lightweight integration of other scripts will keep us from fully separate web servers.

In fact in the long run I see dynamic language support being moved directly into the OS where things like GC which benefit hugely from hardware features like write barriers can be optimized.

I was thinking about non-forking servers, and the fact that they might not benifit from the next wave of dual core PC’s, but now that the application is running in a seperate proccess and not embedded in the server process, I think that this is perfect now.

This is exactly the situation with Zope and Java apps. Neither python nor java’s VMs can really deal with multiple processors all that well (due in python’s part to the Global Interpreter Lock). So the standard approach is to run multiple processes and then front them with apache/squid/whatever and load balacnce across the processes. This scales very nicely to mutiple cores/processors/servers.

-Matt

First, aside from PHP DSO modules have most definitely not prevailed over app servers. Really.

Second, I agree that one of PHP’s great strengths is its simplicity. I would argue that a related, yet slightly different, reason for it’s popularity is that the initial “bar” to getting started is so incredibly low. Likewise for MySQL. Sysadmins aren’t a patient bunch, and a quick zero-to-60 is a massively critical thing for driving adoption of server-based technologies. I’m convinced that’s the major factor behind Rails success too, BTW (combined with good marketing). You can get started and get pages generated really, really easily with low level-of-effort compared to the frameworks / app servers it mocks.

I’m not sure how to read your comment about thousands of files. Assuming you’ve got Python or Java running bringing up their app servers is actually really trivial. Much easier than Rails today, for example. I will grant you that building apps for Zope or Tomcat (say) requires a much bigger initial investment of time, but comparing Zope or Resin or Rails or whatever to PHP is nonsensical. Framework vs. language.

As I mentioned in a follow-up post it looks like I was wrong and Rails will almost certainly go the HTTP app server route, and not CGI/FastCGI.

You mention the extraordinary adoption rate for php , well from it’s documentation , usage , implementation one thing is constant , simplity (think mysql ,same thing stems from it too , connect the dots)

Realise that php either by DSO or CGI only needed the binary , the libraries , extensions and config file , which were only a handfull of files initially , and still are tens of files , not hundreds , not thousands like zope or java.

Ruby for one is allready monlithic in respects to usage , they should be crazy to go that way about deployment too.

One being the fact that it has been in the “will be stable one day” state for what, the last 4 years? Will it ever become stable?

The bigger problem is that the processes for each security context (each UID basically) are not separate processes but threads in a single process. Which means that interpreters for the above mentioned frameworks (or any dynamic content generating “backend”) should be thread safe.
Which condition is not met by most of the most popular frameworks.
PHP interpreter has ZTS but I’m not sure if its considered stable nowadays, but even if it is, quite few of the PHP extensions are NOT thread safe and most of them will never be. That said, such thing as a “PHP interpreter with the common set of extensions” is not going to be thread safe anytime soon (or ever).
As for rails, I read in one of the recent RoR-anti-hype articles (they seem to grow on trees nowadays) that ruby (or RoR?) is definitely not thread safe.
So you could use mpm_perchild for running… maybe python? And nothing else.

Not to mention other deficiencies of mpm_perchild, like the lack of ability to chroot each security context.

Maybe these are the very reasons this mpm is not even stable yet?

There is also a large apeal of in-code modules to in-house users, due to the simplicity and the desire to not have to learn anything about administrating a webserver to get one with a productive website.

There is also new work on Apache 2.2 with a mpm_perchild, which is a hybrid of processes and threads to allow the process space to have a security context and resource limit and within that requests are serviced in a by a threaded server (like mpm_worker).

Once that is stable and working well there well be even less need for FCGI, as you can use in-core modules but still get per virtualhost/userid process isolation. It will then be a matter of time before the lifecycle of the apache mpm_perchild workers can be controlled as well as FCGI, so resources are reclaimed.

There is one big disadvange for moderatly busy websites using FCGI and any form of proxy that is all the data is being copied around and maintain two (or three) connection resources per request (not including ones to databases). The mpm_prechild solution maybe able to stop all that. The data has to go browser -> http apache -> fcgi and back again, this extra indirection is only worth while when your webhosting is setup with redundancy in mind otherwise it just reduces your overall request per second throughput for a single machine setup. mpm_perchild is more likely to be the answer than FCGI/SCGI.

The zope users have memory limits, and the ruby folks have even lower limits.
I’m constantly wasting memory and cpu in idle loops of such sites, so I’m even thinking about a dirty hack signalling them STOP when the last connection dies, and CONT if the next one arrives ….

just my two cents …b.t.w. good article

You may be aware of this already, but in the brief time since you wrote your post, in the Ruby/Rails world, the new HTTP engine “Mongrel” has been getting a lot of excited attention. It does exactly what you describe — lets Ruby web-apps handle their own HTTP connections, so they can be used either standalone or proxied behind another web server. (This was also possible with WEBrick, but Mongrel is by all accounts many, many times faster.)

The big flaw I see with using HTTP as the interface to web-apps is that, as already mentioned, it isn’t supported by most shared hosting environments. That’s a pretty significant problem since so many people rely on shared hosting. Not the pros, of course, but the majority of amateurs and hackers, enough so that I think HTTP-proxying won’t be seen as a mainstream solution, just a special item from the bag of tricks that you whip out for large-scale deployment.

First of all, the benefits for HTTP. My server is Windows and setting up persistent FastCGI processes is a pain - you need to wrap them in services, and this usually isn’t included in packaged apps (although tools exist to do it). Standalone web servers are much more likely to be ready-packaged as services (or easier to modify for that purpose). Also, FastCGI is not part of the standard Apache2 binary for Windows, so it’s a nuisance to get hold of.

SCGI is not an option for me, as it’s Unix-only.

But the big downside to HTTP proxying is ensuring that all the info I need passes through the proxy. For example, I need SSPI authentication, which I have set up using mod_sspi on my Apache frontend. But getting the authentication data to the backend is a nightmare. In one case, I have 2 instances of Apache, both with authentication switched on (a fromtend 2.0 with mod_sspi and a backend 1.3 with mod_ntlm). In another case, I simply gave up and use mod_python.

Another issue can be picking apart URLs. If I want to “mount” my Wiki on http://myserver/wiki, I need to do URL mapping in the Wiki server (like VirtualHostMonster in zope, but for a custom app). I’m hoping WSGI in Python will help with this, but haven’t got round to trying it yet.

So ultimately, I sort of agree with Ian. HTTP proxying is in many ways the ideal solution - but communication between the front end server and the backend can be a nightmare, if the backend app isn’t built to expect to sit behind a proxy.

(to summarize, I think HTTP proxying is a subset of the capabilities of the *CGIs; only a tiny bit less powerful, but still in some important ways)

i think that apache for me is o slow server i’m looking for better http serwer which will be faster and powerfull.
Anyway, good article and i will be back here soon.