> /_Question_:/ > - does it make really sense to create dispatcher pro web service client > or one for all? Do you've any experience with it? > - is it better to use Dispatcher with fork-join or fixed-size one?
Using the default pool fully utilizes the CPU, and using a separate dispatcher will not provide "more" throughput. As Konrad pointed out, this relies on your code *never* blocking threads - if you really want to do that, you need a separate dispatcher. But since you ask for "better", avoiding blocking code (or isolating it in separate actors with a separate dispatcher, if they cannot be avoided) is typically the "better" approach in Akka. There are basically two situations where using separate dispatchers provides benefits: Encapsulating blocking operations, and managing / limiting load. For HTTP clients, usually neither fits: Blocking code is typically better off in separate actors (if it can not be avoided), and load limitation is usually easier to manage using connection configuration. > *2. Connection pool(s)* > Currently I use one /cachedHostConnectionPool/ connection pool for all > materializations for given host/port. I use also /Source.queue /to > handle more requests, if necessary. > Size of pool is of course very specific to the running environment - I > set max to 256. > > /_Questions_:/ > - how "heavy" is queuing? Are "just" request objects kept in queue? > - theoretically if connection pool is bigger then dispatcher threads > should be also bigger -> to handle responses fast enough. In other > words, make it sense to limit connection pool if dispatcher has less > threads? Am I right / make it sense? This is about back pressure: Queueing requests can buffer load peaks, but if the incoming load is more than the server can handle, the queue will overflow sooner or later, resulting in rejected requests - which is a good thing, the alternative being some kind of crash of the server. If your application overloads the called server, there is nothing you can do about it. If processing the responses overloads your application, the approach depends on which resource is the limiting factor. You should go for implementing some kind of explicit back pressure all the way back to the code triggering the web service calls - trying to solve that using thread pool sizes is tricky and will usually not solve the problem in a robust way. - Arno -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
