httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: Performance fix in event mpm
Date Thu, 27 Jan 2011 18:31:25 GMT

On Jan 27, 2011, at 12:21 PM, Jim Van Fleet wrote:

> I have been developing an application using apache 2.2 on linux 2.6.  My test environment
creates a very heavy workload and puts a strain on every thing.  
> 
> I would get good performance for a while and as the load ramped up, performance would
quickly get very bad.  Erratically, transactions would finish quickly or take a very long
time -- tcpdump analysis showed millisecond or seconds between responses. Also, the recv queue
got very large.
> 
> I noticed that ap_queue_pop removes elements from the queue LIFO rather than FIFO.  Also
noticed that apr_queue_pop uses a different technique which is not too expensive and is fifo,
so I changed ap_queue/pop/push to use that technique and the receive problems went away.
> 
> snippet from ap_queue_pop (push is similar with appropriate changes to the fd_queue_t
struct)
> 
>     AP_DEBUG_ASSERT(!queue->terminated);
> #if 1
>     ap_assert(!ap_queue_full(queue));  /* we'd never expect the queue to be full, so
for debug, we check */
> #else
>     AP_DEBUG_ASSERT(!ap_queue_full(queue));
> #endif
> 
> #if 1
>     elem = &queue->data[queue->in];
>     queue->in = (queue->in + 1) % queue->bounds;
> #else
>     elem = &queue->data[queue->nelts];
> #endif
>     elem->sd = sd;
>     elem->cs = cs;
>     elem->p = p;
>     queue->nelts++;
> 
> Please let me know if you think this change is appropriate and/or if you'd like more
data
> 

Hmmm.... Not sure why the fdqueue would be LIFO. But certainly
the above ain't right for pop! :)
Mime
View raw message