I have some problems with the behavior of the actor pool. I’am using it for accessing a key/value store (based on LMDB). For increasing the read performance I ‘am using a set of workers. But dispatching the read requests properly seems to be a problem with the current implementation. Not all the requests are satisfied in the same time. The fastest are around 2 usec while the slowest (disk access) could be 1000 times slower! Using a round robin strategy for example is not optimal, since the requests waiting behind a slow request will get delayed while other workers probably have nothing to do.
This problem can’t be solved by a modified dispatching strategy (just improved).
Ideally there should be a single central queue where all the workers are consuming the next message.
Are there plans to implement such a pool? Or are the available MPMC queues not fast enough?
Thank you for the explanation. At the moment we are working with the current actor pool. As long as all the data does fit in the memory of our servers it’s fine. Most of the clients of our PushServers are connected via WWAN, so small variations in speed do not count.
You are right, a local concurrency pool would be the best performing solution for our problem.
The streaming engine does sound interesting. Does this mean actors would be connected by something like a pipe with flow control?
I’am looking forward to the new CAF features. Clustering is something we need too. One part of our server is using the RAFT protocol to synchronize the key/value store inside a cluster. Unfortunately I haven’t found the time to rewrite the RAFT part to use the CAF.
You received this message because you are subscribed to the Google Groups "actor-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to actor-framewo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/actor-framework/f4871a11-0cdd-46cf-8e10-afc49ca74783o%40googlegroups.com.