andu wrote:
>
> >Is there any plan to implement any sort of threading for MetaCard? Scott,
> >I know I've read your comments on this before, and if I remember the
> >answer was a flat no, because there is little perceived benefit and
> >significantly increased complexity, both on the backend for you, and for
> >scripters on the front end, in order to keep track of what the heck
> >they're telling the computer to do. (Feel free to correct me if I'm
> >remembering incorrectly)
> >
> >I wonder if that might change in light of two things: first, with the new
> >socket support, and specifically the server-in-a-stack you're including
> >with it, it seems like threading would almost be a requirement. Obviously
> >no one's going to try to beat Apache's benchmarks with a MetaCard stack,
>
> My arrogance pushes me to ask, why not? I strongly believe that by 2.4 the
> sockets stuff should be polished enough to at least match *some* of
> Apache's benchmarks at least on Linux.
Possibly more important than multi-thread support in the MC engine is
server architecture and configuration, as proposed below.
>
> >but what happens to an incoming request while you're busy processing a
> >previous request if there is no threading? Is there some sort of buffer,
> >or something else I'm not thinking of?
>
> Don't forget that once the server "accepts" a connection it passes it down
> the line to be processed "with message..." which in theory means it is
> ready to accept another one right away. Another mechanism servers use for
> administering large numbers of calls is KeepAlive which basically limits
> the number of requests per connection and also times out if no requests
> were received from that connection.
> I didn't try it but it might be possible to open several instances of the
> server to satisfy high demand, if needed - on Linux again.
>
If multiple instances of MC can run on the same machine (or same
network), then you can effectively have multi-threading by using one
session as a gateway that distributes the workload to other sessions
depending on, say, protocol... (server A receives all requests; if it's
an FTP request, pass it on to server F; if it's an e-mail, pass it to
server E; etc.)
... or base request distribution on the relative workload of each
server. With the right parts in the right relations to each other,
pretty soon you could have enterprise-ready (?) redundancy and failover.
Fascinating stuff!
Phil Davis
> >
> >Second, I've spent just a very little time with Dan Gelder's Serf, and
> >his implementation of threads in script seems fairly easy to comprehend.
> >Maybe there are issues I'm not thinking of, but still, it seems like
> >threads could be implemented (from our end of things) fairly
> >straightforwardly, in a way that beginners wouldn't have to deal with,
> >but advanced users could really get some mileage out of.
> >
> >Geoff "just stirring up the pot" Canyon
> >
> >This is the MetaCard mailing list.
> >Archives: http://www.mail-archive.com/metacard%40lists.best.com/
> >Info: http://www.xworlds.com/metacard/mailinglist.htm
>
> Regrds, Andu
>
> This is the MetaCard mailing list.
> Archives: http://www.mail-archive.com/metacard%40lists.best.com/
> Info: http://www.xworlds.com/metacard/mailinglist.htm
--
Phil Davis
------------------
[EMAIL PROTECTED]
This is the MetaCard mailing list.
Archives: http://www.mail-archive.com/metacard%40lists.best.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
