10.5 WebDAV Slowness

Question

Level 1

0 points

10.5 WebDAV Slowness

A service I support running apache 2.0.61 with mod_proxy has been experiencing slowness for any 10.5.5 users browsing (https) WebDAV shares on it via Finder. (cd-ing, ls-ing, etc from the command do not see the slowness)

Those using 10.4 (and possibly some older 10.5.x clients) see no issues.

I found this apple thread

http://discussions.apple.com/thread.jspa?messageID=8101932&#8101932

but it doesn't definitively list the source of the issue. Can anyone offer any additional insight?

Mac OS X (10.5.5)

Posted on Oct 2, 2008 11:17 AM

Reply

Answer 1

etresoft

Level 9

56,656 points

Oct 2, 2008 11:47 AM in response to mr-fish

mr-fish wrote:
Those using 10.4 (and possibly some older 10.5.x clients) see no issues.

Really? The Finder's WebDAV has been dog-slow for as long as I can remember. Can you verify that there really is a difference?

Reply

Answer 2

mr-fish Author

Level 1

0 points

Oct 2, 2008 11:54 AM in response to etresoft

I can say for certain it's a remarkable difference in speed.

I too had thought it was always slow, but have had Leopard since I began supporting the service. When I was shown a (fast) 10.4 client, I was surprised.

Reply

Answer 3

etresoft

Level 9

56,656 points

Oct 2, 2008 7:29 PM in response to mr-fish

I still have a hard time believing that 10.4 is fast. Try it using some other WebDAV tool, such as Goliath. WebDAV is something that I've really been excited about, but very disappointed with. Windows, for example, is much, much faster on WebDAV than the Mac. However, Windows' WebDAV implementation is notoriously flaky with only some specific versions that even work at all, sometimes with specific servers.

It may be that Leopard just doesn't "cheat" at WebDAV anymore. Using WebDAV on Tiger is very fast to copy files, it just seems to take forever to "close" them. I just did a quick check on Leopard and the behavior seems to be different and more honest. It also (I'm using 10.5.4) seems pretty quick compared to what I remember from Tiger. Perhaps it is a problem specific to 10.5.5.

Reply

Answer 4

mr-fish Author

Level 1

0 points

Oct 3, 2008 5:07 AM in response to etresoft

10.4 is an order of magnitude faster relative to 10.5.

In looking at the apache access logs, I see that the 10.5 client (WebDAVFS/1.7) attempts to a PROPFIND for files/directories with a "._"<directory> for every file and directory in each directory it traverses. Right when the requests for these directories 404s, Finder displays the results. For directories with a large amount of files/subdirectories, it takes a while for the 404s to all be returned.

The "._' are resource forks/Finder metadata/extended attributes for each of the files. I don't think it's possible to disable their creation for network file systems, but would love to hear if it is. Why the 10.4 DAV client (WebDAVFS/1.4.3) doesn't request them is bugging me quite a bit. Is there anyway to change this behavior in Finder in 10.5?

Reply

Answer 5

etresoft

Level 9

56,656 points

Oct 3, 2008 6:52 AM in response to mr-fish

Maybe in the 3 years that 10.4 has been out, people have found and applied hints like this to disable these files on network shares. Try turning this feature off on Leopard and see if it speeds things up.

Reply

Answer 6

mr-fish Author

Level 1

0 points

Oct 3, 2008 7:06 AM in response to etresoft

.DS_Store files are not the same as resource fork files. Unfortunately, this setting is not applicable to the "._" problem.

Reply

Answer 7

etresoft

Level 9

56,656 points

Oct 3, 2008 10:08 AM in response to mr-fish

After reading this page, it looks like the problem goes beyond .DS_Store or metadata files. You can file a bug report with Apple, but it may be some time before it gets fixed. In the interim, your best solution might be to suggest users install MacFUSE and use its webDAV client.

Reply

Answer 8

mr-fish Author

Level 1

0 points

Oct 3, 2008 11:09 AM in response to etresoft

It still bothers me that 10.4 / WebDAVFS/1.4.3 didn't behave this way. It would be comforting to find a page (from Apple would be ideal) that definitively indicates there is a difference between the clients and that there's no way to change it.

I've used FUSE before & like it quite a bit, but I don't think it's reasonable to expect end users to compile their own FUSE DAV plug in. Because of another unix timesharing service here that nfs mounts the same target file systems, the built-in sshfs support helps some of our users with this problem, but access to that service is limited & so only a minority of our OS X users gain anything from it.

The 'auto_xattr' option listed in the macfuse options ( http://code.google.com/p/macfuse/wiki/OPTIONS) does leave me with hope Finder's behavior can be adjusted.

For the sake of completeness and a hope it may help others who stumble across this thread, here are some additional links I can across while looking into this issue.

Ignoring the title of the page (although fitting), some good info on Apple Double files is here:

http://www.litfuel.net/plush/?postid=147

Additional info here:

http://arstechnica.com/reviews/os/macosx-10-4.ars/7
http://en.wikipedia.org/wiki/AppleDouble

This also explains why cd-ing/ls-ing, etc works without slowness from terminal.app - only finder uses the extended attributes.

Related info on the .DS_Store file here:

http://www.macosxhints.com/article.php?story=2005070300463515&query=smb

Reply