Word.
I just wanted to post about something I've been working on - not the project itself, but rather my findings about the limits of Modx.
To be more exact, not finding the limits of Modx...
I'm working on a Modx site that has 10,000 business profile objects.
Each business profile has one or more child objects associated with it in various relationships, e.g, subscription, invoices, articles, products, tags, categories, foo, bar, etc.
Each of the businesses child articles and products have further objects associated with them as well, e.g tags x 5, topics x 5 (you get the idea...)
Basically its quite a large/complicated business model.
With 10,000 businesses, the database is around 400MB, and the 'Article-Tag' table for example has around 500,000 rows!
I'm happy to report that Modx works fine, and the site itself has been load tested pretty thoroughly.
Here is what I'm using in case it helps anyone else:
Ubuntu 2GB
Nginx webserver
APC cache
PHP-FPM
1) Custom Modx/Xpdo packages for my business logic.
2) Good relational database architecture.
3) Non EAV attributes on custom tables (fields are predefined by the business logic)
4) getPage + custom snippets for getting page data (paging is essential).
5) Not using packages like getResources, wayfinder, archivist (just a choice, no big reason).
6) When it makes sense, using Xpdo->query() with slim/basic queries.
7) Strategic caching of business model data.
8) Minimal use of TVs and Resources for variable data
Probably some things in here that could be better documented to help others get a foot in the door...
When the site goes live, it will be on a 4GB server, with a separate 2GB DB server - there will also be only 4000 businesses (twice the power - half the demand).
By testing beyond the predicted usage and resource limits of the website (on an inferior spec environment), I know that once it goes live it will be fine!
In a future proofing scenario, even if I had to go up to 50,000 businesses I still have plenty of options to look at:
1) Further code optimisations in my business logic.
2) Reducing frontend bandwidth usage (less images,markup,simplified pages).
3) Use of AJAX to lazy load non essentials
4) Scaling the server resources vertically (more RAM + tweaking).
5) Scaling the server resources horizontally - Multiple web nodes and possibly multiple DB servers with Memcached (modx 2.2+).
6) Other stuff I haven't thought of yet.
I feel satisfied that I have done my client a service by using Modx.
It meets their complex business requirements, is nice and fast, and if they keep up to date with the 'Modx upgrades' then the site will last them many years.
Similarly, if I needed a site without such a complicated business model, I would feel confident loading it with far more data/objects.
To anyone wondering if Modx can work for their project, I would say go for it…
At the very least, do some OTT testing to find out.
Byeeee!
☆ A M B ☆
MODX Staff
