Re: mod_dav_fs locking / Re: apr_dbm and concurrency
Joe Orton <[email protected]>
| Newsgroups | gmane.comp.apache.apr.devel |
|---|---|
| Organization | Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US) |
| Message-ID | <ZWBmHJbBv7dUX7ke__17587.4923051865$1700817310$gmane$org@redhat.com> |
On Thu, Nov 23, 2023 at 05:42:10PM +0000, Emmanuel Dreyfus wrote: > On Thu, Nov 23, 2023 at 05:36:06PM +0000, Joe Orton wrote: > > 3) in the mean time I worked up a PR for mod_dav_fs which adds a global > > mutex around the dbm lockdb use. This passes my stress tests for the > > first time. > > How concurent is the stress test? I've been testing with 20 concurrent clients on an 8 core machine. > In the past, I have been badly hurt by a few WebDAV clients proactively > exploring the filesystem using locksdiscovery. That compeltely killed the > service. I introduced the DavLockDiscovery directive to work it around. This is a good point. Was the load in that case PRPOFIND/depth:infinity do you know or "just" depth:1? A global lock like in my PR would make the PROPFIND load even worse, since the lock is held for the duration of the response and there are no concurrent read-only locks. It might be necessary to disable lock discovery by default then, I don't know if any clients rely on or expose that but it's only a "MAY" that lock discvovery is possible in RFC4918. I suspect the lock recovery mechanism for most users & clients is to delete the lockdb. Regards, Joe