Question about machine requirements for deploying certstream server

[Baoxd123]

(Since the official certstream-go server was down, I also have to deploy the certstream server locally. Thank you for your contribution!)
I have a small question: Since the data throughput of certstream is so huge, what kind of resource requirement do I need on my local machine in order to deploy certstream server locally?

[d-Rickyy-b]

Hi there, thanks for your interest in the project.

I tried to outline some information regarding the requirements in the readme. But I understand that that's not really precise, so let me try to be a bit more elaborate here.

I am currently running an instance on an extremely oversized VPS in Oracle's Free Tier. There I am using the ARM architecture (4 cores) with unnecessarily much RAM (24 GB).

CPU requirements

Usually, even small VPS instances should be enough to run the certstream-server-go binary just fine. I'd suggest having a VPS with at least 2 vCores. If you plan on having other applications run on the same server, it's good to over-provision and go with maybe 4 vCores. Also if you plan on having a lot of clients connecting to your server, you want to buy even more cores. There have been reports regarding issues with too small servers: #53 but currently I can't tell if that's really an issue of a too small server or a bug in the code.

Memory requirements

Since the tool uses about 50-60 MB of RAM at idle, RAM really isn't something you should worry about. Obviously with a rising number of clients, the amount of RAM needed will increase linearly, especially when clients aren't able to keep up with the amount of data

Network requirements

Each lite-certificate is ~1500 Bytes in size - full certificates are ~9000-10000 Bytes in size. All CT logs (from the Google list) combined generate approximately 250-300 certificates (precerts & "real" certs) per second, which are subsequently sent to each client. The number of certificates might vary. Even 600+ certs per second are possible and are considered usual.

That means the server needs a downstream of roughly ~25-30 MBit/s to download all certs from the CT logs provided in the Google list in real-time.

9000 Bytes * 300 certs/s = 2.700.000 Bytes/s 
2.700.000 Bytes/s * 8 Bits/Byte = 21,6 MBit/s
21,6 MBit/s + Protocol overhead + Bursts = ~25-30 MBit/s.

For the upstream (traffic to the certstream clients) it depends on the type of stream each client connects to. There are three types of streams: Full, Lite (default) and Domains-only. As explained above, the average size of an entry in each of these three streams varies (lite: ~1500 Bytes, full: ~9000 Bytes, domains-only: ~100-150 Bytes). That makes roughly 3-10 Mbit/s per client for lite certs, 25-30 MBit/s per client for full certs and 0,3-1 MBit/s per client for domains only.

Currently, certs aren't sent compressed by default. But there is an issue for this already: #30 - compression has already been implemented, but It's lacking broad testing, so I can't tell if that'll actually reduce the traffic noticeably.

Below you'll find some throughput statistics from stresstesting my server by creating 30 websocket connections using my tool webstress. Mind the 554 Msg/s/socket that are sent to each client.