I have an http endpoint with a consumerActor (in Node 0) that read the msg from the camel msg and with it create our Message.class than it send to a router1 that forward to one of "N" Worker1 in Node 1, Worker1 make a query on Couchbase process the result and send the Message.class to to a router2 that forward to one of "N" Worker2 in Node 2, Worker2 make a query on Couchbase process the result and send the Message.class to to a router3 that forward to one of "N" Worker3 in Node 3, at the end Worker3 make a query on Couchbase process the result and send the http response.
Il giorno martedì 13 settembre 2016 10:42:39 UTC+2, √ ha scritto: > > What is your bottleneck? > > On Tue, Sep 13, 2016 at 10:13 AM, silvio poma <[email protected] > <javascript:>> wrote: > >> Thanks guy, I eventually fixed all the configuration as you suggested and >> now everything is working. >> I can see a big improvement in the average time of response of my service >> but the throughput is still the same of before. >> Any other suggestions, my target is to have throughput as high as >> possible? >> >> Thanks for yours tips! >> Silvio >> >> >> Il giorno sabato 10 settembre 2016 12:11:35 UTC+2, Guido Medina ha >> scritto: >>> >>> Your contribution makes ID strategy automatic even better, you know >>> automatic = explicit + incremental right? >>> So I think it would also work for your project, but I do understand why >>> you have chosen explicit as you want to fail if you introduce a new class >>> and forget to register it. >>> >>> I use automatic because I only register classes I need extremely >>> optimize in regards of message size over the wire which is important from >>> the low latency PoV, >>> I believe your contribution should also work with automatic? do you >>> happen to know if it is tied to explicit or to the phase of registering >>> listed classes? >>> >>> If the latter then I believe it should also apply to automatic listed >>> classes to register. >>> >>> Guido. >>> >>> On Friday, September 9, 2016 at 8:36:54 PM UTC+1, Justin du coeur wrote: >>>> >>>> On Fri, Sep 9, 2016 at 2:51 PM, Guido Medina <[email protected]> wrote: >>>> >>>>> The problem with explicit is that there are so many "trait" and >>>>> "classes" not really registered which is why I use it, >>>>> it is the newest ID strategy as it register things you might not care >>>>> but commonly used messages you register, >>>>> that way you get performance for what is important and automatic >>>>> registration for other things. >>>>> >>>> >>>> Yeah -- like I said, hardcore. But my situation is extreme: I'm using >>>> Kryo for *persistent* serialization -- as far as I know, Querki may be the >>>> first project doing that in production. That being the case, I care about >>>> the bytes taken up by FQDNs (and the time required to look them up, and >>>> the >>>> risks of things changing out from under me), so I've built out quite a >>>> bit >>>> <https://github.com/jducoeur/Querki/tree/master/querki/scalajvm/app/querki/persistence> >>>> of >>>> infrastructure >>>> <https://github.com/jducoeur/Querki/tree/master/querki/scalajvm/test/querki/persistence> >>>> >>>> to make this work safely. >>>> >>>> (Yes, I know -- I'm insane. But I like Kryo's attitude more than >>>> protobuf's from a code-cohesion POV, so I've invested the time to make it >>>> work solidly for Akka Persistence.) >>>> >>>> *Totally* understood about the sheer number of classes involved in >>>> making this work -- I spent quite a while wrestling with that. But note >>>> that I contributed a new feature to the romix library >>>> <https://github.com/romix/akka-kryo-serialization/commit/ffb2fec2dc9cfbca9c3503d6f32c6500cd1c40cd> >>>> >>>> to help with this. The SubclassResolver allows you to register a single >>>> serializer for an entire type hierarchy, when that makes sense. (Which it >>>> does for many of the common library types.) I found that this cuts down >>>> on >>>> the number of "overhead" registrations required by a *huge* fraction -- >>>> you >>>> can suddenly deal with, eg, Set with a single registration instead of six. >>>> >>>> And yes, I need to find some time to write up a long blog post about >>>> all of this... >>>> >>> -- >> >>>>>>>>>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Cheers, > √ > -- >>>>>>>>>> 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
