Excellent work as always! I'd go for the b. option.
> Am 30.06.2020 um 22:39 schrieb Gustaf Neumann <neum...@wu.ac.at>: > > > Dear all, > > some of you might have noticed the recent changes in the NaviServer > repository concerning rwlocks. rwlocks support multiple concurrent readers > and behave like mutex locks in the case of writers. rwlocks can improve > concurrency especially in applications with many parallel threads and high > loads, but these are only better in cases, where there are more readers than > writers. > > The current version of NaviServer uses rwlocks e.g. for URLspace and for nsv > variables. Here are some statistics of these locks collected on a real-world > application (openacs.org): > > Name Locks Busy Read Write Write % > nsv:7:openacs.org 33.14M 4 33.13M 8.41K 0.03% > nsv:6:openacs.org 16.85M 249 16.4M 453.88K 2.69% > nsv:3:openacs.org 15.09M 3 15.04M 46.88K 0.31% > nsv:2:openacs.org 10.26M 5 10.23M 38.17K 0.37% > nsv:5:openacs.org 9.98M 0 9.98M 1.57K 0.02% > ns:rw:urlspace:4 4.45M 0 4.45M 86 0.00% > > As one can see, the vast majority of operations are read operations, where > typically less than one percent are write operations. One can see as well the > very little number of busy operations, where a lock has to be blocked. The > same site with the same traffic reaches about 2K busy locks for nsv:6 > (instead of 4) and about 3.5K busy locks for nsv:6 (instead of 249) on the > same number of locks. The improvements on the busy locks are significantly > higher on sites with more connection threads and more traffic. > > However, on some other applications, the write ratio might be different, and > there might not be always only improvements, as the test below show. > > In our little test, we create 20 background threads busily reading and > writing from nsv variables, while we are measuring of a foreground task > hammering on the very same nsv variables (with different mixes of background > tasks and writer percentages). > > The first chart shows results under macOS, relative to the same task using > mutex locks instead of rwlocks: > > <dnkmmdiholbgceok.png> > > In the first three columns, we see the performance without background traffic > (i.e. without concurrency). The performance is measured relative to the same > application using mutex locks (lower numbers are better). We see that > without concurrency, the rwlocks lead to better results (runtime improvement > about 25%). The next three columns show results with 20 background tasks, > just reading busily from the nsv variables. The version with rwlocks is > faster by a factor of 10 in the best case (just foreground and background > readers). But as one can see, the performance benefit reduces when more write > operations are performed. The last three columns show the situation, when we > have 50% read and write operations in the background. > > When we consider these values in combination with the statistics of > openacs.org, we see that we are there essentially in the sweep spot where > rwlocks shine (with practically no writers). > > The situation on Linux is different with less positive results (macOS seems > to have a very good implementation of POSIX rwlocks). While in the best > cases, the improvement on Linux is just a factor of 5 better than with mutex > locks, in the worst cases, the performance is nearly 3 times worse. > > <clckkhjfmbfhgjol.png> > > One should also notice that these values were achieved with a conservative > setting of rwlocks, which prevents writer starvation (the results would have > been better without these). > > Since on sites like openacs.org (and even more on our high traffic sites of > our e-learning environment), we are always in range of the first 5 bars, so > using rwlocks is a big improvement. The improvement will be even higher for > situations, where rwlocks are protecting areas where more computing intense > operations are performed, or when more cores are available, etc. > > However, there might be NaviServer applications with nsvs out there, for > which the change of using rwlocks for nsv variables might lead to a reduced > performance. So we have in general the following options for the forthcoming > release: > > a) hardwire nsvs to rwlocks > b) make it a compile-time decision to choose between rwlocks and mutex locks > for nsvs > c) provide a configuration variable in the config file to choose between > rwlocks and mutex locks for nsvs at startup > d) provide a runtime API for creating nsv arrays with rwlock or mutex > > Currently, we have essentially (b) in the repository. (c) seems feasible with > moderate implementation effort. (d) would be a larger project. > > What do you think? My approach would be to leave the code with (b) and > consider (c) in the future, when necessary ... unless someone convinces me > that more control is essential now. > > -g > > PS: Used hardware: > Linux machine: Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz, 10 cores + > hyperthreading, Fedora release 32. > macOS machine: 2,4 GHz Intel Core i9, 18.7.0 Darwin Kernel Version 18.7.0: > Mon Apr 27 20:09:39 PDT 2020; root:xnu-4903.278.35~1/RELEASE_X86_64 x86_64 > > > > _______________________________________________ > naviserver-devel mailing list > naviserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/naviserver-devel
_______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
