On Fri, Nov 11, 2011 at 11:07 PM, Paul Querna p...@querna.org wrote:
4) Have the single Event thread de-queue operations from all the worker
threads.
Since the operations include Add and Remove, are you saying we would have
to have to wait for a context switch to the listener thread before
On Mon, Nov 14, 2011 at 7:47 AM, Greg Ames ames.g...@gmail.com wrote:
On Fri, Nov 11, 2011 at 11:07 PM, Paul Querna p...@querna.org wrote:
4) Have the single Event thread de-queue operations from all the worker
threads.
Since the operations include Add and Remove, are you saying we would
On Mon, Nov 14, 2011 at 11:12 AM, Paul Querna p...@querna.org wrote:
The problem became that in trunk, we had to told the lock for the
timeout queues while we were doing the pollset operation. The
pollset already had its own internal mutex too, for its own rings. So
we were double locking
I've created a branch event-performance with this change and several
other changes:
https://github.com/pquerna/httpd/compare/trunk...event-performance
I did some basic benchmarking to validate it, though if anyone has a
real test lab setup that can throw huge traffic numbers at it that
would be
Yeah, I saw your tweet… This is really cool and I never bothered
to check raw req/per/sec stuff for my acna11 talk because,
as it was said in the trafficserver talk, rps is ridiculous
anyway ;)
Would love to see this folded into trunk and even 2.4.0
if we have the time and inclination. When I get
On Fri, 11 Nov 2011, Paul Querna wrote:
After r1201149, we now lock for lots of things, where in an ideal
case, we shouldn't need it.
I agree that that's not optimal, but it is no regression. Event always
used locking for the timeout queues. But what we really should do in 2.4.0
is remove
On Sat, 12 Nov 2011, Stefan Fritsch wrote:
locking for the timeout queues. But what we really should do in 2.4.0 is
remove all the MPM-implementation specific details from conn_state_t. The
only field that is actually used outside of the MPMs is 'state'. If we make
the rest non-public and
hi,
After r1201149, we now lock for lots of things, where in an ideal
case, we shouldn't need it.
I'm toying around with ideas on how to eliminate the need for a mutex at all.
My current 'best' idea I think:
1) Create a new struct, ap_pollset_operation_and_timeout_info_t, which
contains a what
