Looking at the code it seems heavy use of urandom is made, which will slowdown operations significantly.
I recommend to switch to storing data in None objects to speedup operations.
Furthermore you might consider creating a c extension to improve performance even more - or while we are at it maybe rewrite the whole code into assembler?
If you are clever (and you must be, having written this amazing software) you might also be able to store the code directly into a network card with TOE support so processing can be handled directly in the nic without causing interrupts.
If that still doesn't achieve expected performance, it might be feasible to (again) rewrite the code and store it directly on internet switches / routers so that any incoming mangodb connections are handled directly without connecting to slow mongodb endpoints.
If that is still to slow I'd suggest to write a reverse mongodb client, effectively exploiting the client when it tries to connect to any mongodb server and replacing it with a local mangodb client - which finally should fix all the performance issues we have seen AND still keeps the same data as reliable as mongodb did.
If even that doesn't perform fast enough I suggest to extend the previous approach by rewriting the internet and removing all occurrences of mongodb and replacing it by postgresql (might also be a feasible attempt as step 1).
Looking at the code it seems heavy use of urandom is made, which will slowdown operations significantly.
I recommend to switch to storing data in None objects to speedup operations.
Furthermore you might consider creating a c extension to improve performance even more - or while we are at it maybe rewrite the whole code into assembler?
If you are clever (and you must be, having written this amazing software) you might also be able to store the code directly into a network card with TOE support so processing can be handled directly in the nic without causing interrupts.
If that still doesn't achieve expected performance, it might be feasible to (again) rewrite the code and store it directly on internet switches / routers so that any incoming mangodb connections are handled directly without connecting to slow mongodb endpoints.
If that is still to slow I'd suggest to write a reverse mongodb client, effectively exploiting the client when it tries to connect to any mongodb server and replacing it with a local mangodb client - which finally should fix all the performance issues we have seen AND still keeps the same data as reliable as mongodb did.
If even that doesn't perform fast enough I suggest to extend the previous approach by rewriting the internet and removing all occurrences of mongodb and replacing it by postgresql (might also be a feasible attempt as step 1).