Hacker News Reader

Comment by ph2082 | Hacker News Reader

ph2082

> “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/

I wonder what would be cost of achieving similar performance on Hadoop stack.

View on HN

> 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=...

Ceph 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.

Just remember that besides beefy bare metal server, dedicated specialized network cards, they are also using DPDK, which is user space network stack.

Ok, say that is how achieving high throughput. Does it limited to FreeBSD only or can be used on other *nix as well?

DPDK 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.

Dumb 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.

Reply on news.ycombinator.com