CGI and DestroyStack property

[LiangTyan Fui]

On Apr 29, 2006, at 4:36 AM, Brian Yennie wrote:

> Tariel,
>
>> Would not this mean that in this case it's not a CGI solution any  
>> more but a "regular" f MC running Stack that listens to some port  
>> and behaves like web server?
>> Something  like mchttpd.mc  stack  that Scott Raney put together  
>> and Andre later enhanced?
>> If this is the case, what PHP adds to it other than robustness and  
>> reliability ?
>
> Yes - it is a lot like mchttpd. Using PHP as an intermediary buys  
> you a few things which may or may not be important to you:
> 1) You don't have to open another port to the outside world, since  
> the incoming connection is just coming through your web service  
> (port 80)

Unless you have firewall somewhere, starting a MetaCard process with  
the listen command actually "open another" port on that machine, at  
EVERY TCP/IP interface. Quite an annoying "feature".

> 2) With PHP, you don't have to manage your own incoming HTTP  
> headers - PHP does this automatically with the $_GET and $_POST  
> variables.
>
> Other than that, it's mostly personal preference - but I feel  
> better with PHP handling the connection to the outside world to let  
> the existing web server do the heavy lifting.

When we started evaluating MC CGI on a Pentium (version 1) 133 Mhz  
machine with 256 MB RAM years ago, each of the MC instance took about  
1 second to load - too slow to consider in production use.
The Apache -> PHP -> MC method here could be a big help on those  
machines.

When we put some serious processing power onto it, with P III  
processor and more RAM, it sings. We were convinced that MC CGI was  
the way to go, so we migrated our entire development platform onto it.

The Apache -> PHP -> MC Daemon may offer good speed because no need  
for reloading MC process on each browser query, but the one deadly  
limitation on this setup is the multi-thread capability.
Imagine if your application grow, some queries may take more time to  
complete due to complexity and inefficient coding (it happens), and  
your user based start growing too. If a query needs 1 seconds to  
complete, serving 30 to 50 users concurrently could be problem as the  
daemon processes queries sequentially.
The server load may still low, but the respond could suffer.
You may start exploring the MetaCard very fancy "wait for messages"  
command to release the cycle to other "thread" - we did that, and it  
bought us some time. But the project and user based continue to grow,  
and we ran out of tricks eventually ;)

These days on a AMD 2Ghz server, spawning 200 MC CGI process needs no  
more than 1 second*, so the load time isn't really matter now.

>> In other words, is PHP absolutely necessary for such a solution or  
>> not ?
>
> Not at all! I personally prefer it, but it can certainly work without.

I respect your preference. I was just trying to point out that MC CGI  
may scale up easier, and you have 2 less components to worry: the PHP  
and the MC listen handling.

In all, I am pleased that more people has adopted MC CGI.

* about 300 MC CGI process in 1 second, on a P4 Dual Core, 3 Ghz.

-- 

> - Brian