hi Mike Mike Shapiro wrote: > On Mon, Jun 23, 2008 at 05:05:13PM +0100, Alan Maguire wrote: > >> webrev at: >> >> http://cr.opensolaris.org/~amaguire/smf_ordered_values/ >> >> Additional testing revealed some additional changes >> were needed beyond those described here: >> >> http://www.opensolaris.org/jive/thread.jspa?threadID=63250&tstart=0 >> >> Specifically, handling for nonglobal zones - where >> the persistent repository is immediately writable - >> and svccfg handling of multivalued properties on >> import needed to be addressed also. The first issue >> is solved by an additional upgrade check, the >> second is solved by changing the uu_list svccfg >> uses to store property values during import to >> be ordered, rather than sorting it by strcmp()-based >> comparison of values. >> >> I've tested this pretty thoroughly in global and >> nonglobal zones, run the SMF test suite in >> baseline, bfu-upgraded and bfu-downgraded >> scenarios, and all tests pass as expected (though >> a few tweaks to a few SMF suite testcases are needed >> since they expect imported values to be in a >> strcmp()-sorted order). I'll do some xVM testing >> also - are there any other suggestions for test >> scenarios beyond this and the bfu upgrade/downgrade >> (with nonglobal zones configured and tested also) >> testing mentioned above? Thanks! >> >> Alan >> > > Alan -- > > Fantastic work and sorely needed: thanks for doing this. I looked it > over and it looks good to me. Thanks for taking a look! > One thing I would ask that you check is > to write a trivial micro-benchmark for element get/set and make sure > that the schema change hasn't encountered some unforeseen sqlite > behavior where we have substantively regressed basic property r/w performance. > I can't see why that would be, but it would be nice to check. Good idea. I put together a simple test that times scf_transaction_commit()s and scf_pg_get_property() calls. For property retrieval, there are no significant differences (in the sense of being outside the standard deviation - my stats are a bit rusty, sorry!) in performance between baseline and upgraded schema for retrieval of 1, 10 or 100-value properties on x86 or sparc. For property setting, there is a measurable performance hit for 100-value property setting, which will probably be rare in practice. More details here:
http://cr.opensolaris.org/~amaguire/SMF_repository_change_perf_info.pdf I can dive into the backend with DTrace if needed, but it seems like there?s no major regressions performance-wise for practical use. Tom Whitten wrote: > Changes look good to me, Alan. > > tom > Thanks Tom! (One thing I should mention - I?ve added a VACUUM command to the upgrade SQL commands so that the repository doesn?t grow as a byproduct of the copying/deleting tables. Just a one-line change to the webrev, but I thought I should mention it). Alan
