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:

  • 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

    Elgg version : Release - 1.5, Version - 2009031301
    Number of users : 89978 Active / 89978 Total

    Entities on site

    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]
    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

     

    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

     

  • 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

    Michał Zacher

    by Michał Zacher  @http://vazco.eu/news/view/646918

     

    image

     

    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

    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


    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:

    • 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)

    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