Working with our partners MedicineChest Ltd and The Pharmacy Centre we host and manage about 1,500 UK based pharmacy websites and their associated patient prescription ordering on a single Microsoft Windows 2016 server. Each pharmacy has on average 500 patients with repeating prescriptions containing on average 3 items. Once every 28 days they will use our web application software by going on the website and ordering their prescriptions.

So that’s 750,000 visits per month simply for prescription ordering. Each pharmacy has an average of 4 employees that manage these prescriptions and use the system on a daily basis to manage the patient medication management. There are also the online ordering visits for retail side of each website. We also have appointment booking for pharmacy services like flu jabs, medicine reviews, travel advice, etc. The performance and efficiency of our software solution means we can run more processing on a smaller server.

We have a modest server configuration. Our single server is a XEON 3.5Ghz E3-1231 V3 4C/8T, 32GB RAM, 1TB SSD. It’s a modern server and it sits in a rack at a TeleData data centre in Manchester, UK. We chose this XEON and SSD combination to reduce power consumption and maximise our web application performance. The CPU typically tops out at 80W, although the motherboard can deliver 142W at peak performance.

Our SSD is considerably lower power consumption than an HDD with typical consumption below 9W. The motherboard power consumption averages 100W. Our single 32GB DDR4 memory module is around 3W. Peripheral cards like networking could add up to another 20W. The motherboard has built-in graphics and I/O.

CPU: 80W to 142W, SSD: 9W, Motherboard: 100W, Memory: 3W, Network Card: 20W.

In order to get a reasonably accurate power usage of our server we observed our CPU and networking performance for our web application in the list of tasks. During the typically busy morning periods our web application CPU usage averaged 15%, never exceeding a maximum of 30%. For the remaining normal usage, the CPU averaged 5%, not exceeding 15%. We also monitored the flowing network traffic for the web application, which is typically 2-4% network utilisation and never more than 10% for the server during the busy period. This is to be expected since we transmit minimum data across the wire.

Our web application is idle when not dealing with user messages that trigger events, yielding correctly to other Microsoft Windows processes which saves energy. Having reviewed the usage, we believe we are not exceeding 212Wh consumption for the entire server.

We host our server at an award-winning data centre in regards to energy efficiency. Teledata invested to create an environment which uses a 2MW smart energy storage system that powers the racks and cooling rather than a conventional, fluctuating mains supply with generator backup. The system can draw energy at the best times for the national grid and stop drawing during unusual events. Using battery storage carries a number of energy-saving advantages.

This reduces our carbon footprint in regards to the ancillary operations needed for the day to day running of our racked server. Primarily, heavy energy consuming equipment like cooling which can typically add another 50% energy consumption to actual server power consumption. However due to Teledata’s energy saving efforts we can reduce this to 35% ancillary costs.

Actual total server power consumption is 212Wh. 5.088kW/Day for the actual server. Ancillary costs @ 35% is 1.781kW/Day. Total server footprint 6.869kW/Day. Yearly total power consumption of 2,507kW, which is not dissimilar to the power consumption of a typical UK house over a year.

If the total energy consumption footprint of a single server is 2,507kW. According to 2022 GHG data, the CO₂ emitted into the environment per kW h of electric consumption is 0.193kg. If we transform our server electricity consumption into GHG CO₂ we get 484kg. If one tree on average absorbs 25kg of CO₂, then we would need to plant just over 19 trees to be carbon neutral in our server activities per year. At £1 per tree, it would take £19 to become carbon neutral for our single server.

For a conventional website where one dedicated server hosted just one website/web application the above would be true. Simply plant 19 trees to achieve carbon neutrality. However, we host 1,500 websites on our single dedicated server. Let’s do some more calculations. If our total energy consumption for our single server is 2,507kW, then for a single website using our web application technology the total energy per year consumed is slightly over 1.6kW, which generates 0.309kg, or 309g of CO₂ per year. To put this into perspective it would take about 81 websites before a single tree is needed to offset and become carbon neutral. The tree cost per website to achieve carbon neutrality is just over 1p for one website.

Our Pharmacy web application is more demanding than just a typical website. We could potentially host about 3,000 of this type of application on a single server. For a single server simply hosting websites, we could host many more, perhaps 5,000. For 3,000 websites this would push down our CO₂ emissions even further to 154g and the need to plant one tree per 162 websites in order to be carbon neutral. Around ½p towards a tree to be carbon neutral.

Looking at Eleven Comm website hosted by GoDaddy, they estimated 135kg of CO₂ annually. We can compare this using the information above to 309g CO₂ for a single Peach Rocks website, being conservative and proposing sharing with 1,500 websites per dedicated server. It would be very easy to go carbon negative with just over 1% of a single tree.

We are 99.998% more efficient reducing CO₂ emissions than GoDaddy per single website. Personally, I don’t believe the GoDaddy supplied emissions figure of CO² is correct when reverse engineered to kW, it doesn’t scale up when you add more websites.

We’ve been exclusively talking about server-side environment impact so far. What about the way the software is written that is delivered from the web server to the client browser. What additional, distributed costs could that impose? Remember this software in your client’s browser originated from the server. Should we discuss long polling to keep a web page up to date?

So, what exactly is long polling and why is it done? In a conventional website a web page is downloaded to the client and the connection to the server is then broken. Only a page refresh will get any subsequent changes to the data. Each web page request to the server costs 0.55mAh, or put another way you get 8,000 trips to the server per 1kW. Pressing the F5 key 8,000 times consumes a kW. Seems cheap? It takes more than one call to populate a page, each images requires one call. It could take 50 calls to populate a single page in one browser. In order to keep a page update with current information and to avoid visible web page roundtrips software could make an under the radar call several times per minute to ask if anything has changed on the server.

Consider a single user sat on FB (Facebook) for one hour. To receive regular updates FB long polls at say a rate of 4 calls per minute to find new postings and comments. Over the hour FB will make 240 calls under the radar. Given that it takes 8,000 calls to consume 1kW then 240 calls consume 0.03kW or 30W. Consider a busy website like FB, with say 1,000 users with the web page open in a browser tab. 4 calls per minute become 4,000 calls per minute, 240,000 per hour, 30kWh. That’s 5.8kg of CO₂. So, in a little over 4 hours, we’d need to plant a tree to be carbon neutral. It’s much worse than this since we only considered a 1,000 connected web browser instances. We believe that if a server downloads the software, it should be included in carbon emissions.

Is there a better alternative? Yes, we designed our web applications to use a persistent connection from the client web browser to the web application running on the server. The impact is pretty sensational. Let’s consider the example above contrasted with one of our web applications. There is no longer any need for long polling since if anything changes on the server, we can simply push an update from the server to the client browser down the persistent connection.

Let’s consider during an hour open in a browser tab there are 4 data changes on the server that require an update to the user’s browser hosted web page. Since each change requires only a single direction push the power consumption halves to 0.275mAh. 4 calls equal 1.1mAh. That’s only 0.25W. It’s also better than this since each user’s browser only receives the data update relevant to what they are looking at, since push is smartly targeted. Put another way, there’s no standing charge to obtain updates as in long polling. Only the data updates that are needed are actually smartly pushed.

Therefore, how you design your software matters on a global scale!

We minimise our energy in a number of other ways that are difficult to calculate. Some of the measures below have added to our excellent power consumption and associated performance outlined in our calculated emissions. Some, however are around saving energy ‘off the server’ using our development techniques, processes, network traffic reduction and installation to name but a few.