WEBVTT 1 00:00:04.799 --> 00:00:07.919 Hey, folks, welcome back to another episode of the Ruby 2 00:00:08.000 --> 00:00:11.160 Rogues podcast. This week, on our panel we have Ayush 3 00:00:11.279 --> 00:00:16.079 Nowatya Hello. Hello, I'm Charles max Wood from top End Devs. 4 00:00:16.719 --> 00:00:19.719 This week we have a special guest. We have David Henner. David, 5 00:00:20.239 --> 00:00:24.320 you gave a talk at Rails World in September talking 6 00:00:24.359 --> 00:00:29.039 about performance, and so we reached out because we thought, 7 00:00:29.079 --> 00:00:32.520 you know, hey, it's it's interesting to talk about. You're 8 00:00:32.560 --> 00:00:35.920 on the Zendesk Ruby scaling team, so it sounds like 9 00:00:35.960 --> 00:00:41.560 you're working on I guess a non trivial application. I 10 00:00:41.560 --> 00:00:43.320 don't know if it's just the traffic, but it seems 11 00:00:43.359 --> 00:00:47.759 like it's it's an involved app. So yeah, do you 12 00:00:47.759 --> 00:00:50.000 want to just give I guess any more introduction that 13 00:00:50.039 --> 00:00:51.799 you want us to have and then we can dive 14 00:00:51.840 --> 00:00:54.880 in and talk about how to do performance with Ruby. 15 00:00:56.880 --> 00:00:57.119 Yeah. 16 00:00:57.159 --> 00:00:59.439 I gave that talk, and the ironic part of that, 17 00:00:59.479 --> 00:01:03.359 I gave that same well, I gave almost the same 18 00:01:03.439 --> 00:01:07.439 talk within Zendesk, and it was it was originally an 19 00:01:07.519 --> 00:01:10.159 hour and a half and then at Zendesk I had 20 00:01:10.159 --> 00:01:12.640 to break it down to forty five minutes. And then 21 00:01:12.680 --> 00:01:14.159 I thought I was dumb because I thought it was 22 00:01:14.159 --> 00:01:17.079 a forty five minute talk for Raals World. I found 23 00:01:17.120 --> 00:01:22.400 out it was a thirty minute talk. It's all so 24 00:01:22.480 --> 00:01:26.560 I've got a lot more content, but yeah, thirty minutes 25 00:01:26.599 --> 00:01:30.840 and that's normal. Probably, Wow, thirty minutes, it's not much time. 26 00:01:31.760 --> 00:01:35.120 It's so funny to me because I talked to people 27 00:01:35.159 --> 00:01:37.359 who haven't spoken at a conference or haven't you know, 28 00:01:37.400 --> 00:01:42.480 given a talk in other settings. And you know, so 29 00:01:42.560 --> 00:01:45.120 for example, at church, a lot of times, you know, 30 00:01:45.120 --> 00:01:47.200 they'll have us give like a fifteen minute talk on 31 00:01:47.239 --> 00:01:47.760 a topic. 32 00:01:48.280 --> 00:01:51.319 But it's like, man, fifteen. 33 00:01:50.959 --> 00:01:53.640 Minute talks are hard, and they're like, what, you only 34 00:01:53.640 --> 00:01:55.400 have to come up with this much content, And I'm 35 00:01:55.400 --> 00:01:57.599 like I always come up with an hour's worth of 36 00:01:57.599 --> 00:01:58.920 content and have to cut it down. 37 00:01:59.400 --> 00:01:59.599 Yeah. 38 00:01:59.640 --> 00:02:01.879 Right, there's always more I could put in it. 39 00:02:01.920 --> 00:02:04.760 And so it's knowing what to take out more than 40 00:02:05.040 --> 00:02:08.120 knowing what to put in and then turning that into 41 00:02:08.199 --> 00:02:11.360 a I guess, a cohesive narrative. 42 00:02:11.439 --> 00:02:15.400 And yeah, anyway, having the flow is the hardest part. Yeah. 43 00:02:15.639 --> 00:02:17.840 Today it's like, oh my god, I need to have 44 00:02:17.919 --> 00:02:20.719 this and the original flow is so perfect that I 45 00:02:20.759 --> 00:02:25.599 have actually tweaked down at my company. Then to asking 46 00:02:25.759 --> 00:02:28.400 was like, yeah, I got this, And it wasn't until 47 00:02:28.639 --> 00:02:30.800 two months before the conference talk when I had to 48 00:02:30.800 --> 00:02:36.639 submit my papers. Oh thirty minutes. Oh oh no, let's 49 00:02:36.680 --> 00:02:40.800 get that done. I think it turned out fairly well 50 00:02:40.800 --> 00:02:43.400 though at the end of the day. I was the 51 00:02:43.520 --> 00:02:46.599 last talk on the last day, right before Aaron Patterson talked, though, 52 00:02:46.960 --> 00:02:49.039 and I will say that is the worst time slot 53 00:02:49.080 --> 00:02:52.319 to have, like you're worried about your talk the whole time, 54 00:02:52.360 --> 00:02:54.360 and first talk that I actually paid attention to I 55 00:02:54.360 --> 00:02:56.560 was still kind of little amped up, and that was 56 00:02:56.599 --> 00:03:02.319 Aaron's say goodbye speech. Basically, it's like right, dang. 57 00:03:03.199 --> 00:03:11.479 Yeah, so yeah, I've been there too. I want to 58 00:03:11.520 --> 00:03:15.159 just dive in. So you know what, what's kind of 59 00:03:15.159 --> 00:03:18.000 the low hanging fruit in the rails performance world. 60 00:03:18.280 --> 00:03:21.319 I think the big thing that people like, at least 61 00:03:21.360 --> 00:03:23.919 I don't hear people talking about. And it's like everybody 62 00:03:23.960 --> 00:03:26.960 focuses on. First off, a lot of people focus on 63 00:03:27.039 --> 00:03:29.759 really hard things, and it's like, hey, let's change it 64 00:03:29.800 --> 00:03:31.919 to a micro service. It's like, oh, yeah, that might 65 00:03:31.960 --> 00:03:34.039 make it faster, but probably is just going to hold 66 00:03:34.039 --> 00:03:37.400 a bunch of crust. But the big thing people don't 67 00:03:38.319 --> 00:03:43.599 advertise in the community is just observability and like trying 68 00:03:43.639 --> 00:03:47.400 to actually like find the things you need through. Let's 69 00:03:47.400 --> 00:03:51.039 say I use data Dog as endsk, but everybody can 70 00:03:51.199 --> 00:03:55.039 also complains about the cost of the observability and it's like, 71 00:03:55.360 --> 00:03:58.280 right now, you can actually make your costs lower by 72 00:03:58.319 --> 00:04:01.199 turning on software switches. You don't the observabilit one hundred 73 00:04:01.199 --> 00:04:03.400 percent of time, for example, and you can actually have 74 00:04:04.120 --> 00:04:08.120 like tricks around, like the observability layer just literally going 75 00:04:08.159 --> 00:04:12.159 out and like Okay, if we monitor something and something 76 00:04:12.199 --> 00:04:15.360 goes awry, turn on the observability layer. But don't turn 77 00:04:15.400 --> 00:04:17.680 it out all the time, because if you do, you're 78 00:04:17.759 --> 00:04:21.040 going to be paying half of your infrastructure talks or 79 00:04:21.120 --> 00:04:25.120 or infrastructure costs to Data Dog. So I started to 80 00:04:25.160 --> 00:04:28.199 talk with that and that was I hope a lot 81 00:04:28.240 --> 00:04:35.160 of people got valuable as an dollar figures stuff out 82 00:04:35.160 --> 00:04:35.360 of that. 83 00:04:35.959 --> 00:04:39.319 But then like, hang on, because I have a question 84 00:04:39.360 --> 00:04:43.160 about that. Yep, Because you know, I've used Century, I've 85 00:04:43.240 --> 00:04:49.680 used roll Bar, I've used a new relic. I'm trying 86 00:04:49.720 --> 00:04:52.439 to think of all the different ones that I've I've 87 00:04:52.560 --> 00:04:54.759 used over the years. I mean most of them they 88 00:04:54.839 --> 00:04:57.079 sponsor the show, and so I feel like I have to. 89 00:04:58.199 --> 00:04:59.959 I have to feel good about it being a good 90 00:05:00.040 --> 00:05:03.000 product before I go Okay, you can sponsor the show 91 00:05:03.040 --> 00:05:04.879 and I can go out and say you should try 92 00:05:04.959 --> 00:05:08.800 this one. And so I've tried a whole bunch of them, 93 00:05:08.839 --> 00:05:11.000 but most of them you just install the gem and 94 00:05:11.040 --> 00:05:14.360 then it just kind of, you know, behind the scenes, 95 00:05:14.399 --> 00:05:18.680 does the work. And so my question there is how 96 00:05:18.720 --> 00:05:20.279 do you put a switch around that? Do you just 97 00:05:20.319 --> 00:05:24.680 put it into your initializer? And then so, lawyer, how 98 00:05:24.720 --> 00:05:25.360 do you handle it? 99 00:05:25.920 --> 00:05:29.560 In the talk I gave the actual code, but there 100 00:05:29.680 --> 00:05:32.759 is a general. There is a general like, hey, it's 101 00:05:32.800 --> 00:05:36.439 on or off, and we always have that general thing on. 102 00:05:36.680 --> 00:05:39.040 So there's like the general. But then let's say in 103 00:05:39.120 --> 00:05:43.199 the traces that you get a stack trace and the 104 00:05:43.240 --> 00:05:45.279 default stat trace. I believe it is just one bar, 105 00:05:46.160 --> 00:05:50.279 nothing extraordinary, but you can actually turn a whole bunch 106 00:05:50.399 --> 00:05:52.759 of traces on within that trace. 107 00:05:52.839 --> 00:05:54.360 Oh okay, break. 108 00:05:54.120 --> 00:05:57.120 Down to see everything that's going on, and then you 109 00:05:57.160 --> 00:06:01.120 can actually identify, oh, this part of the code, here's slow, 110 00:06:01.959 --> 00:06:06.079 so bye by turning that on and off, like all 111 00:06:06.079 --> 00:06:07.439 of it on or all of it off. If you 112 00:06:07.480 --> 00:06:10.759 try it all on, all all of it off. I 113 00:06:10.759 --> 00:06:13.399 don't know what our costs that data dog would be, 114 00:06:13.519 --> 00:06:16.879 but I'd be willing that data dog would even say, hey, stop, uh, 115 00:06:17.439 --> 00:06:24.240 you're overloading us, right, But no, that's the big thing 116 00:06:24.319 --> 00:06:28.519 is like turning not the base layer on, it's all 117 00:06:28.519 --> 00:06:33.959 the other little things they're optional. And then what those 118 00:06:33.959 --> 00:06:37.199 optional traces are where the valuable data is though, Like 119 00:06:37.839 --> 00:06:39.920 it's the stuff that you can figure within your own 120 00:06:39.959 --> 00:06:43.399 application that gives you way more insight. It's like, hey, 121 00:06:43.399 --> 00:06:45.920 I want to put a trace around this certain method 122 00:06:46.240 --> 00:06:48.720 because I think it's slow. And then sometimes you do 123 00:06:48.800 --> 00:06:52.079 that and you're like, oh, that's fast. Where's the slum part? 124 00:06:52.480 --> 00:06:55.360 But if you put if you put that around enough thing, 125 00:06:55.680 --> 00:06:59.800 enough things, and we basically our main application, at least 126 00:06:59.839 --> 00:07:03.600 the ticketing inside of the application, we've we got the 127 00:07:03.639 --> 00:07:07.959 observability layer, like just it's covering almost everything. So if 128 00:07:08.040 --> 00:07:11.240 a certain customer starts to have slow response times, we 129 00:07:11.319 --> 00:07:13.639 just turn it on. Really, oh, we can focus on 130 00:07:13.759 --> 00:07:16.000 this part of the code and make the customer faster. 131 00:07:17.399 --> 00:07:18.839 I got you. That makes sense. 132 00:07:21.639 --> 00:07:24.319 But let's see what what am I doing now? Right now? 133 00:07:24.920 --> 00:07:27.000 I'm doing something that's not in my talk. It wasn't 134 00:07:27.079 --> 00:07:31.560 my talk, but it's also interesting. I think if you're 135 00:07:31.639 --> 00:07:33.959 a big company or you're a small company, you might go, well, 136 00:07:34.000 --> 00:07:38.560 why is that hard, And that would be we're changing 137 00:07:38.600 --> 00:07:42.399 the default scope for our main ticketing object. And the 138 00:07:42.480 --> 00:07:44.879 reason why we're doing that we're adding new columns to 139 00:07:46.000 --> 00:07:48.680 and it just seems like, okay, we just change the queries. 140 00:07:48.720 --> 00:07:51.199 Well you change every single query. You also have to 141 00:07:51.279 --> 00:07:53.480 change every index from out from under the hood, and 142 00:07:53.519 --> 00:07:58.439 you have to never have downtime and adding aex alone 143 00:07:58.920 --> 00:08:03.160 on our ticketing tables, they're just so huge. You can't 144 00:08:03.199 --> 00:08:08.040 just say, hey, DBAs add this. They'll say no to you. 145 00:08:08.879 --> 00:08:11.279 So you can lock that table for I don't know 146 00:08:11.319 --> 00:08:12.879 a few days exactly. 147 00:08:13.120 --> 00:08:17.000 You can't do. So it is a juggling act that 148 00:08:17.519 --> 00:08:19.560 luckily I don't have to deal with the DBA side 149 00:08:19.560 --> 00:08:22.839 of it. I don't know what the problems are. And essentially, 150 00:08:23.639 --> 00:08:26.680 when we move from a raw two to a RORA three, 151 00:08:27.160 --> 00:08:30.079 it did two things. First off, it made some problems bigger, 152 00:08:30.240 --> 00:08:33.519 so it made this a direction we needed to go. 153 00:08:34.000 --> 00:08:39.960 But also have you heard of invisible indices? No, So 154 00:08:40.000 --> 00:08:43.679 invisible indices is kind of what sounds like. Essentially, you 155 00:08:43.720 --> 00:08:46.120 have an index and a lot of times you're scared, 156 00:08:46.159 --> 00:08:49.759 too scared to delete any index because if you delete 157 00:08:49.759 --> 00:08:53.240 an index, it's gone and maybe you actually affected your application. 158 00:08:53.799 --> 00:08:57.039 So invisible basically says make it invisible. It's still there. 159 00:08:57.320 --> 00:09:00.799 The sequel is still populating that index to make it 160 00:09:00.840 --> 00:09:04.480 actually work, but you can see are there performance problems 161 00:09:04.480 --> 00:09:09.120 with it? So we have not deleted an index for 162 00:09:09.200 --> 00:09:11.600 fifteen years of our application, and now we're actually able 163 00:09:11.639 --> 00:09:13.919 to go in and say, hey, if we actually delete 164 00:09:13.960 --> 00:09:16.679 these induses, we can add new ones because we the 165 00:09:16.720 --> 00:09:21.759 memory profile won't blow up. So that is the the 166 00:09:23.000 --> 00:09:25.879 saving grace of allowing us to actually do this whole project. 167 00:09:26.120 --> 00:09:32.200 Without that, we'd be too scared because well, having things 168 00:09:32.320 --> 00:09:35.519 break is scary, a lout of money. 169 00:09:36.600 --> 00:09:37.799 So I'm curious. 170 00:09:39.200 --> 00:09:43.279 I mean, I've deleted indices off of databases that I've 171 00:09:43.279 --> 00:09:46.320 worked on, but i haven't done it on like very 172 00:09:46.360 --> 00:09:49.440 large tables. I've added into ses on very large tables 173 00:09:49.480 --> 00:09:56.080 and watched the thing go ah, But deleting them doesn't 174 00:09:56.120 --> 00:09:58.039 seem to have that same effect. So is there a 175 00:09:58.080 --> 00:10:01.639 downside to deleting them other than some queries that use 176 00:10:01.639 --> 00:10:03.120 those indicies might slow down. 177 00:10:03.480 --> 00:10:06.480 Right, and you don't know what, like like when your 178 00:10:06.559 --> 00:10:11.399 application is I think we have over I'm guessing to 179 00:10:11.440 --> 00:10:13.200 have over a thousand repos for example. 180 00:10:13.799 --> 00:10:14.120 Uh huh. 181 00:10:15.159 --> 00:10:21.120 You can't figure out whether you have beat down every 182 00:10:21.600 --> 00:10:24.639 location where every query that actually hits this. There's actually 183 00:10:25.240 --> 00:10:28.879 I had to go through every query in our main 184 00:10:29.480 --> 00:10:33.759 API and we separate our queries by the API queries, 185 00:10:33.799 --> 00:10:37.879 and we separate it by non API queries. Let's just 186 00:10:38.159 --> 00:10:41.799 that way. And the API queries is a manageable list 187 00:10:41.879 --> 00:10:44.519 of things that it's like a couple hundred queries to 188 00:10:44.679 --> 00:10:47.240 the ticketing table that actually happens. You can wrap your 189 00:10:47.240 --> 00:10:50.639 head around that. But the non to API queries, I 190 00:10:50.759 --> 00:10:54.720 think it was over forty thousand different unique queries. Oh wow, 191 00:10:55.039 --> 00:10:58.399 go through each query and say would this index work 192 00:10:58.440 --> 00:11:00.600 with this index work with no? No, no, no no. 193 00:11:01.600 --> 00:11:05.480 So so it is complex. 194 00:11:06.240 --> 00:11:07.679 So what's your approach to that then? 195 00:11:08.440 --> 00:11:13.120 Uh? So that luckily the things we care more about 196 00:11:13.159 --> 00:11:16.960 are the API queries, so we absolutely make sure that 197 00:11:16.960 --> 00:11:21.399 those actually are working, and the non API queries. We're 198 00:11:21.399 --> 00:11:24.399 actually moving a lot of that stuff to elastic search anyways. 199 00:11:25.200 --> 00:11:28.080 So our long term fix is actually all those things 200 00:11:28.080 --> 00:11:31.879 are never actually going to need a query. So, and 201 00:11:31.960 --> 00:11:34.519 I don't know how the magic of that works, Like, 202 00:11:35.039 --> 00:11:36.759 oh wow, you don't even need a query to get 203 00:11:36.759 --> 00:11:39.879 the data. That's awesome. Okay, I'm guessing somebody's looking at 204 00:11:39.960 --> 00:11:42.200 en logs or something like that and they're throwing that 205 00:11:42.360 --> 00:11:46.480 information rate from the bin logs into seql. But I 206 00:11:46.519 --> 00:11:49.159 have That's that's magic to me. 207 00:11:49.440 --> 00:11:52.919 So I used, do you have anything you want to 208 00:11:52.960 --> 00:11:53.519 jump in with? 209 00:11:54.840 --> 00:12:04.879 Uh, haven't seen your talk. Probably probably some stupid questions. Really, Uh, 210 00:12:05.960 --> 00:12:09.200 what kind of like where do you normally find performance 211 00:12:09.320 --> 00:12:13.000 bottlenecks in like apps? You see? Because I know you 212 00:12:13.200 --> 00:12:18.080 primarily are you're working for zenders, you've probably worked on 213 00:12:18.120 --> 00:12:20.320 that product for quite a while. But I'm a freelancer, 214 00:12:20.399 --> 00:12:21.679 So I look at I look at a lot of 215 00:12:21.679 --> 00:12:24.120 code bases, and what I see and it's all it's 216 00:12:24.159 --> 00:12:27.720 all rails. And what I see most of the time 217 00:12:27.840 --> 00:12:31.279 is people just haven't thought through the database design properly 218 00:12:31.960 --> 00:12:36.360 and they're doing all these funky joins or even worse, 219 00:12:36.519 --> 00:12:39.080 getting stuff out of the database and doing things in 220 00:12:39.159 --> 00:12:42.840 memory that you could quite easily do in the database. 221 00:12:43.000 --> 00:12:46.720 And it's like it's quite common mistakes like that is 222 00:12:46.759 --> 00:12:52.720 where I usually find performance bottlenecks. What's your experience in 223 00:12:52.759 --> 00:12:53.320 that regard. 224 00:12:53.759 --> 00:12:56.759 So the worst areas are where they add funky joints 225 00:12:56.840 --> 00:13:03.200 because sometimes you can't solve the is very easily. The 226 00:13:03.639 --> 00:13:06.960 talk was actually more focused on the coding aspect, like 227 00:13:07.080 --> 00:13:10.600 just simple things that people do that they should know 228 00:13:10.679 --> 00:13:14.919 about that they just don't do. So, for example, just 229 00:13:15.000 --> 00:13:19.840 memorization and a little different memorization techniques. And one of 230 00:13:19.919 --> 00:13:22.639 the cool things I brought up a zendes that we 231 00:13:22.679 --> 00:13:26.279 do is we have what I it's kind of like 232 00:13:26.279 --> 00:13:30.360 a singleton, but it's not. It's so our account object. 233 00:13:30.519 --> 00:13:32.519 If you get an account, it doesn't matter how you 234 00:13:32.559 --> 00:13:37.039 get that account. In the request cycle, you only need 235 00:13:37.080 --> 00:13:39.960 one account object. So if you call it tickets dot account, 236 00:13:40.080 --> 00:13:41.799 or if you call user dot account, or if you 237 00:13:41.840 --> 00:13:45.720 call just get me the account through this method called 238 00:13:45.799 --> 00:13:48.320 fetch account that we have, any way you get the account, 239 00:13:48.360 --> 00:13:51.360 it is the same exact object. So one of the 240 00:13:51.399 --> 00:13:53.360 cool things you can do based on that. So if 241 00:13:53.360 --> 00:13:57.759 you get the same object, if you memoize your whatever 242 00:13:57.759 --> 00:14:01.000 you're trying to memorize based on that one object, you 243 00:14:01.080 --> 00:14:07.679 can instead of actually have a request where hey listen, 244 00:14:07.720 --> 00:14:10.000 I'm going to memorize it on this object. But then 245 00:14:10.240 --> 00:14:12.960 someplace else in the application, your memoir. You want to 246 00:14:13.039 --> 00:14:15.039 use that, but you can't. You can't get to that 247 00:14:15.120 --> 00:14:18.840 original object. We can actually memorize it on this god object, 248 00:14:19.360 --> 00:14:22.919 and wherever we call that method again, it is memorized. 249 00:14:23.559 --> 00:14:27.120 So that was I thought, a really cool way of 250 00:14:27.360 --> 00:14:31.279 actually going about like memorizing something is having that god object, 251 00:14:31.519 --> 00:14:34.840 and then you don't have to worry about Okay, and 252 00:14:34.879 --> 00:14:37.720 the presenter we're calling it this way. In the controller 253 00:14:37.759 --> 00:14:39.360 we're calling it this way, and the models we're calling 254 00:14:39.440 --> 00:14:43.159 it this way. But we cannot tie those spaghetti pieces 255 00:14:43.159 --> 00:14:45.519 of code together. But because we have that god object, 256 00:14:45.639 --> 00:14:48.120 we can memorize it in one place and always access 257 00:14:48.200 --> 00:14:50.960 the same data throughout and then never have to worry 258 00:14:51.000 --> 00:14:53.720 about That was a cool thing that actually, well that 259 00:14:53.799 --> 00:14:54.519 was in the talk. 260 00:14:54.799 --> 00:14:57.279 But really, what are you use it for that or 261 00:14:57.360 --> 00:15:00.000 using current attributes or something else. 262 00:15:00.039 --> 00:15:03.039 Far as making it a god object. I wish I 263 00:15:03.120 --> 00:15:05.440 knew that was well before I came into But I 264 00:15:05.480 --> 00:15:09.639 think we're basically we created a method called fetch account 265 00:15:10.360 --> 00:15:15.080 and one we call fetch account outside there, and then 266 00:15:15.519 --> 00:15:22.120 in probably active record we override the account method an 267 00:15:22.159 --> 00:15:24.960 active record, not even every one of our models has 268 00:15:25.159 --> 00:15:28.120 an account method, so I'm guessing we override that and 269 00:15:28.200 --> 00:15:33.279 just memoize the account in the instant variable and it 270 00:15:33.279 --> 00:15:35.919 always goes back to that incident. That's just a guess. 271 00:15:36.759 --> 00:15:38.679 I've not actually looked at that code because I haven't 272 00:15:38.720 --> 00:15:41.320 needed to. And I was actually asked that at Rails World. 273 00:15:41.320 --> 00:15:44.559 I should actually really get into it, but the person 274 00:15:44.559 --> 00:15:47.840 who knows that best just left send us, so I'll 275 00:15:47.879 --> 00:15:51.320 have to dive into code instead of ask questions. 276 00:15:51.720 --> 00:15:54.799 Yeah, I thought current doctributes are probably a bit new. 277 00:15:55.720 --> 00:16:00.000 Came and five or something that we. 278 00:16:00.200 --> 00:16:03.559 Just upgraded to. Did we hit Rails eight yet seven? 279 00:16:04.360 --> 00:16:07.639 Either way? Like, it's so good to be closer to 280 00:16:07.759 --> 00:16:14.399 the edge. We're definitely on Rails seven for application. We're 281 00:16:14.399 --> 00:16:19.200 on Rails four for like six years or something like that. 282 00:16:19.279 --> 00:16:23.360 Who's so good to be closer to the edge. 283 00:16:25.039 --> 00:16:27.559 Yeah, I've experienced that too. For a long time, I 284 00:16:27.600 --> 00:16:31.960 was working on like Rails four five apps, and yeah, 285 00:16:32.080 --> 00:16:33.720 the last year or so, I've been able to work 286 00:16:33.759 --> 00:16:38.399 on Rail seven and Rails eight apps now. And what's 287 00:16:38.440 --> 00:16:40.320 fun is you get to go back now and figure 288 00:16:40.360 --> 00:16:42.480 out all the stuff that's been added in since. So, 289 00:16:43.159 --> 00:16:45.519 you know, I got into like stimulus and Turbo, and 290 00:16:45.559 --> 00:16:48.600 then figured out that oh look, Turbo actually will work 291 00:16:48.639 --> 00:16:54.440 through your what's it action cable channels and so you 292 00:16:54.480 --> 00:16:57.559 can you can push updates when you have sort of 293 00:16:57.600 --> 00:17:01.679 out of band anyway, just all this stuff that it's like, okay, 294 00:17:01.799 --> 00:17:04.759 I don't now need a full cycle to get this 295 00:17:05.319 --> 00:17:06.319 these features to work. 296 00:17:06.680 --> 00:17:08.599 So, being at a bigger company and we started on 297 00:17:08.759 --> 00:17:13.160 Rails one or something like that, upgrading through there's obviously 298 00:17:13.240 --> 00:17:17.440 monkey patches like throughout the years because well rails didn't 299 00:17:17.440 --> 00:17:19.759 have certain things and now they do, and now taking 300 00:17:19.759 --> 00:17:23.200 those monkey patches away is hard, which also means that 301 00:17:23.599 --> 00:17:27.119 really adding the newest features of Rails is hard, in 302 00:17:27.160 --> 00:17:30.359 fact almost impossible. But what we can do is like, 303 00:17:30.599 --> 00:17:33.880 for example, is like, yeah, this week we upgraded to 304 00:17:34.079 --> 00:17:35.799 Rails three to three, and all of a sudden, the 305 00:17:35.799 --> 00:17:38.519 performance got a lot better. But also, like let's say. 306 00:17:38.359 --> 00:17:42.039 In Ruby three yeah, or Ruby three three. 307 00:17:41.839 --> 00:17:43.960 Sorry, Rails three three yeah. 308 00:17:44.119 --> 00:17:46.680 I do remember upgrading to Rails three three back in 309 00:17:46.720 --> 00:17:47.440 the day, but. 310 00:17:47.839 --> 00:17:50.839 I remember upgrading the Rails three from two. That was hard. 311 00:17:50.960 --> 00:17:52.839 But that was brutal. That was brutal. 312 00:17:53.400 --> 00:17:54.519 That was the mob. 313 00:17:55.480 --> 00:18:02.720 Yeah, it was yeah, it is the herb Any long before. 314 00:18:03.279 --> 00:18:04.640 I don't have those, cause. 315 00:18:05.359 --> 00:18:06.799 Oh I haven't. 316 00:18:07.119 --> 00:18:09.480 Who'da did a ton of work on that? Yeah, it 317 00:18:09.519 --> 00:18:11.359 was it was brutal. 318 00:18:12.799 --> 00:18:15.119 But uh, where was I going with this? Oh? I 319 00:18:15.200 --> 00:18:17.880 forgot my train of thought. 320 00:18:18.400 --> 00:18:19.839 Upgraded to Ruby three. 321 00:18:20.599 --> 00:18:24.599 Upgraded Ruby three. I don't think I'm going to remember 322 00:18:24.599 --> 00:18:29.079 what I was thinking about. Oh, and like, for example, 323 00:18:29.119 --> 00:18:33.480 with Ruby three, Uh, we had in our application. We 324 00:18:33.480 --> 00:18:37.119 were very scared because we allowed, we had and still 325 00:18:37.279 --> 00:18:41.599 do allow customers to add their own rej axes. Well, 326 00:18:41.599 --> 00:18:43.880 if you had your own rejects, you can really slow 327 00:18:43.960 --> 00:18:48.079 down and stop you're you can just kill an application 328 00:18:48.160 --> 00:18:50.880 if you allowed the end users. So we had some 329 00:18:51.000 --> 00:18:53.720 weird way of actually making it so they couldn't just 330 00:18:53.839 --> 00:18:57.720 kill our system. But it spun up a process, and 331 00:18:57.720 --> 00:19:00.559 that's spinning up a process took about a half second second. 332 00:19:00.880 --> 00:19:04.200 Let's just say to actually spin up so it would run, 333 00:19:04.319 --> 00:19:08.000 and it make sure that rejects would never actually just 334 00:19:08.119 --> 00:19:11.079 be infinitely running. It would time it out at a 335 00:19:11.119 --> 00:19:16.039 certain point. But doing that was well added a half 336 00:19:16.119 --> 00:19:20.599 second every request. For example, Ruby three allows you to 337 00:19:20.640 --> 00:19:25.960 actually by default have a timeout in your rejexes. So 338 00:19:26.039 --> 00:19:28.880 now were in that extra process up. So now if 339 00:19:28.880 --> 00:19:33.440 you're all most cases you're just running in rejects, that 340 00:19:33.519 --> 00:19:38.079 takes a millisecond or two. Those other cases that actually 341 00:19:38.160 --> 00:19:42.799 do time out, those do time out just by default. 342 00:19:42.839 --> 00:19:44.759 With Ruby, we didn't have to actually do this weird 343 00:19:44.880 --> 00:19:48.680 fancy trick to actually make it happen. So that was 344 00:19:48.720 --> 00:19:53.039 actually a very very big upgrade for us because we've 345 00:19:53.079 --> 00:19:56.559 had those rejects, allowed people to put rejects's in forever, 346 00:19:56.599 --> 00:19:59.480 and we've had to protect against it forever, and that's 347 00:19:59.599 --> 00:20:05.000 just just bad. I think I would have if I 348 00:20:05.039 --> 00:20:07.160 was around way back then, it probably was like, no, 349 00:20:07.319 --> 00:20:09.880 don't let them put their own rejectses and give them 350 00:20:09.960 --> 00:20:11.920 an array of things that they can do. Don't give 351 00:20:11.960 --> 00:20:19.759 them an infinite array, right yeah, but but yeah, of 352 00:20:19.839 --> 00:20:25.240 our upgrades, it is just like looking at the code 353 00:20:25.279 --> 00:20:32.200 that's old, and people don't when it is an application 354 00:20:32.279 --> 00:20:35.960 is as big as it is. People cannot wrap their 355 00:20:36.000 --> 00:20:40.240 head around the whole ticket, save request of the cycles. 356 00:20:40.279 --> 00:20:44.680 Because we have everything gets into the ticket, there's triggers, 357 00:20:44.759 --> 00:20:50.359 there's not just every layer, and essentially people can't wrap 358 00:20:50.359 --> 00:20:52.400 their head around that. So once you put traces around this, 359 00:20:52.720 --> 00:20:58.039 you find blatant like obvious mistakes and you just tackle 360 00:20:58.079 --> 00:20:59.599 them one at a time, and most of the time 361 00:20:59.680 --> 00:21:04.400 it's coding mistakes. It's not and it's not even a mistake. 362 00:21:05.039 --> 00:21:07.079 It was I got to get this feature out fast. 363 00:21:07.240 --> 00:21:09.240 People don't think about performance when you have to get 364 00:21:09.240 --> 00:21:15.480 it out within a week. Right. But it's been good, actually, 365 00:21:15.640 --> 00:21:18.519 like the amount that we've saved and the ticket cycle 366 00:21:18.640 --> 00:21:22.000 and just not even ticket now we're actually since we 367 00:21:22.119 --> 00:21:24.319 did such a good job, we've been given more and 368 00:21:24.359 --> 00:21:27.200 more freedom to actually work in random areas of the code, 369 00:21:27.240 --> 00:21:31.240 and just the amount of improvements that we've made. You 370 00:21:31.279 --> 00:21:37.640 don't think of little coding things like, for example, scopes 371 00:21:37.759 --> 00:21:44.200 versus conditional associations, like a scope. Every time you call 372 00:21:44.240 --> 00:21:47.480 a scope, Rails makes the query. If you have a 373 00:21:47.480 --> 00:21:51.279 conditional association, it makes a query and Rails by default 374 00:21:51.680 --> 00:21:57.759 has that query cashed up. Just making that switch will 375 00:21:58.160 --> 00:22:01.720 reduce the number of queries, and sometimes queries aren't very free, 376 00:22:01.759 --> 00:22:04.160 so all of a sudden, you've just saved time. There 377 00:22:05.279 --> 00:22:10.079 so many N plus one queries where that so? 378 00:22:10.079 --> 00:22:13.279 So were you advocating for scopes or for. 379 00:22:15.279 --> 00:22:20.079 Both? Most of the time conditional queries when when when 380 00:22:20.119 --> 00:22:23.200 you're trying to like tweak the last bit of performance. 381 00:22:24.079 --> 00:22:29.720 I would be advocating for conditional association. Okay, scopes are 382 00:22:29.720 --> 00:22:33.160 not evil, it's just sometimes people don't realize. You know, 383 00:22:33.319 --> 00:22:37.119 I'm using this in the scope within a loop for example. 384 00:22:38.000 --> 00:22:39.359 Uh huh, And. 385 00:22:39.279 --> 00:22:42.599 All of a sudden, I'm getting like like just query 386 00:22:42.640 --> 00:22:44.480 after query after query, where if you don't put it 387 00:22:44.519 --> 00:22:46.759 in a loop, and you if you use a conditional association, 388 00:22:47.240 --> 00:22:49.680 that loop makes one query and you're you're. 389 00:22:49.559 --> 00:22:53.319 Done right, So it automatically eliminates the N plus one query. 390 00:22:53.359 --> 00:22:59.000 Is what you're saying, Yeah, well, yes, yes, but N 391 00:22:59.039 --> 00:23:01.400 plus one query. I always think of n plus one 392 00:23:01.480 --> 00:23:03.799 queriers is the things that you can add just includes 393 00:23:03.839 --> 00:23:06.799 in and it just goes away. Yeah generally, yeah, but 394 00:23:06.880 --> 00:23:09.119 this is an N plus one query that generates itself 395 00:23:09.200 --> 00:23:09.759 a different way. 396 00:23:10.640 --> 00:23:14.759 Yeah, if it was to do like some if I've 397 00:23:15.000 --> 00:23:16.799 just built like a new feature and I just want 398 00:23:16.839 --> 00:23:21.839 to reassure myself that I haven't made any stupid performance 399 00:23:21.880 --> 00:23:26.200 mistakes or or anything like that. Like because again, like 400 00:23:26.400 --> 00:23:29.240 with the work I do, it tends to perform, Like 401 00:23:29.400 --> 00:23:31.960