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 <oxy...@gmail.com> 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 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.