<p>In seldom cases, you will need to start looking into efficiency issues with Chamilo. This guide is a work in progress intended to help administrators optimize their Chamilo installation.</p>
Set your xcache.ini configuration (/etc/php5/conf.d/xcache.ini) to match your system. For example, you *could* have something like this (intentionally hiding comments here):
<pre>
xcache.shm_scheme = "mmap"
xcache.size = 32M
xcache.count = 2
xcache.slots = 8K
xcache.ttl = 0
xcache.gc_interval = 0
xcache.var_size = 16M
xcache.var_count = 16
xcache.var_slots = 8K
xcache.var_ttl = 60
xcache.var_maxttl = 300
xcache.var_gc_interval = 300
xcache.test = Off
</pre>
xCache will feel useless until you actually start to put some variables in cache. If you're showing the "Who is online" counter, that's one of the best item there is to implement xCache.<br/>
For example, you could implement it this way (in main/inc/banner.inc.php):<br/>
<pre>
$xc = function_exists('xcache_isset');
$number = 0;
if ($xc && xcache_isset('campus_chamilo_org_whoisonline_count_simple')) {
Note that, as xCache is a shared caching system, it is very important to prefix your variables with a domain name or some kind of identifier, otherwise it would end up in disaster if you use a shared server for several portals.<br/>
An optional additional caching mechanism you may use is the realpath_cache_size and realpath_cache_ttl php.ini parameters. See <ahref="http://php.net/manual/en/ini.core.php">the PHP documentation</a> for more details.
In Chamilo 1.9 in particular, due to the merge of all databases into one, you might experience performance issue if you have many learning paths with many items in them.<br/>
To solve this performance issue, you can execute the following queries manually in your database:<br/>
<pre>
ALTER TABLE lp_item ADD INDEX idx_c_lp_item_cid_lp_id (c_id, lp_id);
ALTER TABLE lp_item_view ADD INDEX idx_c_lp_item_view_cid_lp_view_id_lp_item_id (c_id, lp_view_id, lp_item_id);
</pre>
These will be available in Chamilo 1.10 directly, but we cannot put them into Chamilo 1.9 from now on for organizational reasons.<br/>
Create 10 directories inside the main/upload/users directory (from 0 to 9) and update your admin settings. This has to be done at install & configuration time, otherwise you might loose user data (or have to write a script for data distribution).
Although this will not make your server faster, compressing the pages you are sending to the users will definitely make them feel like your website's responses are a lot faster, and thus increase their well-being when using Chamilo.<br/><br/>
Zlib output compression has to be set at two levels: PHP configuration for PHP pages and Apache for images and CSS.<br/><br/>
To update the PHP configuration (either in php.ini or in your VirtualHost), use the <ahref="http://php.net/manual/en/zlib.configuration.php">zlib.output_compression</a>. If you set this inside your Apache's VirtualHost, you should use the following syntax.
Configuring your Apache server to use output compression is a bit trickier. You have to use <ahref="http://httpd.apache.org/docs/2.2/mod/mod_deflate.html">the mod_deflate module</a> to do it. Your configuration should look like something like this (please read the corresponding documentation before implementing in production).<br/>
Don't have time or resources to optimize your Chamilo installation yourself? Hire an <ahref="http://www.chamilo.org/en/providers">official Chamilo provider</a> and get it sorted out professionally by specialists.
<h2><aname="7.High-numbers-memory"></a>Memory considerations for high numbers of users</h2>
Some administration scripts *have to* handle lists of all users, and this might have a considerable impact on portals with very high numbers of users. For example, the main/admin/add_users_to_session.php script that handles the registration of users into a specific session, if used with the (non-default) full list of users, will devour about 3KB per user, which, for 100,000 users, translates into the need for around 300MB of RAM just to show this page, and to around 3GB for 1,000,000 users.<br/>
This mode is not loaded by default, but could still be selected, leading to a "Fatal error: Allowed memory size ... exhausted" message.<br/>
The only non-scripted solution here is to allow for the corresponding amount of RAM for your PHP configuration (<em>memory_limit = 300M</em>) or your specific VirtualHost if you use mod-php5 (<em>php_value memory_limit 300M</em>).<br/>