Impact / Energy

Fleet Energy

The energy of many sites at once: a fleet against shared hosting, institutional workloads priced from published case studies, and the saving as the site count grows. The per-site model is on Energy. Numbered citations on this page, such as [9], refer to the references on Impact.

Fleet Energy

derived, from the measured inputs above. The production baseline sets one site against a dedicated deployment. This section sets a thousand sites against consolidated shared hosting behind a CDN, which has already captured most of the multi-tenancy saving. The savings are therefore smaller, and the two sets of percentages do not combine. Each arm is on its own render fraction, and drupflare is on the traffic mix with logged-in views included. Every drupflare site here is asleep. The Fleet At Different Residency charges the warm bounds. Generated by bun scripts/economics/fleet.ts:

The total energy saving is one minus drupflare's annual energy over the shared host's, for the same fleet. With S the saving, E_drupflare the fleet's energy in kWh a year and E_shared the shared-hosting energy under the published arm:

S = 1 - \frac{E_{\text{drupflare}}}{E_{\text{shared}}}

The saving narrows as the shared host's processors fill. At 20 million views a site the host runs at 29% utilisation and drupflare still uses 91% less energy.

The fleet model charges shared hosting under three arms and quotes the one with the smallest saving. same-cost charges it drupflare's per-request CPU, so only idle, PUE and the render fraction differ. native-nginx and native-fpm charge it the measured native costs from the per-view run, logged-in views included: a native render at 92.9 mJ, an nginx hit at 1.9 mJ, or a PHP-FPM page-cache hit at 10.7 mJ where there is no nginx. Native renders are cheaper than wasm ones, so those arms lower the saving where renders dominate. Through 150 million views per site per month the quoted arm is native-nginx; at higher traffic it is same-cost. The first four rows read 99.971%, 99.886%, 99.190% and 92.841% on same-cost and 99.971%, 99.885%, 99.131% and 91.210% on native-nginx, at 10,000, 100,000, 1,000,000 and 20,000,000 views.

Rows past 20 million run the same model at hostile traffic levels. Solved on a 1% ladder, the saving first falls below 90% at 23.9 million views per site per month, below 75% at 88.7 million and below 50% at 364.4 million.

The saving never reaches zero in this model, and the floor comes from an assumption. Once both arms are CPU-bound, per-request energy is at parity, so the remaining gap is the facility overhead the model assumes: 1.15 PUE for a hyperscale operator against 1.54 for colocation. That holds the saving near 1 - 1.15 / 1.54, or 25.3%, and the model reaches 25.34% at a trillion views. An opponent hosted at hyperscale PUE would lose that floor, leaving only the render-fraction difference.

Fleet Sensitivities

Three assumptions of the fleet model move without a new measurement. derived (modelled), from bun scripts/economics/fleet.ts:

• PUE: charging Cloudflare the colocation PUE the opponent carries takes the 20 million row from 91.21% to 88.23%, so a saving above 90% at that traffic holds only at the modelled PUE. The 1.54 is an industry average [6] and says nothing about Cloudflare's facilities.
• Omitted energy: Cloudflare's networking, storage and idle hardware are not attributed to a site. Spread over the fleet's views, the 20 million row falls to 90% if that energy is 0.74 mJ a view and to no saving at 55.8 mJ a view. At a million views the same two thresholds are 57.6 and 624.9 mJ.
• Host memory: the shared host is packed at 1 GB a site onto 1,536 GB, while its power comes from the SPECpower result, a 384 GiB host. On 384 GiB, 1,000 sites need 2.6 hosts and not one, and the saving is 99.64% at a million views and 94.88% at 20 million. The tables keep the 1,536 GB host because it is the arm less favourable to drupflare. --ram-gb-host=384 runs the other.

The Fleet At Different Residency

The table above is the sleeping arm: every drupflare site holds nothing between requests. That is where a fleet of mostly idle sites sits on the free plan or with SITE_WARM=0. The next table keeps the same thousand sites and the same shared-hosting arm, and applies the warm charges from Operating States to every drupflare site. derived (modelled), from bun scripts/economics/states.ts:

The warming CPU moves the fleet by a few points, so memory accounts for nearly all of the difference between the columns. In the memory columns each drupflare site is charged its memory share, while shared hosting is charged the whole host its sites fill at 1 GB each. Every site holds its memory all year, which is where a paid fleet that keeps every site warm sits. A site that holds it for part of the year is charged for that part. The memory a warm object holds is a plateau, so the charge depends on how much it holds and for how much of the year. The saving by each, at 10,000 views a site and at a million:

A booted interpreter's linear memory starts at 64 MiB, and a site's workload only raises it. The range for a Drupal site is therefore roughly 100 MiB for the interpreter alone to 200 MiB for a large distribution. The platform meters more than the linear memory. The share of the year is what differs between sites. A site that is awake only while it renders holds the interpreter's memory for a small share of the year, and a cached anonymous page is served without booting it. If object memory sits in DRAM that is powered whether or not it is used, the charge is zero for every cell and the saving is the sleeping column. The carbon and water figures on Environment follow the sleeping arm.

Real Institutional Workloads

published traffic from named case studies, run through the fleet model at each estate's own average per-site traffic. The model is the 1,000-site consolidated opponent, the least favourable arrangement for drupflare.

The traffic column quotes each source. Mass.gov is one site that "hosts over 400+ government agencies" [10]. NASA's peak was "over 40,000,000 page views in a single day" during the 2017 eclipse [11]. The news agency serves "1 to 2 billion monthly pageviews across dozens of Drupal sites", a main English site and 46 language sites, and is not named in the source [12].

Each figure is a vendor case study from its own year, not a measurement taken for this page, and each is an estate average. Traffic inside an estate is skewed, so its busiest site sits well above the mean and its long tail well below it.

Every estate lands where the saving stays above 84%. NASA's ordinary traffic saves 87.97%, and no published figure reaches the 88.7 million views where the saving falls below 75%. A university estate is two to three orders of magnitude below it.

What the same shapes cost on your own account, from comparison.ts at each estate's site count and per-site traffic:

Every estate costs less on drupflare than on every conventional host priced. Where The Curves Meet gives the general crossing. Kept warm, as a paid plan does by default, Arizona State's 426 sites cost $139.80 a month, 32.0 times under the cheapest VPS and 127 times under the managed floor. The other three estates have few sites, so the warming chain adds under $3 a month to each.

Energy Avoided By Site Count

Energy avoided per year against the worst case, one small VPS, derived: its idle and work energy minus drupflare's energy on the traffic mix.

What that is comparable to, at 10,000,000 views per site per month:

Energy avoided per year against production, derived: the production baseline's idle energy (three regions with a high-availability web pair and database pair in each, 4-vCPU nodes at 15%) minus drupflare's energy on the traffic mix. The analogies for these savings are in the Energy Savings table.

All figures are rounded down. A server is a 320th of a 640-thread host per site, two vCPUs, with the power from SPECpower [1]. A US home is the EIA's 2022 average of 10,791 kWh a year [2], and a passenger vehicle emits about 4.6 t of CO2 a year [3].

Energy moves far less than cost does across these tables. The conventional arm is charged both its idle allocation and the marginal joules of its work. Across a ten-thousandfold range of traffic the total moves by under a factor of two, 9.3 to 16.5 kWh a site, because the idle term dominates everywhere below the top of the range. Energy reaches the same result from the other direction.

How These Figures Are Computed

bun scripts/economics/fleet.ts produces the fleet energy table, the arm comparison, the sensitivities, the solved thresholds and the institutional saving column. bun scripts/economics/fleet.ts --ram-gb-host=384 runs the 384 GiB host arm. bun scripts/economics/states.ts produces the residency table and the memory-held tables. bun scripts/economics/comparison.ts produces the institutional cost table and the energy-avoided tables, at each estate's site count and traffic or across the site counts shown. The estate traffic figures are the published numbers in the table, cited in the references on Impact.