I started seeing the following errors in the specweb99 run output, when I
use mod_specweb99.c with Apache 2.0.43 and worker MPM. The following patch
seems to get rid of the problem. If you're thinking that it may degrade the
response - I did not find much difference though.
Can somebody please evaluate and let me know if it's okay ?.
[...]
+#if APR_HAS_THREADS + apr_thread_mutex_lock(log_mutex); +#endif
from my Linux srclib/apr/include/apr.h, with Apache configured to run the prefork MPM:
#define APR_HAS_THREADS 1
...so I would see some degradation running prefork without getting any benefit from the additional mutexing.
I believe APR has global locks available on every platform we support, where global means that the lock mechanism serializes threads within a process as well as cross-process. If that's true, I would prefer that we start by switching to that global lock mechanism to replace the apr_file_lock. If on some platform APR's global lock doesn't perform adequately, we can deal with that on a case-by-case basis.
A possible complication: read/write lock support. How important is that? I don't know how frequently SPECWeb99 reads the post log. If it doesn't happen often compared to the POST URLs which would need a write lock, maybe we can get by with just a write lock.
Greg
p.s. at the moment, by far the heaviest CPU usage in my Linux SPECWeb99 config is in csum_partial_copy_generic, a kernel function that calculates TCP checksums and copies data to/from userspace. I'd like to get a NIC with hardware checksum support, which should give me some relief. But in the mean time, I'm not doing much benchmarking because it's hard to see meaningful differences when I make changes.
