Hello all
We at hogent are currently working at improving the performance of the
chamilo platform. We have found a very good software package which makes
it possible to profile our database queries which is called Jetprofiler.
We stumbled upon some issues where a lot of queries were used to render
one page (for example the browser of the repository application). A lot
of these issues where due to some basic structures like registrations
(which were contacted for each active application separately), menu
items (same as with registrations) and some other unnecessary calls to
the database. Adding a bit of caching here and there (in tables where
there are no more then 150 records) we were able to limit the amount of
queries drastically (for example in the repository we went from 150+
queries for 10 content objects to only 37 queries).
Although optimizing these things improved the performance already by 30%
(measured by stress tests with JMeter) we noticed in jetprofiler that
the top used queries where still the administration / settings tables.
After a deep analysis of the problem we noticed that the queries as such
were good queries, but they were listed as top queries because they
where called every often. More then once per request...
So we started digging into the code and soon noticed that global.inc is
called for a lot of side scripts that are launched either through css
files or javascript ajax. For example in the repository there are 3
calls to css files which are dynamically built (and even work
recursively) and there are 4 calls to an ajax file => utilities.php.
This means that global.inc.php is loaded at least 8 times per request,
thus retrieving all the settings, all the registrations and even add
some tracking that is used on each page. This means that there is a lot
of overhead created for one request. We think it should be possible to
minimize this overhead, especially since it's something very generic
that will happen on almost every page throughout the system. We propose
the following steps in order to optimize these problems.
1) global.inc seems to be a bit to heavy for use in ajax code etc. We
could try to split the global.inc in for example a common.inc and a real
global.inc. The common.inc could then be responsible for the oblivious
code from the global.inc and could require the global.inc. Through this
way the real pages on the system would use common.inc and have all the
code, and the ajax and other requests are using global.inc which would
only define the basic paths, autoloaders, install check etc. This would
avoid having the online, visit events to be triggered on every ajax
call. It's enough to trigger them for each request.
2) The css files are loaded dynamically each time. Though they are never
changed, except when the registrations change. They are also built on
php files which reads the active registrations and then render the css
files with the import statement. It could be a solution to statically
generate these import files when the registrations are changing (which
is not very often) so that the css file can be sent statically. Through
this way we could already save 3 calls to the global.inc and the
registrations table.
3) There are a lot of javascript / ajax calls that are called already
when the page is rendered the first time. For example for paths,
translations, themes etc. We think this should be optimized by caching
the utilities.js file and remove some oblivious calls to some settings.
These settings (like web path, theme etc) could be given to the
javascript file by printing them as html in the header. We could also
optimize this by avoiding that the system would do ajax calls when a
page just finished rendering. In our opinion it should be best that ajax
calls should only be called when a user interaction has happened.
As we already have a first release we think that this is a really
important topic. We would like to fix these issues but are welcoming all
remarks / feedback.
Best regards
--
Pieterjan Broekaert
Sven Vanpoucke
Digitaal Leren
Directie Onderwijs
Hogeschool Gent
http://digitaal-leren.hogent.be/
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
