Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
- So, my first Ruby Conf was Ruby Conf in San Francisco in 2009 and the closing talk of that conference was this monstrosity by Erin Patterson and Ryan Davis. And if you haven't seen this talk, you should really go find it on Con Freaks, it is a great way to spend half an hour, 45 minutes, because in this talk, Ryan and Erin cover all of the crazy ideas that they came up with while riding the bus home from the Ruby class they were teaching in downtown Seattle.
- [Voiceover] The fail bus. - The fail bus, yeah, we rebranded that bus the fail bus. And they share a whole bunch of perfectly reasonable code for perfectly unreasonable problems. And back in 2009 I was working at a startup and my code was running on something that looked approximately like this.
And now my code runs in someplace that looks like this. So, I was trying to figure out what talk to propose for this conference and I thought, I was sitting on the bus, fail bus, and I'm like, I should totally do another version of this talk. So, I'm Aja Hammerly, the code for this talk is on Github, I'm "thagomizer", and it's in the stupid ideas repo.
I Tweet, @thagomizer_rb and my phone is over there, so you should totally Tweet at me during the talk because I love it when people do that and you won't distract me. And I blog at thagomizer. com, and I used to be, I blog very rarely at thagomizer. com, but now I'm paid to blog at thagomizer.
com, so I blog there more often. I work for Google Cloud Platform, I'm a developer advocate and we do let you run Ruby on our cloud, oddly enough. So, cloud. google. com/ruby. I'm gonna be running office hours tomorrow during the afternoon break, down on level two.
And if you have questions about running your code on Google Cloud or you just wanna know about Google Cloud, you can come talk to me. And because I work at a large company, unless otherwise stated, all code in this talk is copyright Google and licensed to Apache V2, because lawyers.
So, now that all that's out of the way, time to get on with the stupid. First idea, load testing. So, the code in this section pre-dates my time at Google and it pre-dates my time coming to Ruby Conferences, cause it's really old, but that means that it's my copyright and it's licensed to MIT.
And I wanna be real clear, this is really stupid load testing. I started my career in QA and as part of QA at a small company, and my boss would come and say, "hey, can you load test this new feature?" and I would say, "okay, great, what parameters are you looking for? What's the ideal load you want this to have? What kind of specs should I run it against?" and they're like, "load test it, just do the load testing thing.
" And so, my response to that was to take my relatively limited set of skills at that point and come up with something incredibly stupid. So, I had a rails log of the scenario I wanted to run and it was from my local server and I had a mechanize and it turns out with those two peices and not a lot of forethought, you can make a perfectly reasonable load testing framework.
So, why mechanize? Because it let me write out a script of code that was then going to run and I could inject user IDs or association IDs into that script, so I wasn't re-running the exact same scenario for my log over and over again. Also mechanize is actually pretty small and so if I needed to load a bunch of code onto a bunch of load generating machines, it was pretty easy to do that.
So, the big challenge of load testing is to make a whole bunch of computers do the same thing at the same time, pointed at the same server, and if you can do that, you have load testing. There's an analysis piece, but we're gonna ignore that for now, cause this is stupid ideas for too many computers.
So, what's the code look like for this? Well, let's be clear, it's not good. In fact, this is some of the oldest Ruby code that I've written that I haven't deleted yet. And by it not being good, I really mean that, I knew I had this code sitting around when I proposed the talk, and I went to go pull it up to put it on the slides, and this was the first line that I saw.
So, yeah, really truly the first line of that file. So, here's the code, you're probably not gonna be able to see it, it's okay, there's not much here. That's just some preamble to get the mechanize agent started up. That's me looping through the log file and matching against that horrible REG EX, and all that horrible REG EX does is pull out the action, the controllers, and the parameters from the rails log.
And then that right there is writing out the code that will make Mechanize do a post to the server based on what the action on the controller were. It happened to be that the project I was doing this for only had two primary actions for an entire application, like 99 percent of our traffic went through those two, so I just switched, there's a case statement there I think, or an IF, but it's pretty flexible.
You have the action, you have the controller, you have the parameters, so you could totally throw that stuff in for whatever your rails app is. So that's great, now I can programmatically run the website but that's still not load. How do you turn that into load? Well, parallelism, you take your script, you do it on a bunch of computers at once for a very long time.
Turns out very long time is actually pretty easy, you just put that around your script. So, I've used this technique more times than I really want to admit, such is the life of a QA engineer. You have a tool, you have a problem to solve and you're always going to be running on the last minute, this works great.
[ ... ]
Nota: se han omitido las otras 2.759 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.