These are chat archives for ManageIQ/manageiq/performance

30th
Nov 2016
Keenan Brock
@kbrock
Nov 30 2016 02:55
Also, that article talks about "smart stack" and others discovery/configuration information that is very interesting.
huh, looks like dbslayer died around 2008, but is very similar to airbnb and their proxy. (seemed just yesterday when ny times announced that :( )
Keenan Brock
@kbrock
Nov 30 2016 05:30
@NickLaMuro For the BZ, can we use a delegate for vm.ram_size => hardware.memory_mb
the new delegate format works, but I'm thinking darga doesn't support that format.
you remember off the top of your head?
Archit Sharma
@arcolife
Nov 30 2016 07:10
@kbrock @dmetzger57 @NickLaMuro regarding the perf_capture delays we talked about yesterday: https://bugzilla.redhat.com/show_bug.cgi?id=1346999#c8
Archit Sharma
@arcolife
Nov 30 2016 07:17
@FDewaleyne ^
Keenan Brock
@kbrock
Nov 30 2016 14:37

@arcolife so it is agreed that the timer is fixed/super speedy. Before this was fixed, there was no way the data could be captured correctly.
Now, the capture is performed every ~3 minutes ±15 seconds

I hear you saying, with this setup, it is complaining that there are gaps.
Questions:

  1. Are the gaps due to the similator only producing 1 minutes of data? (due to the way it was designed)
  2. Are there no gaps, but the "gap detection" code is wrong?
  3. Are the gaps due to the non "real time" nature of these timings. We send fewer capture events if a machine has no alerts.
  4. Are we possibly sending the wrong "start date" for the metric data, so we aren't getting all of it? (lets hold off on this one for now)
Can you look at the data produced, do you know if there actually are gaps? [point #2, and touches poing #1]
Jason Frey
@Fryguy
Nov 30 2016 15:14
@kbrock Reading back on your crystal stuff...it's just not there yet...some specific benchmarks are even showing it to be slower than Ruby surprisingly
I really want it to get there though...it's a really nice language, but I am partial to Ruby syntax after all :)
Keenan Brock
@kbrock
Nov 30 2016 15:27
@Fryguy +1
Keenan Brock
@kbrock
Nov 30 2016 15:44
@Fryguy lots of the savings you get from crystal is because they are closer to java/C in their handling of primitives.
So if you want to work with integers / floats - a lot quicker. But if you like the ruby auto conversion of integer to bigint when it is needed, then crystal is slower.
It is the safety (think rust has this as well) that is very attractive to me
thought you might like that
Keenan Brock
@kbrock
Nov 30 2016 16:39
yea
that was what I was referring
Jason Frey
@Fryguy
Nov 30 2016 16:40
:D
Keenan Brock
@kbrock
Nov 30 2016 16:40
it was ruby's auto conversion to bigint that was the big savings for ruby
also, the way it was setup, it was tricky for tail end recursion
Jason Frey
@Fryguy
Nov 30 2016 16:40
yup
Keenan Brock
@kbrock
Nov 30 2016 16:41
aah - I had a few comments in there
Keenan Brock
@kbrock
Nov 30 2016 16:48
@Fryguy I did talk with the crystal team trying to use the same gc as ruby.
kinda annoyed with ruby that they had to invent their own GC instead of using / improving an existing library. Or generating one that works similar to other GC implementations out there. (plug and play)
Jason Frey
@Fryguy
Nov 30 2016 16:50

kinda annoyed with ruby that they had to invent their own GC instead of using / improving an existing library.

The one GC that I know of that's "generic" is not really very good. Not sure what Ruby would have used

Keenan Brock
@kbrock
Nov 30 2016 16:51
I did see a paper about ruby using the Boehm - same one crystal uses. but that was before ruby's improved
would be nice the the ruby's implementation had a similar interface to the Boehm one
Jason Frey
@Fryguy
Nov 30 2016 16:51
yeah, Boehm is the one that's not very good
I mean it gets you started, but as soon as you get slightly complicated, it breaks down
Keenan Brock
@kbrock
Nov 30 2016 16:52
wonder what rubineous uses
Jason Frey
@Fryguy
Nov 30 2016 16:52
Good question
Keenan Brock
@kbrock
Nov 30 2016 16:52
keep feeling like crystal should steal more from them