Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The database servers powering Let's Encrypt

letsencrypt.org

Post reply on HN
Print view View original

231–236 of 236 posts

Re: The database servers powering Let's Encrypt

#231

Post by Dylan16807 »

walrus01 wrote: post #144
tyingq wrote: post #143

Earlier quoted context omitted.

The NVME drives are what's making it so expensive. Dell retail is $6044 for each of the Intel P4610 6.4TB drives. That's $145k.

after 15 seconds of googling, the P4610 U.2 format 6.4TB seems something more like a single unit street price of $2400 from non-Dell vendors. I'm mildly surprised it's that low considering that the U.2 format stuff, for serious servers, will always command a premium price. Probably in the range of $2100 to $2200 per unit from a x86-64 component distributor in moderate quantities.

It looks like performance-wise I can compare it to a couple of 970 EVOs stuck together, and those are $160/TB retail. So from that point of view you're paying more than double.

Re: The database servers powering Let's Encrypt

#232

Post by skyde »

jeffbee wrote: post #136
mike_d wrote: post #130

Earlier quoted context omitted.

It sounds like you just hit the threshold where defaults don't cut it anymore. With >100 concurrent clients you need to tune your DB for your workload. innodb_thread_concurrency and innodb_concurrency_tickets would be a good starting point, and optimal values depend on your r/w balance and number of rows touched per type of query.

I'm saying the innodb buffer pool mutex doesn't scale over 100 contenders and you are saying that I can tune mysql so there's never more than that, which it seems to me like we're in agreement.

would it scale better if we set innodb_sync_spin_loops=0 ?

Causing the lock to not spin and give up the pending CPU cycles back to OS if the lock is not available.

Re: The database servers powering Let's Encrypt

#234

Post by eppp »

SulfurHexaFluri wrote: post #161
eppp wrote: post #139

Earlier quoted context omitted.

Single threaded performance isn't keeping pace unfortunately.

That just means multithreaded will become more and more important. Languages like rust may gain some usage as we start to require safe multithreading.

That may be so, but that doesnt make it any less depressing. Some things cant be run parallel. I cant mail a letter until it is written.

Re: The database servers powering Let's Encrypt

#235

Post by [deleted] »

killingtime74 wrote: post #173
kilburn wrote: post #170

Earlier quoted context omitted.

Why 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 i…

Kudos for sharing the location of relevant code. This is the kind of referencing we need

[deleted]

Re: The database servers powering Let's Encrypt

#236

Post by the_biot »

So they've completely ignored the lesson Google taught us all 20+ years ago -- lots of cheap servers scales better than an ever more expensive big iron SPOF setup -- and which we're now all using to scale the internet. It's unbelievable to see a design like this in 2021.

What a stellar bit of incompetence.

Post reply on HN