[BlueOnyx:20708] Aventurin{e} 6108R & BlueOnyx 520XR: Large update coming

[Michael Stauber]

Hi all,

I just want to give a small heads up for a large update of Aventurin{e}
6108R, BlueOnyx 5207R, 5208R and 5209R that is currently in the making.

Here is the TL;DR:
==================

On the 1st of March I will release around 400 updates for Aventurin{e}
6108R in one go. These will go straight into the production repository.

Shortly after that around 400-500 updates will hit the BlueOnyx 5207R,
5208R and 5209R *testing* YUM repository. These updates will remain in
the testing repository until 5th of March. On the 6th of March they will
be hitting the production YUM repository.

These updates modernize the underlying architecture of the Chorizo GUI
and should bring a net speed increase of roughly 50% (or better) for
*all* GUI related page loads.


The not so technical details for those interested in them:
===========================================================

There has always been one technical issue in the innards that had me
scratching my head. I knew we were doing certain repetitive tasks on
every GUI page load. And that the GUI would be faster if we could
eliminate these repetitive tasks and just do them once per page load.
Some of those could even be cached and be done only once per session,
which would be tremendously beneficial.

Part of the problem is how it's all "glued together": CodeIgniter on one
hand and the remains of the Sausalito engine on the other hand. Between
our PHP Classes ServerScriptHelper.php, CceClient.php,  Capabilities.php
and BxPage.php we had a lot of friction and even some duplication of
tasks and methods.

This stems from which class is instantiated from where and how to share
data between them. If ServerScriptHelper needs the "System" Object from
CODB, it would fetch it. If Capabilities.php needed the "System" Object,
it would fetch it as well. Same for all other classes.

Anything ACL related (finding out what access rights exist and if the
currently logged in user has an applicable access right for the
transaction or view request) was especially "costly". Costly in terms of
CODB transactions, as somewhere between 12 and 20 CODB FIND, NAMES and
GET requests had to be made.

However: If done right we need to poll this only once per session and
can cache the information. Until either the session ends or expires. Or
the ACLs of this user are elevated or reduced by a higher privileged user.

By implementing such a cache and making it globally accessible for all
GUI modules and Classes we dropped about 20 CODB requests past the
initial login. Just for the ACL's.

Further optimizations and globally instantiating important repetitive
info netted another 30-40 eliminate CODB transactions.

Likewise: Some "baggage" pages of the GUI (jQuery scripts that are
loaded by every GUI page) got trimmed down to no longer use CCE at all.
Unless they absolutely have to. That also dropped another half dozen
CODB requests.


Will this update be disruptive?
================================

I don't think so and I'll do my best to NOT make it disruptive.

Although the underlying changes are pretty massive: All GUI pages from
included modules (or from PKGs in the store) remain compatible. No
existing methods or calls have been deprecated.

Which is good.

This alone already gives GUI pages that use the older coding standards a
net speed increase of about 30-40% due to a general reduction in
repetitive tasks.

However: To make full use of the speed increase *all* GUI pages need
some minor changes.

Hence the massive update. I'm in the process of making code changes in
all GUI pages of all modules and they will be published soon as
indicated on top of this message.

Likewise: All PKGs in the BlueOnyx shop that have GUI pages will be
overhauled and updates for these PKGs will be made available.


Is it worth it?
================

Oh dear. It is. \o/

Say you go to the GUI login page and enter your username and password
and hit the login button. Say you logged in as "admin", so the first
page you will see is the /swupdate/news page.

By the time this page has loaded the GUI will have made 132 CODB
transactions. After the improvements are in place this number drops to
60 CODB transactions.

Now what happens if you hit "reload" in your browser on the same page?

The previous version of the GUI then does 77 CODB transactions. The new
version makes do with 16. The main reduction here comes from the caching
of the ACL related data and not having to do further AUTHKEY requests
between the start of the page load until the page is fully displayed in
your browser.

And after the first login and first page load all subsequent page loads
will continue to make do with about 70-80% less CODB transactions,
because the bulk of the relevant info (the ACLs) have already been
fetched and are now cached for the rest of the session. Or something
happens that warrants re-building the Cache. Like promoting a regular
user to siteAdmin or demoting a siteAdmin back to regular User. Just to
give an example. In that case the cached ACLs of this user (if he is
currently logged in) will be expired and get rebuild once.

There are still pages that need many, many CODB transactions that take
time. Such as taking a look at the Vsite or User list. Because there we
need to poll every relevant Vsite or User Object to fetch some data for
display or calculations. But even those benefit from the changes, as
they don't need to do the 60 repetitive CODB requests that we eliminated.

All in all: This should be good.

-- 
With best regards

Michael Stauber