Why not supply async api in mongo C driver?

async api would be more effective, and less threads. why not supply in mongo c driver?

there are async api in mongo java driver

Hi @kuku_super, thanks for reaching out!

An async API on the C driver has been considered before. It is not outside the realm of possibility. Notably, the investigation in CDRIVER-27 concluded the current multi-threaded API could maintain throughput well as the number of application threads increased.

Do you have a use case in mind for an async API? Has the number of threads spawned by libmongoc been problematic?

Sincerely,
Kevin

1 Like

Hi @Kevin_Albertson , thx for ur reply.

if changed the request waits 0 - 2 ms, then we compared the thread pool solution and the async solution with 1 cpu. the async solution would give more qps, more than 20% better.

more quickly the request, there would be more context switch.

hi, @Kevin_Albertson, give a use case in game server.

we service 10k player in a server process with only one cpu. every player would save data to mongodb once 1 second. so , there would be 10k qps ops. suppose 10ms per op, if we use thread pool solution, we need 1000 threads only one cpu. we would deploy 5-6 processes on one server with 8 cpus. the context switch would cost too much cpu.

so async solution would be better.

would async solution be considered again?

look forward to your reply , @Kevin_Albertson.

Hi, sorry for bumping the thread.

I’m a maintainer of drogon framework. We’ve investigated MongoDB support a while ago. But stopped by the fact that the C API does not support async mode. The main reason being we want to keep the high concurrency all time in our framework and reduce context switches. From our experience, running DB on the same thread as the HTTP request can improve throughput up to 20%. And we try hard to keep all threads not blocked under all circumstances. Otherwise performance tuning becoming a loose-loose game of balancing number of DB threads and dealing with the drawbacks of having too many threads.

Hopefully the feedback can push this forward.