pathological DAV request behavior
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| gvfs |
Invalid
|
Medium
|
|||
| gvfs (Ubuntu) |
Triaged
|
Low
|
Ubuntu Desktop Bugs | ||
Bug Description
Binary package hint: gvfs
I reported this in bug 259771 yesterday, but now I think it is worth its own bug report:
----
FWIW, I see the attached behavior when I try to browse a DAV share from
an apache2 server.
On connect to the server, PROPFIND / is issued once with Depth 1. It
takes a while, because this directory has over 1000 subdirectories.
That's reasonable. Okay so far.
Then the weird stuff begins. When I click "311" (ignoring my taste in
music for a moment), the *exact same* PROPFIND /311 with Depth 0 request
is issued *twice* in a row over the same connection. Exactly the same
headers, exactly the same result. I see other redundant requests, as
well.
But then it gets *really* strange. After PROPFIND /311 with Depth 1 is
issued, gvfs issues *another* PROPFIND / with Depth 1! In god's name,
why? This appears to be the root of the slowdown I see: the needless
repetition of requests for data that seconds before had been
transferred. And I suspect the SMB gvfs backend is doing something
similar.
Not sure if local caching + If-Modified-Since requests are valid here,
but that may be a potential solution. Nautilus may be re-reading the
parent directory unnecessarily; however, IMO the gvfs backend should be
able to more gracefully deal with this situation, since not every
application in existence can be rewritten to assume the data it is
accessing is 20 mbits and 70 msec away. In my case, this is data that
hardly ever changes: the only time the root directory of this DAV share
changes is when I rip a new CD, which probably occurs once every few
weeks.
(Aside: this stuff is even slower over GnuTLS SSL (16 seconds for
PROPFIND / vs. about 2 seconds plaintext), the difference of which I
can't yet explain since I can't tcpdump the SSL connection.)
My gvfs and related components are 0.2.5-0ubuntu2 (hardy up-to-date).
My nautilus is 1:2.22.5.1-0ubuntu1 (also hardy up-to-date).
----
Furthermore, it has become clear by looking at my apache logs that the gnome DAV's request behavior is completely pathological. For one 5418548 byte Ogg file, I see the following requests with the bytes served in the 7th field:
192.168.33.1:80 192.168.35.130 3286 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3286 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3286 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3286 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3287 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3286 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3290 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3283 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3286 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3286 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3284 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3321 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3321 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3286 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3286 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3321 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3285 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3287 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3290 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3283 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3284 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3321 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3285 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3287 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3290 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3286 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3286 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3283 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3284 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3321 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3285 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3287 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3290 krose [16/Oct/
192.168.33.1:80 192.168.35.130 3290 krose [16/Oct/
If you're not counting, that's 39739742 bytes---about 38 MB---transferred for one 5 MB Ogg file played continuously without interruption. Clearly, gvfs (or at least the DAV backend) needs better caching behavior.
| Sebastien Bacher (seb128) wrote | #1 |
| Changed in gvfs: | |
| assignee: | nobody → desktop-bugs |
| importance: | Undecided → Low |
| squarooticus (krose) wrote | #2 |
| Sebastien Bacher (seb128) wrote | #3 |
| Changed in gvfs: | |
| status: | New → Triaged |
| Changed in gvfs: | |
| status: | Unknown → New |
| Changed in gvfs: | |
| status: | New → Confirmed |
| Changed in gvfs: | |
| importance: | Unknown → Medium |
| Changed in gvfs: | |
| status: | Confirmed → Invalid |
thank you for your bug report, could you open a bug on bugzilla.gnome.org too where the people writting the software will read it, you will probably get a better reply on such technical issues there