4 ms·
> “For its next-generation backend, the Ceph community is exploring techniques that reduce the CPU consumption, such as minimizing data serialization-deserializ
by ph2082 7y ago
> “For its next-generation backend, the Ceph community is exploring techniques that reduce the CPU consumption, such as minimizing data serialization-deserialization, and using the SeaStar framework with a shared-nothing model…“
Seastart HTTPD throughput as mentioned on their site Between 5 to 10 CPU, it can achieve 2,000,000 HTTP request/sec. Just Vow. But If you look at Http Performance data on below URL, running similar configuration on clouds (AWS etc.) looks costly though.
http://seastar.io/http-performance/ http://seastar.io/http-performance/
I wonder what would be cost of achieving similar performance on Hadoop stack.
- lossolo 7y agoJust remember that besides beefy bare metal server, dedicated specialized network cards, they are also using DPDK, which is user space network stack.
- ph2082 7y agoOk, say that is how achieving high throughput. Does it limited to FreeBSD only or can be used on other *nix as well?
- benlwalker 7y agoDPDK runs on Linux and FreeBSD officially. All of the momentum is on Linux though* *I was recently part of an effort to add FreeBSD testing to DPDK because SPDK's FreeBSD test agent kept failing when we updated DPDK. I'm a core maintainer for SPDK, which is basically DPDK for storage.
- ddorian43 7y agoDumb http-response benchmarks can be achieved everywhere. Seastar excels on complex (cpu,disk,ram,network) scenarios (big disk-based db) with oltp/olap and keeping SLA low.
- aasasd 7y ago> it can achieve 2,000,000 HTTP request/sec Is that including some db operations? Because otherwise eeeeh: https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=plaintext https://www.techempower.com/benchmarks/#section=data-r18&hw=...
- pas 7y agoCeph has a lot of small ops, where lock and cache contention becomes very significant. (Basically a small piece of data/request comes in from the network and the OSD [object storage daemon] network thread has to pass it to the I/O worker thread and then forget it. The I/O thread similarly just needs to get the request issue a read/write, and let the kernel work.) Since the whole Ceph I/O model is async the less waiting, scheduling, contention, etc. happens the better. Currently Ceph is CPU bound, that's why they are trying to improve CPU perf.