Bill Stoddard wrote:
> I am working with a customer that wants to support 10,000 concurrent clients on a
>single machine.
> That number will just grow in the future. I think the actual memory used by the
>scoreboard in this
> case may be trivial compared the savings with moving to a threaded server. On some
>systems, shared
> memory is pinned (non-pagable) real memory. How big a chunk can you expect to
>allocate at a time?
> If we can safely allocate say 20MB of shared storage, then maybe you are right and
>we shouldn't be
> worrying about eliminating HARD_SERVER_LIMIT.
We aren't worrying about trying to eliminate HARD_SERVER_LIMIT. If that can happen
then great, if not
then who cares. I'm not even trying to save the memory, though if it happens as a side
benefit then
great.
What I am trying to do with the redesign is allow people to use the threaded mpm, and
others, with
max_requests_per_child set to anything other than 0. Your customer will not be pleased
with
the current performance of the threaded mpm with mrpc set to anything other than 0.
The potential savings of not allocating the mod_status memory would be about 1.5 MB
for 10,000
workers. Not all that much in the grander scheme of things. The difference between an
average
of mid to high hundreds of rps vs the current dozens of rps for threaded with mrpc =
1000 is
what I am trying to fix.
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
