MidCOM QB optimizations

Posted on 2007-08-31 10:40:36 EEST.

Yesterday was the MidCOM performance sprint, I did some optimization and cleanup to MidCOM QB and Collector, here are some numbers (as seen on #midgard @irg.freenode.net)

[09:50am] mashiara: some numbers for effects of the QB limit/offset stuff backported to 2.8 branch
[09:50am] mashiara:  http://rambo.pbt-unknown.org/photos/list/all/?org_openpsa_qbpager_org_routamc_photostream_photo_page=6
[09:50am] mashiara: LORI time-to-first-byte (==midcom page generation time)
[09:50am] mashiara: ## Before QB backport:
[09:50am] mashiara: 4.316
[09:50am] mashiara: 4.301
[09:50am] mashiara: 4.285
[09:50am] mashiara: 4.334
[09:50am] mashiara: 4.707
[09:50am] mashiara: ## After QB backport
[09:50am] mashiara: 4.192
[09:50am] mashiara: 3.404
[09:50am] mashiara: 3.061
[09:50am] mashiara: 2.991
[09:50am] mashiara: 3.039
[09:50am] mashiara: 3.181
[09:52am] mashiara: all caches etc are on, without ACL cache the hit from
 fetching ACL for all photos in the stream (as opposed to just the set required
 to get this far) would be much higher

These optimizations have been backported to 2.8 branch and the numbers are from there.

Also yesterday (in trunk) I added to dbclassloader (that autogenerates the DBA base classes) reflection based code generation for get_parent_guid_uncached and get_parent_guid_uncached_static which uses collector to resolve the values, should be fairly fast, though in compound it might slow some components a bit when their objects previously did not resolve parent chains at all (by default get_parent_guid_uncached returned null...) and now they do, components that overloaded said methods to provide the functionality should review those and either drop the overload or make a better collector based implementation than the reflection based code generator has.

Back

Layout Copyright © 2006 Finnish Teleservice Center Ltd Oy - Site Powered by Midgard CMS