CGI and DestroyStack property

LiangTyan Fui mlist at afteroffice.com
Thu Apr 27 22:49:11 CDT 2006


On Apr 28, 2006, at 10:19 AM, Brian Yennie wrote:

>> It is rather crud to use PHP -> socket -> MC.
>> The MC socket port listening method is not robust enough, and may  
>> went deaf under some loads.
>
> I think Pierre would disagree. I would also - it's a whole lot more  
> likely to handle a big load than a CGI that loads the whole engine  
> with every request. There's nothing crud about it, it works quite  
> well.

Linux cache the engine very well (at least on disk cache), so  
subsequent call to the MC cgi result in no disk reading.
We have managed to serve over 250 concurrent mc process in a 2 GB RAM  
Intel based linux system without significant load on the system.

We was basically switched from the daemon based Metacard to the  
session based not for speed consideration (CPU gets faster, RAM gets  
cheaper each year), but for more stable, easier debug and rebuild on  
the project (update daily).

Anyway, my point is: it is quite different to code in daemon based  
Metacard and the CGI based Metacard. Going from CGI based to daemon  
based to solve the read/write conflicts may not justify the re-coding  
effort on the rest of the project (specially multi-users based).

It is easier to write all the result into a separate file, and have a  
process to collect/merge the results when you need it. That will help  
to reduce the conflicts in a way.

BTW: we are rather extreme on the server configuration, we turn off  
PHP, perl and almost every scripting support in apache for security/ 
speed tuning. So you know why I don't recommend PHP here ;)

Oh one more thing, the Metacard listen command don't allow one to  
bind the port on a specific IP. So Metacard daemon will listen too  
ALL the TCP/IP interface on the machine. Make sure you have your  
firewall configured if you do not want external traffic going into  
that port.

-- 

>> You don't have to use PHP to handle the browser POST queries. We  
>> have pure MC CGI written to handle POST running for years without  
>> problem.
>>
>> Unless you need to MC running as daemon explicitly, I don't see  
>> the need of PHP here.
>
> That was the point of this thread... I think you missed the  
> requirements. The original poster already has a working CGI, but  
> wanted a daemon solution to easily solve read/write conflicts for  
> the stack.
>
> - Brian
>
> _______________________________________________
> metacard mailing list
> metacard at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/metacard



More information about the metacard mailing list