Performance Issues

From Dokeos

On this page we will gather information about possible performance problems you may have, the possible causes and possible solutions. This will mostly be a collaborative effort to put everything performance-related on this page and try to go in-depth for the best solution.

These solutions will typically range from changing your server configuration (linux or windows), optimizing the Apache and MySQL configuration, adding indexes on specific table columns, and much more. Even rewriting/optimizing the dokeos code will be part of getting the best performance.

1 General performance tuning
2 Dokeos specific performance tuning
3 Resources
4 See also

General performance tuning

System monitoring and tuning

System monitoring is the first step in locating performance problems and remains an important task during the life-cycle of the entire project. A lot of tools exist to monitor the system. Typically you'll want to take a look at :

Memory usage (vmstat, top,...)
- Physical memory
- Virtual memory
- Swap usage
CPU states and load (top, sar,...)
Processlists (ps)
Hard disk usage and load (iostat, sar,...)
Network usage and load (netstat, sar,...)

Tuning a system depends heavily on the purpose of the server. However, on most servers you'll need to :

Remove obsolete, unused packages from the system to keep as much free cpu cycles as possible
Compile the core tools used on the server from the source code to have the binary tuned to the capabilities of your system.
...

MySQL monitoring and tuning

The database can be monitored using the processlist. If you have phpMyAdmin installed, you can access it through you browser. It will list the running queries (queries that run less than 1 sec. will be harder to spot), with running time, status and SQL code. Using this list, you can easily see when queries need too much time to run (>15s).

Though this method can come in handy visually, there are some inherent problems:

It's not possible to track a browsing session of a single person. Instead, all (running) queries are listed.
When there are too many MySQL connections, you can no longer list these processes (or kill the ones that may hang) and you may even have to restart your DB-server.
This technique is not meant for pure monitoring or measuring performance, but is mostly used only as a database management tool.

Because of these minuses, it's better to use PHP Profiling to measure the performance of SQL queries.

Alternatively you can enable (in the my.cnf file) the logging of slow queries. This will create a separate log file with the SQL code and more detailed information for the query.

Tuning a MySQL database depends heavily on the amount of information will be processed. With most MySQL distributions, there are a number of example config files included (my-small.cnf, my-medium.cnf, my-large.cnf and my-huge.cnf). You can use these as a base to create your customized config file. More information about the possible tuning values are available on the MySQL manual.

Things you can optimize:

the maximum number of connections
a better processing of the connections
the memory usage for queries
...

Apache monitoring and tuning

There are also monitoring tools available for the Apache web server. One of the most important ones is the "Server Status" which is embedded in Apache itself. To enable it, you need to uncomment a few lines in the httpd.conf file:

 #
 # Allow server status reports generated by mod_status,
 # with the URL of http://servername/server-status
 # Change the ".example.com" to match your domain to enable.
 #
 <Location /server-status>
     SetHandler server-status
     Order deny,allow
     Deny from all
     Allow from 127.0.0.1
 </Location>

If you need a more detailed look at the status you can also enable the extended status (use with care, as it might affect performance as well):

 #
 # ExtendedStatus controls whether Apache will generate "full" status
 # information (ExtendedStatus On) or just basic information (ExtendedStatus
 # Off) when the "server-status" handler is called. The default is Off.
 #
 ExtendedStatus On

While tuning Apache, you can compare with other config files, but mostly this is a trial-and-error approach. The different configuration options can be found on the Apache website. Most importantly are:

the maximum number of connections (before they get put in a queue)
how many internal servers should be listening for incoming requests
how long the connections should be kept open for subsequent requests
the internal processing of connections
...

Log monitoring

You can also monitor several log files. If you use logging for error_messages, you can pin-point the specific date and location of some problems. An unfortunate problem with log files is that they can easily grow very large and it's hard to search through them. A solution to this is to use log analysis tools.

Some log files to check :

/var/log/httpd/error_log
/var/log/httpd/access_log
/var/log/httpd/ssl_log
/var/log/mysqld.log
/var/log/messages
/var/log/sa (if you have the sysstat package installed, which includes "sar")
...

Benchmarks

A benchmark is a method to simulate a heavy load on a computer. In the case of dokeos, it can be used to simulate X number of users. The output of the benchmark will show how many users the server is able to process before putting them in a queue (and a delay may be noticeable). Using this information you can search for optimalisations, apply them to the server/software and run a new benchmark to check if there's any (and if so how much) improvement for the performance. A benchmark merely provides you with some statistical data. It doesn't pinpoint any problems nor does it show what is an abnormal value. If the numbers are not to your satisfaction, you'll have to search for any possible problems and try to solve/improve them.

Setting up a benchmark for a dynamic environment (PHP) with user-authentication is rather hard. However, if it is set up correctly, it may provide a general overview of which pages (requests) take a long time to be processed.

A few benchmarks available:

PHP Profiling

PHP Profiling is a new method for measuring performance. It runs PHP within a controlled environment and returns a report of such statistics as the time spent in a function, the time it takes for a database query to run, how much memory is being used, etc.

As with benchmarks, it takes some time and understanding to setup correctly, but once it is, you'll be able to pin-point the source of a performance problem much more easily. Regardless of this information you will still need to find solutions to the problem-source, but it's a starting point.

Information about profiling is available on :

Caching

Caching is a technique in which a caching server (other than your web-server), which is in between the user and the web-server, keeps a copy of the requested page on disk. Whenever the same page is requested the copy is sent back (as long as no changes have been made to it). It will alleviate some of the load for the web-server to send pages to the client.

In larger institutions this will probably be set up and work automatically. However, it's also possible to tune these settings in PHP, Apache, etc.

More information is available :

Caching Tutorial
e-Accelerator (a further development of mmcache, caching for PHP)

Dokeos specific performance tuning

Indices on statistic tables

Indices on scorm tables

In Dokeos up to 1.6.3, if the server is used intensely with SCORM contents, you can improve the MySQL server efficiency considerably (6-folds) by adding indexes on the SCORM tables (namely in the scorm database, the scorm_sco_data table) on the scoIdentifier, contentId and studentId fields.

This can be done very easily with phpMyAdmin by clicking on the lightning icon at the end of each field's line.