All, Teng Xu, a graduate student working with me, has been developing a WebDAV performance testing client. Some of the results he received were a bit puzzling -- small PROPFIND operations were taking far longer (appx. 40-45ms) than we had expected. So, we started looking into the components of this time on the server side. We initially suspected the problem might be XML parsing, but quickly found this not to be the case.
>From what we can tell, the call sequence looks like this: method_propfind --> ap_xml_parse_input --> ap_get_brigade --> core_input_filter --> apr_bucket_read --> socket_bucket_read --> apr_socket_recv --> apr_wait_for_io_or_timeout --> apr_poll --> poll What we found was that just poll() was taking about 31milliseconds, and the rest of the functions took only microseconds. Poll acts somewhat like select(), and we verified that there was only one file description active at the time. Both client and server were on the same local subnet (100Base-T wiring), and the PROPFIND request body was relatively small, around 1500-2500 bytes (we tested for different numbers of properties being requested by PROPFIND, hence the variation). Strangely, when we request 1, 2, 3, ... or 14 properties per request, we see this behavior (long poll() response times). But, as soon as we request 15 properties, things speed up dramatically, to appx. 3-5ms. So, the good news is that XML parsing isn't hosing our performance. But, it does seem that there is some problem in poll() for relatively small request bodies that is a large impact on performance. But, the silver lining is that fixing this problem (assuming it's real, and we're not smoking something) could result in an order of magnitude improvement in several important WebDAV methods (PROPFIND is used to get directory listings, for example). I imagine there will be follow-up questions -- please address them to Teng (cc'ed), as I will be out of email contact for the next week, attending the ACM Hypertext conference. - Jim Whitehead
