Spray application resources and timeouts under heavy load.

[Conor Reedy]

Hello,

I have multiple instances of a spray app sitting behind a load balancer (6).  When under heavy load the client calls are being timed out.  Can someone point me in the right direction for documentation? 

I'm hoping to get some insight into allowing unlimited connections to the application (its not a public facing application so no worry of DOS attack).  Also the application seems to limit itself to using 25% CPU of the box and a very small memory footprint.  Are there configurations that would allow the application to run using all available resources? Does this have to do with the default dispatcher?

Thank you very much for your time!

Best,

Conor

[Jan-Pieter van den Heuvel]

Hi Conor,

I don't think there is any documentation related to the analysis of performance problems in Spray (other than questions asked previously on this list). This highly depends on the design of your application and is more related to analyzing performance problems in general than specifically for Spray. Can you give us some more info on what it is you are trying to do and the design of your application?

Having said that, one common mistake is to perform blocking calls inside the Http Service containing your routes. Keep in mind that this is an actor and can only handle one message (= request) at a time. If you perform any computationally expensive operations or any IO operations (e.g. database calls) make sure you perform them asynchronously using Futures or other actors.

Hope this helps.

Kind regards,

Jan-Pieter

--
You received this message because you are subscribed to the Google Groups "spray.io User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spray-user+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/spray-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/spray-user/74075895-17d5-470f-8edc-d04d45155278%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Conor Reedy]

Hello!

Thanks for the response. Really appreciate any input on this.

As far as blocking calls all IO is handled inside of futures.  The hierarchy of calls of pretty straight forward being a "root" actor passed into the Http.Bind.  From there the app passes to a secondary handler (there are 2 routes so there are 2 different handlers).  The db calls inside of these Actors are wrapped in futures and the response is wrapped inside of onComplete.  I guess my question is mainly focusing on the use of 25% cpu.  Even when we're hammering requests it remains the same.  What can I do to make full use of the CPU available?  Could it be that the actor's mailbox is filling up with too many requests?  My understanding is that if the Actor is getting messages for creating futures each future will run on a different thread (somewhere in the ether) return to the actor to complete the request.  Is there a way to configure child actors for this so multiple requests can be processed in parallel?  This concept is somewhat of a grey area to me as I don't understand why the resources aren't being fully utilized and if there is a way to distribute the work is there some documentation of patterns to achieve this "load balancing".

Thank you an immense amount for your time.

Best,

Conor

On Friday, November 4, 2016 at 3:59:53 AM UTC-4, Jan-Pieter van den Heuvel wrote:

Hi Conor,

I don't think there is any documentation related to the analysis of performance problems in Spray (other than questions asked previously on this list). This highly depends on the design of your application and is more related to analyzing performance problems in general than specifically for Spray. Can you give us some more info on what it is you are trying to do and the design of your application?

Having said that, one common mistake is to perform blocking calls inside the Http Service containing your routes. Keep in mind that this is an actor and can only handle one message (= request) at a time. If you perform any computationally expensive operations or any IO operations (e.g. database calls) make sure you perform them asynchronously using Futures or other actors.

Hope this helps.

Kind regards,

Jan-Pieter

2016-11-03 21:53 GMT+01:00 Conor Reedy <cre...@geezeo.com>:

Hello,

I have multiple instances of a spray app sitting behind a load balancer (6).  When under heavy load the client calls are being timed out.  Can someone point me in the right direction for documentation? 

I'm hoping to get some insight into allowing unlimited connections to the application (its not a public facing application so no worry of DOS attack).  Also the application seems to limit itself to using 25% CPU of the box and a very small memory footprint.  Are there configurations that would allow the application to run using all available resources? Does this have to do with the default dispatcher?

Thank you very much for your time!

Best,

Conor

--
You received this message because you are subscribed to the Google Groups "spray.io User List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to spray-user+...@googlegroups.com.