Roman: Thanks for putting this together. I confess I haven't dug in in detail yet, but having the numbers available is a nice resource.
Best Erick On Thu, Aug 1, 2013 at 6:23 PM, Roman Chyla <roman.ch...@gmail.com> wrote: > On Thu, Aug 1, 2013 at 6:11 PM, Shawn Heisey <s...@elyograg.org> wrote: > > > On 8/1/2013 2:08 PM, Roman Chyla wrote: > > > >> Hi, here is a short post describing the results of the yesterday run > with > >> added parameters as per Shawn's recommendation, have fun getting > confused > >> ;) > >> > >> > http://29min.wordpress.com/**2013/08/01/measuring-solr-**performance-ii/< > http://29min.wordpress.com/2013/08/01/measuring-solr-performance-ii/> > >> > > > > I am having a very difficult time with the graphs. I have no idea what > > I'm looking at. The graphs are probably self-explanatory to you, because > > you created them and you've been staring at them for hours. There are > both > > lines and shaded areas, and I can't tell what they mean. > > > > I know :) but I am rather investing time in preparing a better test, > because as you said, worst case is the aim - and I would like to trigger > the worst case (btw, all these remaining GC configs have comparable max > execution time of less than 1.5s - that is the worst case in their case so > far and with so a few measurements, there is no meaningful analysis of > significance between them). But when I look at the heights of the areas, in > the charts, the higher means worse - so the yellow seems to be the worst > (g1-custom), your preferred configuration (i think it was cms-x1, green) > seems better than g1-custom. But 'SEEMS' is an important qualifier here > > > > > > Tables with numbers, if they have a good legend, would be awesome. > > > > tables are there, just hidden, you would have to run it - the code is there > as well... > > > > > > One thing I'd like to see, and when I have some time of my own I will do > > some comprehensive long-term comparisons on production systems, is to see > > what adding or changing *one* GC tuning parameter at a time does, so I > can > > find the ideal settings and have some idea of which settings make the > most > > difference. > > > > My concern with garbage collection tuning has been mostly worst-case > > scenario pauses. I certainly do want averages to come down, but it's > > really the worst-case that concerns me. > > > > Let's say that one of my typical queries takes 100 milliseconds on > average > > with my GC config. Somebody comes up with another GC config that makes > the > > same query take 25 milliseconds or less on average. If that config also > > results in rare stop-the-world garbage collections that take 5 full > > seconds, I won't be using it. I'd rather deal with the slower average > > queries than the GC pause problems. > > > > exactly > > > > > > I had to let my production systems run for days with jHiccup before I > > really noticed that I had a GC pause problem. I've since learned that > if I > > look at GC logs with GCLogViewer, I can get much the same information. > > > > well, and instead of days, I think it is possible to trigger the worst case > scenario in a matter of hours (but that is my conjecture, to be proven > wrong... ;)) > > roman > > > > > > Thanks, > > Shawn > > > > >
