How on Earth can a website be eco?
Dec 2016
Eco - Live Webapps Vs Websites
John Ince
Eco - Live Webapps Vs Websites
We're always barking on about how green our live webapps are. Folks have said to us "How on Earth can a website be eco?". Let's try to answer that question in this article.
A little background reading to help in your understanding. Feel free to skip if we've told you all this before, yawn. Head over to the University of Southern California, the link's at the bottom of this article, for a more complete background however it can be summed up in just the one paragraph below.

This usc.edu paper is a reasonable resource. It's aimed at prolonging the battery life of smartphones and tablets. It aims to identify the biggest consumers of power from a client point of view, by client I mean the browser side of things, in this case the phone. It's just as relevant to a desktop browser. but since it's plugged in we simply don't seem to care (unless we're running on battery!). By far the biggest consumer is a HTTP GET/POST, a client request for data from a server on the Internet. Cut down the requests, cut down on the power consumed, on both the server and client side of the equation. Sending/Receiving 1 byte or 1000 bytes makes negligible difference to the energy consumption which is about 0.55 mAh per call. That's the paper in one paragraph. Read on.
A Traditional Website - How it Works
Firstly, and most importantly lets dive into a regular website. So, what's this mythical HTTP GET thingy? In it's simplest form when you type in an URL in your browser to access a website it generally does a HTTP GET. This asks the server for the HTML resource/file stored at that path. Easy eh! We know all this. What's lesser known is that it's a make and break connection by design. Open the underlying network connection, let's call it a socket, request the file needed upward to the server, the server sends the file content to the browser and then the browser/client breaks the connection. Job done! Each new HTTP request opens a new connection. This is an over simplification and there are browser optimisations around keep alive connections however it's the core of how it works. However a HTML document that's been requested almost always has other resources, like images or other URL based resources (run code at the server). For each single resource there's a server HTTP call. It gets better. Remember here that there is no permanent connection to the server, it broke with the last HTTP request. What if something changes on the server that affects your page? You'll never know until you hit the refresh button. F5, F5, F5... is that the way you want to live your life? So, what to do? Enter the magical AJAX (Asynchronous JavaScript and XML), don't stop reading it's not that technical, it's simply used to make an under the radar HTTP call without having to do a full refresh of the page. It's ideal for programmers to put into a loop and call over and over again. HTTP GET +.55mAh, HTTP GET +.55mAh, ad infinitum... So we're checking for page changes by calling the server constantly and burning power on mobile/laptop and also on the server because it has to respond. What if nothing has changed? You just wasted energy.
Example - Traditional Website
Let's consider an example. Facebook. Your friends comments appear live right? No it's just AJAX faking live.

Here's the facts: One HTTP request 0.55 mAh. ( therefore ) 2000 HTTP calls per Ah ( therefore ) 0.24 Kwh = 1Ah ( therefore ) 8000 HTTP calls per Kwh.

If Facebook makes 4 HTTP calls for minute in the background using AJAX

1 Facebook user / 1 hour sat on Facebook = 240 HTTP requests to receive 1 comment

Oh, we think that there's more than 1 Facebook user. This is exactly the reason that they need to keep building more data centres to respond to billions of HTTP GET requests that return nothing
A Live Webapp - How it Works
For the purposes of this discussion we'll concentrate mostly on the HTTP side of things without delving too deep into our architecture and contrast with a traditional website. In our world the traditional web server is a minor part of our workings. We simply use it to pass the static parts of our pages and to translate literals/text on-the-fly into other languages. We also use it for exactly what it's supposed to be used for, retrieving images and content, that's it. Our webapps are a completely separate program running on the server. So how do we talk to this other program/webapp if it's not via the traditional web server? There's a new (but quite old in IT terms) technology called HTML5 websockets, it's simply a specification or words, defining what it is and how to implement it in code. In brief the idea is to keep a persistent two-way connection open between the client and the server, remember traditional web server calls are make and break. We're now in a whole new world where the client can ask the server for some data (same as always) but more importantly the server can PUSH live data to the client. We've just nuked the AJAX problem. No more checking the front door every 25 seconds to see if anyone is there. If something changes on the server that a particular client is viewing we PUSH the change, remember that's a one way from server to client. We have of course built on top of the simple HTML5 simple specification with more power saving tricks using an observer model we know which clients are viewing which data and selectively PUSH data only when necessary.
Example - Live Webapp
Let's consider an example. Project Peach newsfeed/private version Facebook. Your friends comments appear live right? Yes, pushed in realtime.

Here's the facts: One HTTP request 0.55 mAh. ( therefore ) 2000 HTTP calls per Ah ( therefore ) 0.24 Kwh = 1Ah ( therefore ) 8000 HTTP calls per Kwh.

1 Project Peach user / 1 hour sat on newsfeed = 0 HTTP requests, 1 server PUSH ( 1/2 HTTP request )

We'll let you do the maths...
How Do We Prove this Physically?
So far all this is theory. It would be nice to know that data is only moving on change. It would be good somehow to see it in action on the wire. There's a low level network monitor tool called Wireshark, it's built on an underlying library for programmers just like 'us' and we've used it before called 'libpcap', we can sniff/view filtered network traffic as in how much data is moving up/down the wire and also the HTTP GET calls. Now for some gore. We don't live in a perfect world and sometimes our lovely, power efficient, planet saving websocket connections get blocked by proxy servers, firewalls and so on. This is particularly true in the corporate world. We're keen for these power buyers to see our technology, so to aid this we provide an AJAX fallback mode. Yer, told you it was gory, shock and horror attracting corporate clients at the expense of the planet. The interesting part of this is that we can run both modes, Websockets Vs AJAX at the same time. In Wireshark we can watch the carnage that is old school AJAX at work in all it's horror with simply the two differing connection methods to our single webapp. If we thought that this is a massive thing we could build a demo page into our own Project Peach webapp that extends our eco section. We would simply use the wireshark 'libpcap' to capture data on an active websockets and an active AJAX connection. We could do some nice bar charts based on REAL data flow including some energy cost savings. Remember this is purely for the HTTP GET/POST calls. It's much bigger than that...
Other Random Bullet Points on Energy Saving
We've focused mostly on the client energy saving. Remember each client request has server energy costs. What if the request is AJAX (repeating) and the server calls a database query? The point is that server requests vary in power consumption.

Our webapps are of a single page design. This provides both smooth inter-page movement and energy savings. All the pages are download in just one HTTP request at initialisation and there are zero server roundtrips on moving pages.

What is the energy consumption with duplicate development? A website and multiple mobile apps? Different development teams with writing duplicate code for the same end result. Monitors, compilers, testing... All costs energy. Just one solution with live webapps.

Installation, updates and distribution. Same for both desktop applications and mobile apps. Consider the Microsoft Windows monthly updates in terms of data transmission, each and every desktop on longer as it's at shutdown. What about the play store and iTunes store? The updating, download and installation cycle. With live webapps there's a single app instance in the cloud. Distribution is just like a website. Transparent to the user and zero energy

We have one technology for both websites and apps. Internal corporate applications, front facing websites or end user applications. There's a single framework for all needs. Our bigger building blocks of code speed up development which is more human efficient and energy efficient.

Great human testing. Our framework core is on test 365/24/7 in the public domain via http://cashclamber.com Self testing code via bitcoin incentive.

What's the biggest waste of energy and resource from a programmers perspective? Hunting down badly worded bug reports? Our live webapps report errors from both the server and clients components centrally. We get the exact line of failure. As users use, we fix. We've fixed the excessive energy in fixing bugs by making it much easier.

We can upcycle your existing code. Think about that investment in both energy, time and money in building your systems. Now you want a modern interface but your old code doesn't fit anymore. You going to re-write it all? Why not upcycle and re-use. Our framework will save you big time on wasted energy.

We've just one centralised cloud hosted webapp instance that ALL browsers connect to. There's no concept of an instance running per machine. Only our UX runs in browser, the browser is the client app instance.

We've created a reduction in network traffic by our smart connections. We send only targeted data to the correct, interested connection. We only send data to interested parties. If no one is looking then nothing is sent.

Remember we run ALL our current live webapps on a single tiny VPS, that's not even a server, it's a slice of a server! Need a quart in a pint pot? That's how efficient our live webapps are!
Coming soon. Click a link & jump to the document.
Doing it differently since 2012. We're simply 10 years ahead. Our software is designed, coded, maintained, supported & hosted in the United Kingdom.
Why Project Peach?
The Hawthorn Gallery
DBD International
Knot 2b Missed
Monero Mine
About Us
Contact Us
Pay Us
Copyright 2020 Project Peach