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 firstname.lastname@example.org.
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.
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.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?Hope this helps.Kind regards,Jan-Pieter
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