Re: [akka-user] Akka HTTP client - Advice for executor context

[Albert]

Great explanation Arne - thank you!

I think I have all pieces except one:

I call web services in parallel, creating Futures. Futures are then 
converted to one Future (like Future.sequence). 
Do I reach backpressure in case of "too many requests" when router respond 
with Source (OverflowStrategy.backpressure) with flow with business logic 
producing future?
In other words if my Future will be assembled as Flow and router respond 
with Source?

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

Re: [akka-user] Akka HTTP client - Advice for executor context

[Albert Gorski]

Great explanation Arne - thank you!

I think I have all pieces except one:

I call web services in parallel, creating Futures. Futures are then
converted to one Future (like *Future.sequence*).
When, in router, I create response with Source and
set OverflowStrategy.backpressure


2017-04-26 10:15 GMT+02:00 Arno Haase :

>
> > /_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/c
> urrent/additional/faq.html
> >>  Search the archives: https://groups.google.com/grou
> p/akka-user
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Akka User List" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/to
> pic/akka-user/6XMGUhB8caE/unsubscribe.
> To unsubscribe from this group and all its topics, 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.
>

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

Re: [akka-user] Akka HTTP client - Advice for executor context

[Arno Haase]

> /_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.

Re: [akka-user] Akka HTTP client - Advice for executor context

[Albert]

Thank you Konrad for really fast response!

I read the docs again and if I correct understood my configuration 
can/should be like this one:
*1. Dispatcher(s)*
One dispatcher for all web service clients with fixed size. Size of the 
pool correspond to CPU amount (16 for 16 cores)
*or*
dispatcher pro web service client with fixed size. Size of the pool = 
number of cores / dispatcher amount

*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?

*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?

Cheers,
Albert

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

Re: [akka-user] Akka HTTP client - Advice for executor context

[Konrad Malawski]

Dispatcher (executor) is mostly important if you're doing bad things on it
- like blocking on responses for example.
If you're handling things in async / reactive ways the default akka
dispatcher is fine most of the time, just don't block on it (read this:
http://doc.akka.io/docs/akka-http/10.0.5/scala/http/handling-blocking-operations-in-akka-http-routes.html
same
thing applies in any code really).

It is more interesting to think about the connection pools configured than
the dispatcher here.
Those can limit how many connections you can have open to a given host,
what timeouts should be set for idle timeouts and cleaning up connections
etc. You can read about this in documentation on pools in akka http.

-- 
Konrad `ktoso` Malawski
Akka  @ Lightbend 

On 26 April 2017 at 09:15:00, Albert Gorski (albgor...@gmail.com) wrote:

Hi,
I've Akka HTTP service which calls 5 other services using Akka HTTP client
(Host-Level Client-Side API). Currently I have executor context per service
(host/port).

What is the best practice for setting executor context? I mean, should I
use fork-join or cached or fixed thread pool or maybe something else?
Is it good to configure executor context pro service? It's a kind of
bulkhead solution, but is it really good for performance?

Thank you for response in advance:)

Cheers,
Albert

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

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