A few weeks ago, our version 4 demo server was unreachable for roughly 7 hours. After gaining access to the server again, I reviewed the log files and deduced the problem was simply a result of extremely high traffic volume. The demo had been using file-based caching up to that point, and APC wasn’t installed, so increased activity on the demo resulted in excessive file I/O and CPU usage skyrocketed. Some time ago, I wrote up a support article that gave tips on how to improve SocialEngine’s performance, and after applying these changes to the SE4 demo, there was a remarkable improvement. I kept a rough outline of all of the steps I took in setting up the server, and after requests from a few clients, I decided to make this information available.
First Thing’s First
The most important thing you can do to improve loading speed for a SocialEngine website is to make sure that you have sufficient CPU and memory resources available. Knowing this, and knowing that the database and application would be running on the same server, I chose a server with 4G of memory and a Quad core processor. There are two reasons why I chose a server with 4G of memory:
- Our chosen hosting provider locked us into a predefined a Processor and Memory
- Having reviewed the demo database using the mysqltuner script, I saw that we were only using 1G of memory
mysqltuner --user <username here> --pass <password here> [--] Data in InnoDB tables: 1G (Tables: 150)
A server with 4G of memory and a single Quad-core processor proved to be precisely what was needed for our usage.
There’s an element of uncertainty when moving an existing website to a new server, and with this in mind, I decided not to go with a traditional dedicated server. Instead, I opted for a cloud server at Rackspace for the layer of flexibility they provide in making changes to server configuration. From their control panel, it’s possible to migrate to a new instance with only a few minutes of downtime. Another reason why I chose a cloud server at Rackspace is because they allowed me to choose my preferred operating system, Ubuntu, and control panel software like cPanel or Plesk. Personally, I tend to avoid installing control panel software in order to keep server software as simple as possible.
To sum up what we have thus far:
Operating System: Ubuntu 10.04 LTS Hosting provider: Rackspace Memory: 4G Processor: Quad-Core AMD Opteron(tm) Processor 2374 HE
Installing and Configuring Server Sotfware
After spinning up the cloud server, the first thing I did was to update the package manager’s local index:
sudo apt-get update
Next, I made sure all of the core build packages that I’d be using were installed:
sudo apt-get install build-essential autotools-dev autoconf gcc g++ gcc-multilib g++-multilib re2c make
After this, I built my LAMP stack:
sudo apt-get install mysql-server mysql-client apache2 php5 apache2-threaded-dev php5-common php5-dev php-pear php5-curl php5-gd php5-imagick php5-json php5-mysql php5-cli libpcre3-dev
Then, I installed APC:
sudo pecl install http://pecl.php.net/get/APC-3.1.9.tgz
Before I could make use of APC, I needed to increase the kernel.shmmax setting so that I could allocate 128M of shared memory to APC. To do this, I edited the file /etc/sysctl.conf, appended the following line:
kernel.shmmax = 134217728
and ran the command:
sysctl -p
to load the changes made to the sysctl.conf file. With this change in place, I could finally enable APC, which was only installed previously and not enabled. To do this, I created the file /etc/php5/conf.d/apc.ini and added the following to the file:
extension=apc.so apc.shm_size=128
My next step was to make sure that the mysqli.reconnect directive was enabled. To do this, I edited the file /etc/php5/conf.d/mysqli.ini and added:
mysqli.reconnect=On
I then edited the /etc/mysql/my.cnf, and under the [mysqld] section, I added:
interactive_timeout=60 wait_timeout=60
There are a few other changes that I made to the MySQL configuration that were unique to this installation. Earlier, in this article I touched on how I used the mysqltuner tool to determine how much memory was being used by InnoDB, but the tool also suggests changes that can be made to MySQL to achieve better performance. The most important setting to change is innodb_buffer_pool_size.
The size in bytes of the memory buffer InnoDB uses to cache data and indexes of its tables. The default value is 8MB. The larger you set this value, the less disk I/O is needed to access data in tables.
This setting should be slightly greater than the amount of memory currently being used by InnoDB, and in the case of our demo, I raised the value to 1200M:
innodb_buffer_pool_size=1200M
MySQL can be sensitive at times, and a bit of caution is needed when configuring InnoDB. Misconfiguring InnoDB can prevent the engine from loading, which can produce a host of errors. After making changes to your my.cnf file, and after restarting the MySQL daemon, it’s a good idea to review the /var/log/mysql/error.log file for any errors.
The last change I made, which is less of a performance optimization, was simply to enable mod_rewrite which wasn’t enabled by default. To do this I ran the command:
a2enmod rewrite
To apply all of these changes, the Apache and MySQL daemons need to be restarted. To do this, I ran the following commands:
restart mysql /etc/init.d/apache2 restart
These changes alone produced a significant performance improvement, but there is still one more change that needs to be made. SocialEngine is still using file caching. To use APC with SocialEngine, I went into the Admin > Settings > Performance and Caching page and made sure APC was selected.
exit(0)
The information included in this article won’t work for all SE4 communities, however these changes worked well for us given our particular needs. Finally, a word of caution to those with root access. I would not suggest executing any of the commands included in this article without understanding what they do and their intended purposes. When in doubt, man <command> and when man fails, Google.
