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
_______________________________________________
metacard mailing list
[email protected]
http://lists.runrev.com/mailman/listinfo/metacard
