Thread pools on the JVM should usually be divided into the following three categories:
- CPU-bound
- Blocking IO
- Non-blocking IO polling
Each of these categories has a different optimal configuration and usage pattern.
Latency Comparison Numbers (~2012) | |
---------------------------------- | |
L1 cache reference 0.5 ns | |
Branch mispredict 5 ns | |
L2 cache reference 7 ns 14x L1 cache | |
Mutex lock/unlock 25 ns | |
Main memory reference 100 ns 20x L2 cache, 200x L1 cache | |
Compress 1K bytes with Zippy 3,000 ns 3 us | |
Send 1K bytes over 1 Gbps network 10,000 ns 10 us | |
Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD |
We'll use NixOps to deploy, so we need to install it
nix-env -i nixops
And to deploy on DigitalOcean we need to have an account and create an API access token for it.
#!/bin/bash | |
# `gitea dump` doesn't currently back up LFS data as well, only git repos | |
# It primarily backs up the SQL DB, and also the config / logs | |
# We'll backup like this: | |
# * "gitea dump" to backup the DB and config etc | |
# * tar / bzip all the repos since they will be skipped | |
# * Not rotated because git data is immutable (normally) so has all data | |
# * rsync LFS data directly from /volume/docker/gitea/git/lfs | |
# * No need for rotation since all files are immutable |
Whenever the topic of Bitcoin's energy usage comes up, there's always a flood of hastily-constructed comments by people claiming that their favourite cryptocurrency isn't like Bitcoin, that their favourite cryptocurrency is energy-efficient and scalable and whatnot.
They're wrong, and are quite possibly trying to scam you. Let's look at why.
There are plenty of intricate and complex articles trying to convince you that cryptocurrencies are the future. They usually heavily use jargon and vague terms, make vague promises, and generally give you a sense that there must be something there, but you always come away from them more confused than you were before.