Whether you are running a small website or needing to scale to millions of users, Barebones CMS is no slouch. Easily run it on one lonely server or thousands.
Barebones CMS is extremely light on system resources and operates close to the metal, which allows it to deliver up to several thousand requests per second. More requests/sec means more users served from a single piece of hardware. Deploying fewer servers to handle the same load ultimately translates to more money in your pocket.
Here are some measurements of system usage for content delivery via Barebones CMS:
The Barebones CMS SDK allows up to 512MB RAM for image cropping/resizing routines. However, an admin user would have to be uploading insanely large image files of at least 10,000 x 10,000 pixels to even get close to that limit. 32MB RAM is a more realistic average for processing image files (roughly 2,000 x 2,000 pixels). Even then, only admin users and automated processes that the server operator directly controls (e.g. /feeds scripts) will generally incur any significant RAM overhead for processing image files.
In short, Barebones CMS can run very well on hardware with as little as 256MB RAM. Any tiny, cheap VPS (e.g. OVH's SSD VPS 1) generally provides far more hardware for running Barebones CMS than most people will need to serve content to website visitors.
The only metric that ever really matters is the average number of requests per second handled.
The following is a chart that shows the average requests per second for a number of different scenarios that deliver the same content:
Here's a brief breakdown of the chart:
As can be seen, Barebones CMS gets slightly less than half of the number of requests per second compared to static HTML delivery. On the upside, it is much faster to make a change in just one file than to edit and upload a bunch of static HTML documents whenever a sitewide change needs to be made.
Other CMS products were included solely to provide a reference point for those who might be curious. Nothing is intended nor insinuated other than a strict comparison against the PHP baseline and the static HTML benchmarks. No special treatment or preference was given to any CMS that was tested. The same content was put into a single asset in each product's default installation. SQLite was used wherever possible (mostly out of laziness of not wanting to have to clean up database tables). Available time, hardware, and software constraints limited the upper limit of the concurrent connections to 200.
The hardware used for the benchmarks:
The software used for the benchmarks:
All TCP/IP connections over plain HTTP to localhost, which is known to skew benchmarks toward CPU bound operations.
Benchmarks are just a metric to show one possible scenario in one environment. They should always be taken with a grain of salt. Your own mileage will vary.