4 ms·
Yes. They are not doing a very heavy computational workload. Typical heavy-duty servers these days can do 100k's or millions of TPS. 40 TPS is a really, really,
by PeterCorless 6y ago
Yes. They are not doing a very heavy computational workload. Typical heavy-duty servers these days can do 100k's or millions of TPS. 40 TPS is a really, really, really light load.
Further, I was looking at those new server specs. There's an error I think? The server config on the Dell site shows 2x 8 GB DRIMMs, for 16 GB RAM per sever, whereas the article says 2 TB!
With only 16GB of RAM, but 153.6 TB of NVMe storage, the real issue here is memory limitation for a general-purpose SQL database or a typical high-availability NoSQL database.
Check my math: 153600 GB storage / 16 GB memory = 9600:1 ratio
Consider, by comparison that a high data volume AWS i3en.24xlarge has 60TB of NVMe storage but 768 GB of RAM. A 78:1 ratio.
If the article is correct, and the error is in the config on the Dell page (not the blog), and this server is actually 2 TB RAM, then that's another story. That'd make it a ratio of 153600 / 2000 = ~77:1.
Quite in line with the AWS I3en.
But then it would baffle me why you would only get 40 TPS out of such a beast.
Check my logic. Did I miss something?
- edoceo 6y agoThey don't only GET 40 TPS, that value is an estimate what they serve (above it was site/90 days). They have capacity for much, much more with that hardware
- z77dj3kl 6y agoYes, you can customize the config on Dell's site to upgrade the memory.
- cm2187 6y agoDon’t these certificates have long RSA keys which are more expensive computationally? Though I guess that doesn’t have to happen on the database server.
- tialaramex 6y agoThe only RSA computations Let's Encrypt need to do are: * Signature by their RSA Intermediate (currently R3, with R4 on hot standby) - which will be a dedicated piece of hardware - to issue a subscriber's certificate. In practice this happens twice, as a poisoned pre-certificate to obtain proof of logging from public log servers, and then the real certificate with the proofs baked inside it. * Signatures by their OCSP signer periodically on an OCSP response for each certificate saying it's still trustworthy for a fixed period. Again this will be inside an HSM. * Signature verification on a subscriber's CSR. To "complete the circuit" it's helpful that Let's Encrypt actually confirms you know the private key corresponding to the public key you wanted a certificate for, the signature on your CSR does this. Some people don't think this is necessary, but I believe Let's Encrypt do it anyway. You're correct that none of this happens on the database servers. I guess it's possible their servers use TLS to secure the MariaDB connections, in which case a small amount of either ECDSA or RSA computation happens each time such a connection is set up or torn down like at any outfit using TLS, but those database connections are cached in a sane system so that wouldn't be very often.
- kilburn 6y agoWhy are you assuming that their workload includes just one query per emitted certificate? The reality is that they are storing information during challenges, implementing rate limiting per-account, supporting OCSP validation and a few other things. You can investigate further if you really want to see the queries that they make against the database since their software (Boulder) is open source [1]. Most queries are in the files in the "sa" (storage authority) folder. [1] https://github.com/letsencrypt/boulder/ https://github.com/letsencrypt/boulder/
- killingtime74 6y agoKudos for sharing the location of relevant code. This is the kind of referencing we need
- deleted 6y ago[deleted]