I have not had time to watch this yet, but perhaps it may be of some interest - https://vimeo.com/105888905
On 17 October 2014 08:39, Koray Al <hecatom...@gmail.com> wrote: > Hello All, > > Our application is nearly offline, it doesn't need to communicate with > remote servers etc. The only obligation they have is to communicate with the > hardware that are in the same gigabit network in realtime. So the load is > nearly at the same level all the time. We also already have more memory than > it needs. (in fact currently the application is using %8 of the computer > memory at most) > > I have checked out my application with jHiccup (which Adam suggested) > running for a day and it seems that the highest hiccup duration is 65 > milliseconds. It is acceptable for my application ( but it will not be, if I > try to implement the realtime part I was asking for ) A friend of mine also > suggested checking out the garbage collection suggestions for Apache Kafka > and Twitter Storm. ( https://gist.github.com/mrflip/5958028 ) I will monitor > the system with suggestions from there. > > After watching Konrad's link, I am now sure that I am way over my head :) > But I think using optimizations suggested by experts will surely help. > > It looks like I will have to use C++ for that kind of realtime applications, > but I will resist as long as I can :) > > Regards, > Koray > > On Thursday, October 16, 2014 3:57:42 PM UTC+3, Alec Zorab wrote: >> >> I'm not sure I'd say it was the *most* important factor - if you're >> spending a lot of time talking to a database or waiting for packets to cross >> the atlantic then you may have other problems to contend with, but certainly >> at the 5ms scale, GC can have a very significant impact. >> >> GC monitoring and tuning on the jvm is an art unto itself - google's >> probably the best way to familiarise yourself with it, but if you just want >> to get a quick and dirty feel for what's going on, the VisualGC plugin for >> VisualVM is useful. >> >> On 16 October 2014 13:30, Koray Al <hecat...@gmail.com> wrote: >>> >>> @Alec >>> >>> So when 5ms is the target, you are saying that the GC becomes the most >>> important factor for the system's performance. Do you have any suggestion >>> (book/website etc.) for me to check out for this matter? I have my >>> application currently running in a high traffic environment and I would love >>> to monitor GC pauses periodically if I knew how :) >>> >>> @Adam >>> >>> Thank you for the suggestion, I also came across similar JVMs but the >>> cost seems to be unapplicable for me since most of my applications do not >>> run in a central server, instead it runs on a lot of nodes. >>> >>> @Conrad >>> >>> Thank you for the link, this is exactly what I am looking for since I >>> have no idea what to check for my system's performance. In the meantime I >>> was checking out Kamon since my application generates and kills a lot of >>> actors and I need a way to monitor actor counts, transaction times etc. >>> >>> I will check out all your suggestions. >>> >>> Regards, >>> Koray >>> >>> >>> On Wednesday, October 15, 2014 3:24:53 PM UTC+3, Akka Team wrote: >>>> >>>> Hi Koray, >>>> I concur with the other guys – these kinds of skills are very specific. >>>> It's certainly doable, and there's loads of companies using both the JVM >>>> and/or Akka for these kinds of systems, but it requires a lot of thinking / >>>> monitoring / tweaking to get these super high performance apps. >>>> Here's a talk from the Twitter guys I really liked which shows a bit of >>>> the resources and techniques one has to apply when building such apps: >>>> Twitter-Scale Computing with OpenJDK (youtube). >>>> >>>> These topics are the fun and interesting part, so you're in for a ride - >>>> enjoy it. :-) >>>> >>>> -- >>>> Konrad >>>> >>>> Akka Team >>>> Typesafe - The software stack for applications that scale >>>> Blog: letitcrash.com >>>> Twitter: @akkateam >>> >>> -- >>> >>>>>>>>>> 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+...@googlegroups.com. >>> To post to this group, send email to akka...@googlegroups.com. >>> Visit this group at http://groups.google.com/group/akka-user. >>> For more options, visit https://groups.google.com/d/optout. >> >> > -- >>>>>>>>>>> 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 http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk -- >>>>>>>>>> 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
