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