[Aplaws-devel] [aplaws - Developing on APLAWS+] Performance

[Aplaws D. L. <apl...@li...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=4278168
By: cgyg9330

On our site, publishing times have suddenly started getting worse and worse
- even small multipart articles are now taking over a minute to publish, and
our gatekeepers are fed up with frequent deadlocks (caused by publishing several
articles in different windows) and publishing that seems to take hours.

I have been looking into this and tracked the performance hit to updates on
dnm_object_1_granted_context table executed in the change_context procedure.
As far as I can tell, there is little that can be done to speed up the sql (though
having said that I can't entirely get my head around the way that the start
with...connect by...prior syntax is applied here).

However, the number of entries added to the dnm tables is pretty liberal at
the moment, as is the number of context updates. It is possible to completely
avoid many calls to change_context, and I am fairly sure that dnm entries are
only really required for objects that have a permission context or have permissions
granted directly - ie objects that have any kind of access control presence.

I have been experimenting on my test instance, and have got publish times on
a three section multipart article down from 72 seconds to 6.5 seconds. Tests
so far show no adverse effects.

Changes are:

PermissionManager - in setContext method, only set context if it has changed
- the persistence layer doesn't always realise when an entry hasn't been modified,
because of entries made by triggers.

Triggers - currently entries are added to dnm_object_1_granted_context, and
change_context is procedure called, for every acs_object created. Changed to
only add entries when context is set or when permission added.

Permission check sql in permissions.pdl - small change to queries required for
some permission checks - eg on site nodes (objects with no context/privileges
have 0 as their context in dnm tables - 0 is an object with all privileges granted
to site-wide-admin). The change has had no impact on the duration of permission
checks - fortunately - the whole point of the dnm tables is to ensure permission
checks are quick.

delete all existing entries from dnm_object_1_granted_context where the associated
object_context entry has null context and there are no entries in acs_permissions
(that's 145000 out of 173000 entries on my test instance!!)

Minor additional changes

ContentItem - don't automatically set context to the content section on all
items - it never remains as that, and it seems to be an unneccesary overhead

Article text - don't set article as parent of text - the relationship is already
recorded in text_pages, and setting parent means adding an unneccessary
object_context with associated overhead.

Get rid of surplus acs_objects with associated object_context and dnm entries
- lifecycles and notifications can optionally be deleted, I have added config
parameter to specify whether you want them deleted when complete.

I am going through checking for any horrible errors I may have introduced, and
will eventually submit a patch when I am confident that everything is working.
I have only made changes to Oracle versions of the triggers - I am not sure
about writing triggers in postgres sql. Without these changes there are only
minor benefits for pg users - the change to PermissionManager speeds things
up a litle bit.

Chris.......

If anyone is interested in trying out these changes, I can send an early patch 
 

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=368401