recommendations for a medium to large elgg site
I have seen a few questions on elgg scalability and hardware requirements recently.
After half a year of testing, setup and running of a medium sized elgg site (a few thousand members) I would like to post some recommendations to anyone who is interested. They are meant for sites that need to handle dozens or hundreds of *concurrent* elgg users. So if you have only 10 or 20 active users at the same time you don´t need to care.
Before you start: If you are interested in how many users your machine and server setup will handle install the plugin hu_skawa_genusers on a test installation and let it simulate the amount of users and activities you expect. The manual is very good and you should really take the time for a few hours of testing.
Hardware: elgg is very CPU-intensive because of the hundreds of PHP scripts and database queries that have to be made for every hit. For a large community you will need a dedicated machine and the fastest CPU you can afford. We bought a 4x 2,66 GHz CPU, 4 GB of RAM and fast disks, which is sufficient for several hundred concurrent users (see below).
PHP: Don´t use PHP over CGI or FastCGI. It works, but it is much slower than the Apache PHP module (more than 30% slower in comparison to FastCGI in our setup). I also use the APC opcode cache, which works fine.
MySQL: Convert the MySQL tables to the InnoDB engine. (Edit: We did this with the tables elggannotation, elggentities, elggentity_relationships, elggmetadata, elggmetastrings, elggusers_sessions. The rest is still MyISAM to make FULLTEXT search work and avoid problems with INSERT DELAYED.) This helps a lot, because the tables get updated very often and InnoDB does row based locking instead of MyIsam table based locking when writing to the DB. Also make sure to raise the Innodb buffer size, the more the better. In our setup MySQL may use about half of the available RAM (2 of 4 GB). I don´t recommend to run a medium sized elgg site in a setup with less than 1 GB RAM.
Memcache: For a large setup memcached is a must, too. I had to raise the maximum open files limit in its startup scripts to get it to work under very high loads / with many concurrent users. In our setup Memcache needs about 100-150 MB of RAM.
PHP coding: If you are still worried you can also improve your widgets by caching their output. I wrote some simple code that caches the content of widgets like "Who´s online" or "My Profile visitors" for a minute or so to memcached on high server load. The load times for threse widget dropped about 30-50%, wich sums up to a nice saving alltogether.
Caching, Javascript, CSS: JS and CSS load times don´t hurt so much (from the server side perspective) because they are usually cached. elgg has very efficient compression and cache/expire settings by default (if you use modular PHP!). This why is we stay with Apache even if there are more efficent HTTP server options.
Use the Firefox YSlow Extension to gather response times for your elgg pages. You will notice how much data is transferred on every request, how much of it is cached and how fast every single widget loads. This will help you to identify slow windgets/bad code. Unfortunately YSlow does not "see" the widgets on a page, so you will need to identify their URL from the HTML source and examine them one by one (you can also use the elgg debug output, but this will tell you the generation speed on the server, not the load time on the client).
After all of these optimizations my load times using elgg 1.5 on a dedicated machine (i7 4x 2,66 GHz CPU, 4 GM RAM, Debian Linux, Apache 2, PHP 5.2, MySQL 5.1) were:
Page /dev/pg/dashboard/ generated in 0.120798826218 seconds
Page /dev/_css/js.php/1239385595?js=initialise_elgg&viewtype=default generated in 0.047819852829 seconds
Page /dev/_css/css.css?lastcache=1239385595&viewtype=default generated in 0.0590708255768 seconds
Page /dev/mod/profile/icondirect.php?lastcache=1239308096&username=gumi&size=small generated in 0.0483059883118 seconds
Page /dev/pg/view/11859?shell=no&username=gumi&context=widget&callback=true generated in 0.0848619937897 seconds
Page /dev/pg/view/11860?shell=no&username=gumi&context=widget&callback=true generated in 0.0965390205383 seconds
Page /dev/pg/view/11630?shell=no&username=gumi&context=widget&callback=true generated in 0.0829989910126 seconds
Page /dev/pg/view/11850?shell=no&username=gumi&context=widget&callback=true generated in 0,0667469501495 seconds
Page /dev/pg/view/11629?shell=no&username=gumi&context=widget&callback=true generated in 0.118735074997 seconds
Page /dev/pg/view/11631?shell=no&username=gumi&context=widget&callback=true generated in 0.134125947952 seconds
Page /dev/pg/view/11618?shell=no&username=gumi&context=widget&callback=true generated in 0.0892231464386 seconds
I used the hu_skawa_genusers plugin to create 1000 users and did a simulation of several hundred users doing things in elgg at the same time (blog, messages, profile entries). That worked well until about 500, and with only a few errors until up to 800 "users". Note that the simulation does not load widgets and CSS/JS code, so the "real life" numbers are lower.
While Apache could handle the load the bottleneck turned out to be the MySQL server. That´s why I think that using a different webserver software will not help much and we would have to separate the HTTP/PHP from the MySQL server to handle more load.
We still don´t have a millions of entries in the MySQL tables yet. I expect that RAM is more important then, but I think that MySQL and RAM caching will still be quite efficient until we reach 5 or 10 GB of data. Then I will buy a bunch of SSD disks :-)
If you have any question just ask!
Read on:
- http://docs.elgg.org/wiki/Scalability
- http://www.marcus-povey.co.uk/2009/01/04/elgg-scalability/
- http://www.marcus-povey.co.uk/2009/09/21/running-elgg-on-a-mysql-cluster/
- http://groups.google.com/group/elgg-development/browse_thread/thread/f9f585332495e1d4/ad1918aa64b3ff9c?#ad1918aa64b3ff9c (outdated)
- http://209.85.135.132/search?q=cache:QjFcoauKPXsJ:anionu.com/2008/12/optimising-elgg-speed%2B/+optimizing+elgg+speed&cd=1&hl=de&ct=clnk&gl=de&client=firefox-a (only available in Google cache)
- Brett@brett.profitt
Brett - 0 likes
- jimbob@jimbob
jimbob - 0 likes
- jimbob@jimbob
jimbob - 0 likes
- gumi@gumi
gumi - 0 likes
- Dimentox@dimentox
Dimentox - 0 likes
Elgg version :
Release - 1.5, Version - 2009031301
Number of users :
89978 Active / 89978 Total
Sites:
1
Users:
89978
Widgets:
897879
Photos:
131
Wire posts:
64
Messages:
44
Albums:
26
Plugin configuration settings:
5
FAQ Object:
3
Discussion topics:
2
Blog posts:
1
Top-level pages:
1
DefaultWidgets settings:
1
Pages welcome blocks:
1
Groups:
42
eAccelerator 0.9.5.3 [shm:mmap_anon sem:spinlock]
Checked From
Time (US/Central)
Result
KBytes
Seconds
Kbps
showHelp('def_kbps');
Washington, DC (3 Mbps)
09:54:51
OK
16.69
0.50
267
Santiago, Chile (760 Kbps)
09:47:41
OK
16.69
2.14
62
Dortmund, Germany (5 Mbps)
09:46:10
OK
16.69
0.41
329
Los Angeles, CA (1.5 Mbps)
10:46:49
OK
16.69
0.41
329
Beijing, China (5 Mbps)
09:45:18
OK
16.69
0.64
208
Chicago, IL (45 Mbps)
09:46:52
OK
16.69
0.39
342
Gloucester, UK (5 Mbps)
09:46:58
OK
16.69
0.44
305
Sydney, Australia (5 Mbps)
09:47:28
OK
16.69
1.03
130
- Brett@brett.profitt
Brett - 0 likes
- N Mahmud@nasim
N Mahmud - 0 likes
- thouseef19@thouseef019
thouseef19 - 0 likes
Machine
Server
Elgg version
Estimated # of users handled daily
Estimated # of registered users
A
Apache (prefork)
1.7.14
2 251
6 753
A
Apache (prefork)
1.8.1
2 829
8 486
A
Apache (prefork)
1.8.8
3 660
10 981
A
Nginx + php-fpm
1.8.3 + core optimizations
24 480
73 440
B
Apache (prefork)
1.7.14
4 241
12 723
B
Apache (prefork)
1.8.1
5 363
16 089
B
Apache (prefork)
1.8.8
6 914
20 742
B
Apache (prefork)
1.8.9
9 722
29 166
- Average active user will spend approx. 15 minutes on the page and make click every 30s each day
- We assume also that in rush hours we may expect 3x bigger traffic than usual for ¼ of the day
- We assume that there’s 1/3 of active users (average user visits page every 3 days)
- We noticed that RAM usage didn’t change much, so unless You’re not using Swap memory, it doesn’t seem to affect performance much (you may want to use additional RAM for fine tuning some in-memory caches, but we’re not covering this case here)
You must log in to post replies.Awesome post! Thanks for publicizing your information!
MJ and Dhrup,
Would be very interested to see your stats. In particular the current server setup you have, number of accounts, max numbers online at any time, bandwidth usage, disk usage, CPU usage and server load!
I am not really started yet, but pays to be prepared!
Thanks Dhrup,
I will share, but right now nothing but a very small site taking no resources. However if things change then will be more than happy.
Btw - thats my little boy - 2 years old. Looks cute but appearances can be deceptive!
Our actual load is not very interesting. The machine handles several dozen of concurrent active real users and rarely has a load of more than 1.0 or 1.5 (Linux top), which is not much on a quad core server. If somebody would setup a stats page here I would be ready to share ours.
@MJ: I made the simulations because I wanted to give our customer a fair estimation of the number of concurrent users we would be able to handle. Until now we never had 500 or 800 users active at the same time so I cannot compare the simulated load to the real one.
You can let the simulation do a post/message etc. every two or five or ten seconds per user on average. So you will end up with very different numbers depending on your settings. The same thing applies to your real community. While most people on elgg.org will just read posts, those of a school or gaming community will be much more active.
I just would like to say that the load of an elgg server does depend on a lot of things. If somebody plans to run a huge elgg site he or she should have own experiences and do a test drive using the hu_skawa_genusers plugin. I would always recommend individual consulting depending on the target audience, installed plugins and the type of hosting and administration support available.
There is another recommendation:
Use the Firefox YSlow Extension to gather access times for your elgg pages. You will notice how much data is transferred on every request, how much of it is cached and how fast every single widget loads. This will help you to identify slow windgets or bad code. Unfortunately YSlow does not "see" the widgets on a page, so you will need to identify their URL from the source and examine them one by one (you can also use the elgg debug output, but it will tell the generation speed only).
These values are from a typical YSlow output from our live community dashboard, under low load conditions. Setup: Debian Linux, intel Q6600 4x2.4 GHz, 4 GB RAM, Apache 2.2, PHP 5.2.9, MySQL 5.1, Memcached:
HTTP Requests - 40 (without widgets)
Total Weight - 134.6K
1 HTML/Text 3.4K
4 JavaScript File 41.9K
1 Stylesheet File 59.3K
18 CSS Image 7.3K
16 Image 22.4K
RESPONSE TIME (ms)
Dashboard: 620 ms
JS Code: 100-200 ms each
user icons: 170 ms each
When cached these values drop to about half of the given response times.
widgets: 150 ms (who´s online, only 5 users at the time) up to 300 ms (the wire, 100 entries)
Alltogether the site loads within about a second, depending on the number and complexity of the widgets placed on it. Pages without widgets load even faster.
Statistics
Basic site statistics
Entities on site
PHP 5.2.11 [ZE 2.2.0]
Using apache2handler on Linux dimentoxcom04.theplanet.host 2.6.18-164.el5PAE #1 SMP Tue Aug 18 15:59:11 EDT 2009 i686
WEBSERVER
top - 09:37:08 up 21 days, 14:33, 1 user, load average: 2.68, 1.84, 1.79
Tasks: 141 total, 1 running, 140 sleeping, 0 stopped, 0 zombie
Cpu(s): 35.1%us, 0.6%sy, 0.0%ni, 64.1%id, 0.0%wa, 0.1%hi, 0.2%si, 0.0%st
Mem: 4151876k total, 4003140k used, 148736k free, 80784k buffers
Swap: 2040244k total, 13036k used, 2027208k free, 3723712k cached
[root@dimentoxcom04 ~]# ps auxww | grep httpd
root 5990 0.0 0.4 1083472 18012 ? Ss Oct21 0:03 /usr/sbin/httpd
apache 29214 10.3 0.5 1085736 23048 ? S 09:34 0:22 /usr/sbin/httpd
apache 29268 11.8 0.3 1084160 15788 ? S 09:36 0:15 /usr/sbin/httpd
apache 29269 11.7 0.3 1084160 15492 ? S 09:36 0:15 /usr/sbin/httpd
apache 29271 10.7 0.3 1084160 15092 ? S 09:36 0:13 /usr/sbin/httpd
apache 29274 11.0 0.3 1084160 15840 ? S 09:36 0:13 /usr/sbin/httpd
apache 29277 10.3 0.3 1084160 15452 ? S 09:36 0:12 /usr/sbin/httpd
apache 29300 11.2 0.3 1084160 15420 ? S 09:36 0:12 /usr/sbin/httpd
apache 29307 10.5 0.3 1084160 15752 ? S 09:36 0:10 /usr/sbin/httpd
apache 29326 9.6 0.3 1084160 15108 ? S 09:37 0:07 /usr/sbin/httpd
apache 29328 10.2 0.3 1084256 15600 ? S 09:37 0:06 /usr/sbin/httpd
apache 29333 9.1 0.5 1085476 21180 ? S 09:37 0:04 /usr/sbin/httpd
apache 29341 6.7 0.3 1084160 14904 ? S 09:37 0:02 /usr/sbin/httpd
apache 29353 7.2 0.3 1084160 14528 ? S 09:38 0:00 /usr/sbin/httpd
apache 29354 0.0 0.3 1084000 12904 ? S 09:38 0:00 /usr/sbin/httpd
apache 29355 2.0 0.3 1084024 14388 ? S 09:38 0:00 /usr/sbin/httpd
apache 29357 29.5 0.3 1084160 14860 ? R 09:38 0:01 /usr/sbin/httpd
apache 29358 3.5 0.3 1084024 14432 ? S 09:38 0:00 /usr/sbin/httpd
apache 29359 13.3 0.3 1084160 14680 ? S 09:38 0:00 /usr/sbin/httpd
apache 29360 1.1 0.3 1084024 14304 ? S 09:38 0:00 /usr/sbin/httpd
apache 29361 7.6 0.3 1084160 14572 ? S 09:38 0:00 /usr/sbin/httpd
apache 29362 0.4 0.3 1084164 14300 ? S 09:38 0:00 /usr/sbin/httpd
apache 29363 4.4 0.3 1084160 14488 ? S 09:38 0:00 /usr/sbin/httpd
apache 29364 4.2 0.3 1084024 14432 ? S 09:38 0:00 /usr/sbin/httpd
apache 29365 10.0 0.3 1084160 14620 ? S 09:38 0:00 /usr/sbin/httpd
apache 29366 5.2 0.3 1084160 14584 ? S 09:38 0:00 /usr/sbin/httpd
apache 29367 25.2 0.3 1084160 14660 ? S 09:38 0:01 /usr/sbin/httpd
apache 29368 6.0 0.3 1084160 14628 ? S 09:38 0:00 /usr/sbin/httpd
apache 29369 5.0 0.3 1084024 14456 ? S 09:38 0:00 /usr/sbin/httpd
apache 29370 14.0 0.3 1084024 14384 ? S 09:38 0:00 /usr/sbin/httpd
apache 29371 7.5 0.3 1084024 14440 ? S 09:38 0:00 /usr/sbin/httpd
apache 29372 15.0 0.3 1084024 14416 ? S 09:38 0:00 /usr/sbin/httpd
apache 29373 9.0 0.3 1084024 14456 ? R 09:38 0:00 /usr/sbin/httpd
apache 29374 1.0 0.3 1084024 14028 ? S 09:38 0:00 /usr/sbin/httpd
apache 29375 7.0 0.3 1084028 14388 ? S 09:38 0:00 /usr/sbin/httpd
root 29377 0.0 0.0 4196 600 pts/0 D+ 09:38 0:00 grep httpd
============= Drives =============
/dev/hda: Model=TEAC CD-ROM CD-224E-N, FwRev=3.AC, SerialNo=
/dev/sda: , Size=250.0 GB
========== Partitions ==========
Disk /dev/sda: 250.0 GB, 250000000000 bytes
255 heads, 63 sectors/track, 30394 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 267 2040255 82 Linux swap / Solaris
/dev/sda3 268 30394 241995127+ 83 Linux
============= CPUs =============
model name : Intel(R) Xeon(R) CPU X3210 @ 2.13GHz
model name : Intel(R) Xeon(R) CPU X3210 @ 2.13GHz
model name : Intel(R) Xeon(R) CPU X3210 @ 2.13GHz
model name : Intel(R) Xeon(R) CPU X3210 @ 2.13GHz
============= MEM =============
4064 MiB
============= PCI =============
-[0000:00]-+-00.0 Intel Corporation E7230/3000/3010 Memory Controller Hub
+-01.0-[0000:01-02]--+-00.0-[0000:02]----08.0 LSI Logic / Symbios Logic SAS1068 PCI-X Fusion-MPT SAS
| \-00.1 Intel Corporation 6700/6702PXH I/OxAPIC Interrupt Controller A
+-1c.0-[0000:03]--
+-1c.4-[0000:04]----00.0 Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express
+-1c.5-[0000:05]----00.0 Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express
+-1d.0 Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1
+-1d.1 Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2
+-1d.2 Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3
+-1d.7 Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller
+-1e.0-[0000:06]----05.0 ATI Technologies Inc ES1000
+-1f.0 Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge
+-1f.1 Intel Corporation 82801G (ICH7 Family) IDE Controller
\-1f.3 Intel Corporation 82801G (ICH7 Family) SMBus Controller
============= USB =============
Bus 002 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
Bus 001 Device 002: ID 04b4:6560 Cypress Semiconductor Corp. CY7C65640 USB-2.0 "TetraHub"
MYSQL SERVER
top - 09:02:16 up 21 days, 14:36, 1 user, load average: 0.17, 0.12, 0.09
Tasks: 110 total, 1 running, 109 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.4%us, 0.6%sy, 0.0%ni, 97.8%id, 0.1%wa, 0.0%hi, 0.1%si, 0.0%st
Mem: 4151876k total, 3748932k used, 402944k free, 141416k buffers
Swap: 2040244k total, 64k used, 2040180k free, 3279908k cache
============= Drives =============
/dev/hda: Model=TEAC CD-ROM CD-224E-N, FwRev=3.AC, SerialNo=
/dev/sda: , Size=250.0 GB
========== Partitions ==========
Disk /dev/sda: 250.0 GB, 250000000000 bytes
255 heads, 63 sectors/track, 30394 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 267 2040255 82 Linux swap / Solaris
/dev/sda3 268 30394 241995127+ 83 Linux
============= CPUs =============
model name : Intel(R) Xeon(R) CPU X3210 @ 2.13GHz
model name : Intel(R) Xeon(R) CPU X3210 @ 2.13GHz
model name : Intel(R) Xeon(R) CPU X3210 @ 2.13GHz
model name : Intel(R) Xeon(R) CPU X3210 @ 2.13GHz
============= MEM =============
4064 MiB
============= PCI =============
-[0000:00]-+-00.0 Intel Corporation E7230/3000/3010 Memory Controller Hub
+-01.0-[0000:01-02]--+-00.0-[0000:02]----08.0 LSI Logic / Symbios Logic SAS1068 PCI-X Fusion-MPT SAS
| \-00.1 Intel Corporation 6700/6702PXH I/OxAPIC Interrupt Controller A
+-1c.0-[0000:03]--
+-1c.4-[0000:04]----00.0 Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express
+-1c.5-[0000:05]----00.0 Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express
+-1d.0 Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1
+-1d.1 Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2
+-1d.2 Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3
+-1d.7 Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller
+-1e.0-[0000:06]----05.0 ATI Technologies Inc ES1000
+-1f.0 Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge
+-1f.1 Intel Corporation 82801G (ICH7 Family) IDE Controller
\-1f.3 Intel Corporation 82801G (ICH7 Family) SMBus Controller
============= USB =============
Bus 002 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
Bus 001 Device 002: ID 04b4:6560 Cypress Semiconductor Corp. CY7C65640 USB-2.0 "TetraHub"
root 3024 0.0 0.0 4540 1216 ? S Oct01 0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --user=mysql
mysql 3683 7.3 5.1 263332 212232 ? Sl Oct01 2271:50 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --port=3306 --socket=/var/lib/mysql/mysql.sock
root 28581 0.0 0.0 3960 672 pts/0 S+ 09:02 0:00 grep mysql
This community site is running on a linux box that also hosts about 5 other Elgg sites, including http://demo.elgg.com.
Box specs and stats:
CPU: 2 x Intel Xeon 5130 @ 2Ghz
Ram: 3 GB
HD: 500GB Seagate Barracuda, no RAID.
Load average right now: 0.85, 0.74, 0.82 (This is a bit lower than normal. We're generally around 25% of capacity. For the non-linux people, these are the load averages of the last minute, 5 minutes, and 15 minutes not adjusted for number of processors. In our case (4 processors) a 4.00 would be 100% capacity; 1.00 is 25%.)
IO Stat: (Normalized for number of processors.)
%user %nice %system %iowait %steal %idle
8.37 0.00 1.67 0.22 0.00 89.75
Software:
Web server: nginx w/ PHP in fastcgi mode. (Interesting to note, we found this significantly faster than apache when we were testing a few months ago. Couldn't find the numbers right now, though...)
Standard Debian stable MySQL.
Standard Debian stable PHP with APC.
Not using memcache.
Community stats:
Users: 21619
Plugins: 1138
Groups: 454
Messages: 113046
Average simultaneously logged in users: ~20 (Most of the activity here is from users not logged in.)
Load time: 1-5 seconds, depending upon page (and site, for that).
This isn't as thorough as gumi's info, but it's what I have easily available. The community site isn't a huge data-crunching site. Most people jump on, search for a plugin or reply to a message, then leave. The demo site actually has more logged in user activity, with about 500 new sign-ups a week.
Please just share stats if you want to. There's no reason to wait for X many people to share before you do...
Awesome post! Thank you very much, unfortunate me, I found it only today!
Determining required hardware for planned user throughput in Elgg
by Michał Zacher @http://vazco.eu/news/view/646918
Introduction
In this article we measure performance of a few types of Elgg installations and estimate amount of users that can be handled by particular hardware set.
We focus on possible server throughput. In case you’re interrested in amount of served requests per second, you will find some details in this article.
Results
Where:
A - Physical machne with AMD Athlon(tm) XP 2600+ processor (1 core, 2GHz), 32bit OS, 750MB RAM
B) VPS virtualized as 2 cores 1.7GHz each, 32bit OS, 1GB RAM
Both machines were running APC (PHP opcode cache). We made also single test on Nginx server installation on machine A for Elgg 1.8.3 with some basic performance enhancements that we introduced. This install is a good example of what you can archieve when you highly optimize your website, but without framework-level caching yet.
We made benchmarks for very simple installations of Elgg versions 1.7.14, 1.8.1 and 1.8.8 on server running basic Apache install with prefork module.
Stay tuned, we’ll prepare soon similar benchmark results for our high load solution with framework-level caching. We expect 30 times better results than for Elgg 1.8.8.
Assumptions
We made some basic assumptions that may vary for specific projects:
Note that changing these assumptions highly impacts the results.
Method
We took amount of clicks that active user generates every day. We computed server throughput and extrapolated daily clicks throughput. This way we could simply compute amount of active users daily. We had to take into account rush hours (in fact we take 1/2 of the users throughput) and multiply that by 3 (registered users count).
Conclusions
As it seems that processing is CPU-bound we could estimate that 8 core server should give nearly 4 times better results than Machine A. But unfortunately no one can take it as certain since every system is different and one badly written plugin can ruin whole system’s performance. However these results can serve as basic estimate of possible well written Elgg system’s performance.
We obviously see that optimizing Elgg’s core and migrating to different web server software may highly impact throughput. We can also notice that systems with over 100k registered users may be hard to run on the single server without building more efficient solution or scaling on multiple servers.
We have developed high load solution that better utilizes server resources and (depending on cache hit ratio) allows to increase throughput over 30 times. You may read more about it in this article: http://vazco.eu/news/view/548838