Forum OpenACS Development: Re: Towards OpenACS 5.9

Collapse
34: Re: Towards OpenACS 5.9 (response to 1)
Posted by Gustaf Neumann on
Here are some tests comparing acs_object/cr_item creation/deletion in OpenACS 5.8.1 vs. the forthcoming OpenACS 5.9.0 (current version of the oacs-5-9 branch) caused by the measures 1 to 4 in [1].

In short, all these operations are faster in oacs-5-9

  • acs_object creation: 16% faster
  • acs_object deletion: 6% faster
  • cr_item creation: 6% faster
  • cr_item deletion: 9% faster
All these tests were performed in fresh "empty" installations (containing only acs-core + xotcl-core) on a Mac OS X Notebook (2.8 GHz Intel Core i7 with PostgreSQL 9.4.4). The tests first insert 100K acs-objects and delete it, later it inserts 100K cr-items and deletes it again. Below is the raw test data.

As mentioned above, on sites with millions acs-objects, the improvements can be mich larger. An update operation on the context_id of an acs_object dropped on our live system from 2.5 minutes to 10 seconds (under this context_id is a large tree of objects). On operations with leaf objects, the difference will be much less. The changes are especially good for large sites and improve the scalability of OpenACS.

-g

[1] https://openacs.org/xowiki/openacs-todo

=== OpenACS 5.8.1
    acs_objects created 100000, total 85945ms, 0.8595ms / object
    acs_objects deleted 100000, total 152611ms, 1.5261ms / object
    cr_items created 100000, total 206543ms, 2.0654ms / object
    cr_items deleted 100000, total 432189ms, 4.3219ms / object

=== OpenACS 5.9.0
    acs_objects created 100000, total 72457ms, 0.7246ms / object
    acs_objects deleted 100000, total 143823ms, 1.4382ms / object
    cr_items created 100000, total 193504ms, 1.9350ms / object
    cr_items deleted 100000, total 395428ms, 3.9543ms / object
Collapse
35: Re: Towards OpenACS 5.9 (response to 34)
Posted by Gustaf Neumann on
Dear all,

there will be a beta2 release of OpenACS 5.9, which i hope to be able to package on the weekend. Among a few small upgrade glitches i've updated the timezone reference data. The old data was 7 years old, we have now 43 more timezones and many fixes and updates.

best regards
-gustaf neumann

Collapse
36: Re: Towards OpenACS 5.9 (response to 35)
Posted by Gustaf Neumann on
OpenACS 5.9.0 Beta 2 is now available.
Collapse
37: Re: Towards OpenACS 5.9 (response to 36)
Posted by Gustaf Neumann on
OpenACS.org runs now on OpenACS 5.9.0 Beta 2
Collapse
38: Re: Towards OpenACS 5.9 (response to 37)
Posted by Gustaf Neumann on
Due to the early usage of OpenACS 5.9.0 Beta 2, several (old and new) bugs showed up, that i am fixing step by step. i apologize for possible errors generated from openacs.org visible to probably some users. However, this process helps to get out finally a better OpenACS 5.9.0 release. Things are stabilizing already....
Collapse
39: Re: Towards OpenACS 5.9 (response to 38)
Posted by Gustaf Neumann on
Just to keep you updated: it turned out that debian packaging become more tedious than in the past. The original goal was to provide a Debian package more or less with stock OpenACS 5.9.0. Hector was starting with this work, but several obstacles appeared. One problem area is the debian conformity checker, which becomes more and pickier. Some of the complaints could be addressed quickly, others are more complicated.

For example, just recently, the checker complains about minified .js files, which are not regarded as source code anymore. So we have to get rid of all minified files in the debian distro (and all references to it in the source). This affects mostly the rich-text editors. It looks to me as if the best solution would be to pull out the editors from acs-core and to make it own packages, which can be installed via "install from repository" in the future (... but that will require same refactoring).

Another problem are is the aolserver package in debian, which is in a very old state, but the the debian maintainers are quite unresponsive concerning bug reports. Hector has started to look into the details, how to getting a NaviServer package into debian (there is some work from the people at qcode.co.uk we can build upon). But in any case, the cycles are rather slow.

Short message: we are on it, we are getting closer to a release.

Collapse
40: Re: Towards OpenACS 5.9 (response to 39)
Posted by Michael Aram on

+1 for a stronger modularization with respect to external libraries.

As I have suggested earlier, I sympathize with the idea of having dedicated OpenACS packages for external JS libraries such as jQuery, YUI2, Bootstrap, etc...

These could follow a naming conventions similar to acs-* such as e.g. vendor-*, external-*.

Collapse
41: Re: Towards OpenACS 5.9 (response to 40)
Posted by Gustaf Neumann on
The actual problem with debian packaging just concerns core, since the js libraries for the richtext editors are embedded in acs-templating. In order to move these out, a better interface than we have now would be desirable, that addresses the needs of the currently used rich-text editors. This might be a goal for OpenACS 5.9.1.

But certainly, better approaches than ajaxhelper to handle complex js frameworks like bootstrap/yui/ext/... etc are as well needed, but that might be candidates for theming packages, since mixing theses is though...