TinyCDN: a portable blazing fast CDN
It all started as a proof of concept for the holdon utility described last December in Perfplanet’s Calendar, it ended up being the fastest nodejs static content file delivery I could test on many Internet of Thing platforms, and even on generic live servers. Everything you see in this website, as example, uses this middle-ware too: that’s how much I trust its efficiency, and Heroku stats just confirmed it!
You see that little image there? That’s the day I’ve switched this site from express.static middleware, to tinyCDN one.
On tinyCDN peculiarities
This npm utility is arbitrarily capable of pre-generating, or creating on demand, the gzip, deflate, or plain/binary version of any file listed in its Array of well known extensions.
By default, these are files such .js, .css, .txt, .html, .svg, .md, .htm, .xml, .json, .yml and you can specify any other, or reduce the predefined list, as you need.
Having their own counter-part pre compressed means your server simply has to serve them as they are, instead of needing a runtime compressor accordingly with the capability of this or that browser.
Moreover, it is possible to use an Etag, so that even the hashing of the static file will be pre calculated and your CPU or RAM will be free, per each other connection asking for the same file, of calculating such hash.
In few words, if you ask a fresh new static file for the first time, such file will be compressed, and its SHA256 (or any other hash) will be calculated, in order to be used later on as Etag, only once!
If are wondering “how can this be faster than alternatives?“, the answer is that while this compression and hash computation happens, every other client asking for the same file will be put on hold through the holdon utility.
Fully Streams Based
Waiting or not, whenever a file is ready to be streamed, it will be simultaneously served to every client that was waiting for it, even if it was already compressed and its Etag was already ready.
Why? Well, that’s simply because Hard Disks are still the biggest bottleneck of any server, imagine to multiply that potentially by 100 when it comes to IoT or Computer boards such the Raspberry PI, entirely based on SD cards!
The time it takes to actually find, and access, a file as a readStream, is precious time you don’t want to repeat per each client that might ask in the meanwhile for the same file: you put all of them on hold, and once the file start streaming, you stream all of them at once!
Cluster magic by default
Not only you can queue clients asking for the same file in a single thread, you can queue multiple thread of different clients asking for the same file through the tinyCDN Converger module, an utility which aim is to redirect multiple clusters to a single thread capable of executing any operation and inform each cluster once the operation has been completed.
And best of all, this is configurable too, so we could just disable it if we think it would be not needed or overkill.
As both module and CLI
That’s right, tinyCDN can be used as module to create a generic nodejs http/https, or even Express, response middleware, or it can be used as CLI in order to simplify the delivery of any generic folder as static content.
Even SSL over HTTPS
Strawberry on top, you can start a nodejs https server simply providing a valid .crt and .key file.
If you don’t know how to, I’ve got you covered!
As Summary
There are many solutions capable of serving static content from a folder, and I am the author of one of the very first one too, however none of them was usable just as middle ware, and with all improvements aimed to make even an Arduino Yun capable of satisfying any home base requirement.
It is not by accident, that you would rarely find something faster on node js, but if you don’t believe me you can always try by your own to benchmark tinyCDN against Express: you’ll find details within each file
Hope you’ll enjoy this little script, and you’ll use holdon concept to boost any other program you might think of.
