We are a relatively new property, with a ton of CPU and memory intensive functionality. Our functional spec is based around the serving of content, e-commerce transactions and membership management. Additionally, we have high resource software based around analysis tools and SaaS.
Below is a brief outline of the set-up we have decided upon in the short to medium term. I believe the specification would be apt for most similar properties managing membership.
Hosting specification
Below is a brief outline of our cloud-based set-up:
Database Server: We are using a dedicated container for MySQL, running 8GB of memory and 4 dedicated CPU’s, with what I guesstimate as having a nice (nee relevant) balance between memory and CPU usage. We with undoubtedly alter this as and when we better understand the resource usage and scaling required by the property. Additionally, MySQL we also have phpMyAdmin and Htop.
Web Server: We are running a lower powered droplet, utilising Ubuntu 18.04 as the Linux OS. Additionally, this we have Apache2 and PHP running, along Htop on the server to catch errant threads and the GD module for next generation image processing. For speed, we serve the WEBP image in place of PNG and JPG images (for compatible browsers). Other variations from the norm include Memcached and Zend Opcache, again to help speed things up.
Search Server: In terms of enterprise search, we are currently testing Apache Lucene/Solr on a dedicated droplet, running just Linux, OpenJDK, Tomcat and Solr. Moving-forward our faceted search functionality (and related items) will be powered by either Apache Solr, or Elastic Search. As I type this, I am leaning more towards Solr, purely for its documentation, which is easy to use.
Tools: This has the similar specification as our database server, but is running Ubuntu 18.04 and a standardised LAMP stack. We have PHP 7.3 installed for its improved performance over the typical 7.2.
Caching Server: We are looked at using Varnish as a reverse proxy sitting in-front of the web server in order to drastically speed up the performance of our static pages.
Caching
For membership and transaction-based properties such as this one, it is vital that caching is configured correctly. We have ours set up so that the logged in users are not served optimised pages. Additionally, our transaction pages have limited caching.
We have the following cache set-up:
- Page Cache
- Database Cache
- Object Cache
- Browser Cache
- Fragment Cache
- Http reverse proxy
CDN
At present we are investigating the migration of some of our files over to a content delivery network. The CDN’s we are looking at include Cloudfront, Fastly and Stackpath, with the preference (currently) Stackpath.
Well, there you have it. This is our current set-up. It will change and adapt and as it does I will edit this document to better reflect the actual.