Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
- Good morning, everyone. I hope you enjoyed what just happened before this. (chuckles) Today we're gonna talk about how to performance. This talk is going to focus on tools and techniques to help speed up your Ruby code. The things we're gonna talk about today came out of work that I did with Aaron to speed up integration tests in Rails.
I'm Eileen Uchitelle, and I'm a programmer at Basecamp, formerly known as 37signals. I'm on the security and performance team, so I make sure things run fast and safely, and you can find me anywhere online at eileencodes. I'm also on the Rails committers team which means I'm allowed to push directly to master, and on the Rails security team.
I'm not on Rails Core, which seems to mean I'm not allowed to Tweet from the Rails Twitter account, and I'm not sure if that makes you feel more or less secure. This is my dog Arya. She is of course named after Arya Stark from Game of Thrones. She has her own Twitter account, @aryadog, and she would love it if you followed her.
Be warned, though, she likes to talk about poop a lot. I'm from upstate New York, from a city called Kingston. It was the first capital of New York in 1777, but then the British burned it down twice. And so they moved the capital to Albany, because we couldn't be trusted with it.
Where's my British? I'm really happy to be speaking at RubyConf this year. Not only is this my first time speaking at RubyConf, this is my first RubyConf ever. I always like to mention something that I find interesting about the city that I'm currently speaking in, and since this is my first time in San Antonio, I think it's really interesting that you have this Riverwalk thing, where you have a really, really narrow walkway, with a river in the middle, and you have to cross bridges to get to the other side to go to the restaurants you actually want to go to.
Do you people fall in a lot? - [Voiceover] Woo! - [Voiceover] 500 a year, I heard. - That's crazy. So perhaps you're wondering why we wanted to make integration tests faster, other than the obvious, faster is better. And why I'm giving this talk. While integration tests and controller tests both processor out and make assertions about the response, they are two completely separate code bases in Rails.
We figured that if we make integration tests as fast as controller tests, then we can just combine the two code bases. If we didn't speed up first, everybody would notice their test speed got suddenly got slower in Rails 5 and then they would complain to me.
This has the added bonus of when we consolidated the code bases, nobody has to change their code. There's no deprecation notice, you can just continue writing tests as you were, but for us, it's faster. The purpose of this talk is to show you the techniques and tools that Aaron and I used to speed up integration tests.
We're going to go over what worked and what didn't, and ultimately how successful we were. Before we can talk about speeding up integration tests, we first need to go over the difference between benchmarking and profiling. Benchmarking measures how slow our code is.
This is all about collecting data on where your code currently stands. Benchmarking tools are also instrumental in proving we made our code faster. We can use benchmarking tools to measure our code before and after we make changes so that we can be sure that we've improved the speed.
Profiling tells us what parts of our code are slow. We can use profiling to pinpoint the exact methods that are slowing down our code. Improving performance is a lot harder, if not impossible, if you don't use these two tools together. Let's get started. So back in January, David said to me, Hey, I like fast things like race cars.
And I really, really hate it when things are slow. I want to move Basecamp's controller tests to integration tests, but right now they're 20 to 40% slower than controller tests, and that's just not going to do. Can you see what you can do about speeding up integration tests in Rails so they're as fast as race cars? Of course I said yes, because this was a good opportunity, good opportunity to improve Rails for everyone.
So if we're going improve performance, what's the first thing we need to do? We need to get a baseline. This gives us something to measure against so we know we're actually improving the speed of our code, instead of just thinking or hoping we are. To get a good baseline, I decided that it would be a lot easier to not change Basecamp code, and rather build an application specifically for testing the speed of integration tests.
Building a new application has many benefits. It's public on GitHub, so you can see all the different kinds of test I wrote to measure the integration test performance, and two, it removes anything that can be getting in the way of helping me build a solid baseline, like log in code, and all that other stuff, because that's part of your application, not part of the integration test code.
Of course hello world examples won't show me where all of the slowdown is, but you need to start with the bare minimum, and build up from there to find the underlying issues. Controller tests and integration tests don't look that different. They both define a test, process or route, and assert something about the response.
Here, the index tests for both are getting the index route and asserting the response was a 200. That's it. To build a baseline, I started with Ruby 2. 1. 5 and Rails 4. 2. 0, because that's what Basecamp was using at the time. I wanted to be sure that integration tests were slow in isolation, using the same technology as Basecamp.
First I double-checked that David's assertion that the integration tests were 20 to 40% slower than controller tests was true. He was basing this off the time that it took to execute, so I first looked at that, knowing that wasn't going to be my real baseline.
I ran the single controller test that we looked at earlier, and found that it showed 1. 625 seconds of real time. I ran the corresponding integration test, and it took 2. 12 seconds of real time. This calculated to integration test being 23% slower than controller tests.
That's actually a huge difference. It would make running your entire test suite on integration test only, quite a bit slower. I then decided to run each of those tests five more times, and got some interesting results. The time a single test took to run varied a lot, and after a few runs, it appeared that there was no difference in speed between controller tests and integration tests.
[ ... ]
Nota: se han omitido las otras 3.160 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.