Panel:


Dave Kimura
Charles Max Wood
David Richards


Special Guest: Dan Mayer

In this episode of Ruby Rogues, the panel talks with Dan Mayer who believes that small distributed software teams can make a large impact. Dan loves Ruby, distributed systems, OSS, and making development easier. The panel and Dan talk about performance and benchmarking. Check out today’s episode to learn more!

Show Topics:

0:00 – Sentry.IO – Advertisement!

1:07 – Chuck: Our panel is Dave, David, myself, and our guest is Dan Mayer. Say “Hi”!

1:24 – Chuck: Give a brief introduction, please.

1:32 – Dan gives his background and what he currently is working on.

1:53 – Chuck: We wanted to talk to you about benchmarking and performance. Tell us how you got into this?

2:28 – Dan: It has been an interesting timeline for me. About seven years I worked for a large site that had a legacy Rails app. It got a lot of dusty corners over the years and we removed dead code, and removed bugs and confusion for the consumer. We were finding ways to tweak it and not impacting your users. I was using Trace Point but the overhead was quite significant. I moved away from that project but found that I found a need for it, again, a few years later. I actually tried to modify...and basically Eric said “prove that it is slow.” It really wasn’t the type of bottleneck that I was seeing. Since then I am rewriting it. I removed one bottleneck and now...

5:00 – Chuck: ...if that number gets smaller then Ruby is doing well. Is it really that simple? How do you benchmark?

5:15 – Dan answers the question.

6:40 – Panel: How do you benchmark things front to back?

6:49 – Dan: I look at benchmarking in different layers. You can see the overall impact in the broad range. If you want to see specific things then that’s a little trickier. For Ruby 3x3 he has been working on a Rails Benchmark, and that’s Noah. He has a sample Rails app and...

8:09 – Chuck: He is using discourse, and we talked to him on a past episode.

8:20 – Dan: My original plan was to insert my gem within that project. However, I ran into a few issues and Noah and I are working on that because of the issues.

8:57 – Panel: How does the coverband gem – how does it provide security so you don’t leak out information to in-users?

9:12 – Dan answers the question.

9:54 – Panel: Then you can build whatever views you want to trace back that sort of information?

10:02 – Dan answers the question.

10:30 – Chuck: Is it running benchmarks against every method you have in your app or what?

10:40 – Dan answers question.

11:27 – Panel: I like when I can remove all of the code I feel safe.

1:37 – Dan: The gem was driven by the fact that I love to delete code. These old files have been sitting around – they aren’t valid – let’s get rid of them.

12:04 – Chuck: This is off topic from benchmarking, but...

12:43 – Dan: ...to get that feature at run time it can hurt your performance. 

15:20 – Panel: Is there added memory usage?

15:27 – Dan: I rewrote the library around coverage and I put it out. It worked well for my company and myself. But people were saying that they got a huge performance hit. I went from needing to sample to capture...the new bottleneck was collecting the data all of the code usage of your gems and...it went from just recording your custom code to all Ruby code. Where it was slowing down was reporting that.

I didn’t have any benchmarks to capture that. What I was failing to do was...

I can talk about what I did do to help people if you want?

17:41 – Chuck: Looking at how much storage is my app using or how much...How can you even begin to isolate it?

18:11 – Dan: On all the different types of benchmarking – I know there is a benchmarking memory increase. I haven’t benchmarked that, yet. To get at these different levels, how do we ensure that’s fast? It was a new challenge to me.

19:45 – Panel: It sounds like this has become a practice over the years. Is that how you handle it or how do you like to