Slow WebDAV response

I am using Zimbra as my mail server, and have implemented a WebDAV client so users can send/receive attachments directly to NC. The problem that I see now is that it takes approx 26 seconds before I see a response coming from NC.

Below is a screenshot of TCP trace, it shows the request coming in at 3.3 sec (since the trace started). And NC responds at 29.3. Which is 26 seconds after the request.

When I view the folder in NC web page it is almost immediate. I also get the same behaviour if I select and empty folder via the Zimbra WebDAV client. It also takes approx 26 sec before it shows it is an empty folder.

I don’t see any high CPU usage or I/O delay.

I can see a difference in the request packet (PROPFIND) between the ZImbra client and for example Cadaver command line client.

This is the working version (Cadaver) which response as expected:
No. Time Source Destination Protocol Length Info
18 3.234744 192.168.7.241 192.168.7.245 HTTP/XML 771 PROPFIND /remote.php/webdav/Documents/ HTTP/1.1

Frame 18: 771 bytes on wire (6168 bits), 771 bytes captured (6168 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 192.168.7.241 (192.168.7.241), Dst: 192.168.7.245 (192.168.7.245)
Transmission Control Protocol, Src Port: 36120 (36120), Dst Port: 8081 (8081), Seq: 1331, Ack: 5069, Len: 703
Hypertext Transfer Protocol
    PROPFIND /remote.php/webdav/Documents/ HTTP/1.1\r\n
    Host: <cloud-domain>\r\n
    User-Agent: cadaver/0.23.3 neon/0.30.1\r\n
    Depth: 1\r\n
    Content-Type: application/xml\r\n
    Authorization: Basic ********\r\n
        Credentials: ********
    X-Forwarded-Proto: https\r\n
    Via: 1.1 <cloud-domain>\r\n
    X-Forwarded-For: 62.253.85.245\r\n
    X-Forwarded-Host: <cloud-domain>\r\n
    X-Forwarded-Server: <cloud-domain>\r\n
    Connection: Keep-Alive\r\n
    Content-Length: 288\r\n
    \r\n
    [Full request URI: http://<cloud-domain>/remote.php/webdav/Documents/]
    [HTTP request 4/4]
    [Prev request in frame: 14]
    [Response in frame: 24]
eXtensible Markup Language
    <?xml
        version="1.0"
        encoding="utf-8"
        ?>
    <propfind
        xmlns="DAV:">
        <prop>
            <getcontentlength
                xmlns="DAV:"/>
            <getlastmodified
                xmlns="DAV:"/>
            <executable
                xmlns="http://apache.org/dav/props/"/>
            <resourcetype
                xmlns="DAV:"/>
            <checked-in
                xmlns="DAV:"/>
            <checked-out
                xmlns="DAV:"/>
            </prop>
        </propfind>

This is the failing one (Zimbra) which shows 25 seconds delay for the same folder request:
No. Time Source Destination Protocol Length Info
8 3.463214 192.168.7.241 192.168.7.245 HTTP/XML 619 PROPFIND /remote.php/webdav/Documents/ HTTP/1.1

Frame 8: 619 bytes on wire (4952 bits), 619 bytes captured (4952 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 192.168.7.241 (192.168.7.241), Dst: 192.168.7.245 (192.168.7.245)
Transmission Control Protocol, Src Port: 35890 (35890), Dst Port: 8081 (8081), Seq: 1, Ack: 1, Len: 551
Hypertext Transfer Protocol
    PROPFIND /remote.php/webdav/Documents/ HTTP/1.1\r\n
    Host: <cloud-domain>:443\r\n
    Depth: 1\r\n
    Content-Type: text/xml; charset=utf-8\r\n
    User-Agent: Sardine/UNAVAILABLE\r\n
    Accept-Encoding: gzip,deflate\r\n
    Authorization: Basic ********\r\n
        Credentials: ********
    X-Forwarded-Proto: https\r\n
    Via: 1.1 <cloud-domain>\r\n
    X-Forwarded-For: 78.129.138.120\r\n
    X-Forwarded-Host: <cloud-domain>:443\r\n
    X-Forwarded-Server: <cloud-domain>\r\n
    Connection: Keep-Alive\r\n
    Content-Length: 96\r\n
    \r\n
    [Full request URI: http://<cloud-domain>:443/remote.php/webdav/Documents/]
    [HTTP request 1/1]
    [Response in frame: 55]
eXtensible Markup Language
    <?xml
        version="1.0"
        encoding="UTF-8"
        standalone="yes"
        ?>
    <propfind
        xmlns="DAV:">
        <prop/>
        </propfind>

I think this is linked to a known issue where PHP is using too much memory. It seems after resolving this issue my WebDAV response has improved.