On Thu, Mar 20, 2014 at 12:25 PM, Eduardo Fernandes <[email protected]>wrote:
> > > El jueves, 20 de marzo de 2014 09:44:28 UTC+1, Patrik Nordwall escribió: >> >> Hi Eduardo, >> > > Many thanks for your time, Patrik. > > >> >> >> On Thu, Mar 20, 2014 at 12:04 AM, Eduardo Fernandes <[email protected]>wrote: >> >>> Hi all. >>> >>> We have a system where we've implemented a pipeline strategy as follows: >>> >>> The idea is move our current architecture to Akka. Taking into >>> consideration that the Akka cluster technology abstracts almost everything >>> related to where the actors are and how many pending messages exist to a >>> particular physical host, etc. >>> >> >> That is not true. Akka cluster is essentially cluster membership, >> including failure detection. Several tools, such as cluster aware routers, >> are provided on top of this, but you have full control of where and how to >> run the actors when you need that. >> > > Gotcha. What I couldn't find is, for example, flush all mailboxes to > actors in a particular host. The idea is to optimize the packets on the > wire with a single shot with as many as pending commands as possible to a > particular physical node. In fact I don't know exactly how to flush pending > commands to the wire. I'm sure it is because I don't heavy enough knowledge > about Akka yet. > > >> >> >>> my question is: >>> >>> Is the internal Akka net pipeline more or less equivalent to our one or, >>> in case of not, could I plug in something similar our current pipeline into >>> Akka? >>> >>> We've found that the three criteria aforementioned enabled us to adjust >>> our current technology to a wide range of customer requirements. >>> >> >> To give me a more clear picture, can you give some example of what this >> solves. >> > > We're calling Akka actors from a farm of tomcat's (hundreds) where each > tomcat manages 5.000 - 9.000 concurrent users. To achieve this we have a > competition criteria to flush the pending net packages (we, currently, > manage byte arrays) which accumulates many pending user commands. As we > need, in many cases, the response of the async cal, we need to block the > thread waiting for the response. So the criteria to flush the packets to > the wire is a combination of : total number of threads blocked, total > volume of data pending to be sent and a max timeout. > Sounds like you have a huge opportunity to improve the scalability of this by using a non-blocking web framework/library, such as Play<http://www.playframework.com/>or Spray <http://spray.io/>. > From our experience, if we have many many small packets (100 bytes) it is > better to accumulate (typically up to 2-3 Kb) and then flush. If there are > aprox 40 threads blocked we also flush to increase tomcat throughput. So, > depending of the application scenario on or other criteria will apply with > more or less relevance. Until now a good choice of the 'magic numbers' > solves the problem with very good results. I'm wondering if this criteria > applies to Akka or not. Maybe Akka solves this kind of problem > automatically auto-adapting itself to the better combination. > When using akka remoting, the serialized representation of the messages are sent without any batching. > > >> >> >>> >>> I couldn't find the right way to go on after reading the docs >>> Dispatchers, Routers, and mailboxes, (and also I'm a novice Akka user). >>> >>> >> I'm not sure I understand what you are trying to do and why, but one >> solution might be to pass the messages via an actor that is responsible for >> the buffering and flushing. >> > > Maybe it is what we need. Is out there some example of this kind of actor > doing both things (buffering and flushing to the wire) the pending packets? > It sounds that is exactly what we want. > Take a look at the Buncher example<http://doc.akka.io/docs/akka/2.3.0/scala/fsm.html#A_Simple_Example> . It is using FSM, which doesn't exist in the Java7 API of Akka. in case you are not using Scala or Java8 you can implement that with an ordinary actor as well. If you want to go more low level and have full control you can use Akka I/O<http://doc.akka.io/docs/akka/2.3.0/scala/io.html>instead of Akka remoting. > > Thanks Patrik again for your time and for dedicating calories to > understand so many different scenarios. > You're welcome. /Patrik > > Best regards, > > > >> >> Regards, >> Patrik >> >> >>> Many thanks for your help and suggestions. >>> >>> Best regards, >>> >>> Eduardo. >>> >>> -- >>> >>>>>>>>>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> >>> Visit this group at http://groups.google.com/group/akka-user. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> >> Patrik Nordwall >> Typesafe <http://typesafe.com/> - Reactive apps on the JVM >> Twitter: @patriknw >> >> -- > >>>>>>>>>> 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- Patrik Nordwall Typesafe <http://typesafe.com/> - Reactive apps on the JVM Twitter: @patriknw -- >>>>>>>>>> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
