Hi there, let me give you a perhaps surprising, but very real advice: don't solve problems you don't have. Unless you've proven you're bottleneck is the router (which I doubt that will be the bottleneck), go with the simplest thing that solves your problem – in your case it's simply creating a cluster aware router, and hitting it from all incoming requests, it will parallelise the requests into the cluster.
Then benchmark, and once you have data to back that this is not good enough, we can talk :) On Sat, Aug 20, 2016 at 4:34 PM, <mnielsen...@gmail.com> wrote: > Hi, > > This is probably a fairly simple question; I'm hoping to receive the > advice of those more experienced. > > I've been enjoying learning Scala, Play! & Akka over the past few weeks. > > Now it's down to business and I need to design an application that will > scale well. > > Reducing it down to just the point, the application will accept > compute-and-database-heavy, parallelizable requests from users. There will > be an unknown number of users who will generate an unknown request arrival > rate. The requests will be serviced by *remote* backend actors. Each > request may comprise from 1 to thousands of distinct and independent > elements. > > It seems to me the back-end requests would be best satisfied by a pool of > actors that will scale itself up in some manner, and the app would route > the requests via a router -- I'm good with doing that. > > Where I am getting bogged down is here: is it better for the controller > that serves each request to spawn its own router and back-end pool, or I > should have a central router? > > I'm a little uneasy about each request spawning its own router and pool > because that just seems a bit uncontrolled; also it has implications on the > cluster state. > > On the other hand, how would I get a central router to scale? > > What I seem to need is a pool of routers. > > But then it's turtles all the way down? > > Maybe a pool isn't the way to go, but instead use a group, but then it > seems I need to duplicate the logic that's already conveniently present for > pools. > > Any advice would be warmly received. > > -- > >>>>>>>>>> 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. > -- Cheers, Konrad 'ktoso' Malawski Akka <http://akka.io/> @ Lightbend <http://lightbend.com/> -- >>>>>>>>>> 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.
