 I'm invited to this conference which is called Ruby Midwest. I am Australian so I now live in San Francisco so I looked at the map and thought, this is going to be awesome. Yes! Yes, I'm coming. Ruby Midwest. Of course. That's just up the road. That would be sweet. I'm sick of tired of travelling from country to country and I got that wrong so I thought okay, so how do I do this Midwest business? This is the middle of the West. I was pretty lost by now. In my agile fashion of what's next I looked briefly at the invite and I said I was in Kansas. That was Kansas City in Missouri. Sorry. It's taken me a while to get here. So at some point I had to ask the question how this possibly is called the Midwest. So for me it's been an actual safari. You're already thinking there can't possibly be more men's in this. Oh yes there can. That's how. Conference and it's now 2011 so unlike a lot of us when we first went Ruby we all came to the first RailsConf and it was like who's making money from Ruby and Rails and there's very few people but now we all do and as projects they have money, we have to make decisions, we have to spend that money. You might never think of it like that but trust me your boss does and your boss is thinking in this fashion he's thinking I could spend the money on features or I could spend it on the other aspect of the performance aspects. You want to add resources. You want to get more performance. You want your app to hum. You can press in app cloud the add button which is a tremendous button and when you do that it costs you money. My manager's not too thrilled to make that very distinct association. I press it some more times and it costs you more money. Just in case you're wondering. Nonetheless so you've probably wondered well this is how I think. There's still a university student in me that wants free beer and certainly free internet and free performance so I was always very interested to have it here through as much little money as possible I could get good performance. This is kind of in the back of my mind constantly and so I work in engineer now and a lot of people have been doing the event machine, doing other things and performance and threading or whatever so I was getting a little bit sick and tired of all these random conversations on Twitter that are interesting to follow that's sort of hard to get to the guts of. So what I did was I organised a very last minute EM RubyConf which could have been called concurrencyconf and it was sort of the back end of Braille's Conf and it was really good. We flew some people in. We had some people do some videos, prepared videos that they gave us and I think they had a packed room of 50 or something people. So I've learned all these things and I went and read some research papers. There's a way to spend some quality time. And I thought it's unfair if I do all this and I don't tell you about it and I thought well I could do this one in two ways. I can tell it in such a way that I come out very clever or I can do it in such a way that I come out very funny and no more importantly or I could give you just the answer. Like you're here writing Ruby, it's great. What's the one thing I could do? What's the 50 things you could do under 50 different edge case circumstances? What's the one thing you could do? And so I want to give you the one thing. So we talked about angry resources and whilst that's a thing you could do, let's see what else we can do. And so the goal for me, I just want to write code. I don't want to be thinking. Like I love James's talk because you just have one pattern for things. I try to have APIs that don't ship nils, wrap up things that might ship nils such that they never ship nils and you never have to think about it. You're just trying to lower the cost of thinking and all I want to think about is my application. So I'm going to give you a solution, a plan. How to think about this stuff. Should I use a vented? Should I use threads? And how's my code fit in that? And here it is! And if you forget to write this down, I will show it about a half a dozen times more. Keep an eye out for it. Now you think, well that's great. What does that mean? Well here is the thing you should do next example. Like this is the money shot. I think that's rude actually. There's a better way of saying that. This is what you pay money for. You know, it's great. You pay some money to come to this conference. Personally I think this is worth. If you have not done doing this, I mean think about how much money you spend running web apps specifically. A lot of people want to talk about it as web app focus because you get an interesting side effect when it comes to threaded. But you're probably spending lots of money. You do this, you spend less money, you're paid for the conference, and everyone else is free. Not that they weren't valuable. That's been really, really good. I've actually thoroughly enjoyed this conference. Alright, so what is a vented? A vented is where you arrange IO. Now I would like to say orchestrate IO. But there's a cost to that. And these guys have to have a smaller font. And I'd rather have a bigger font than spend 30 seconds explaining it. I want to, threads is where you're going to do actual work. It has an interesting premise. What that means is in a vented you can't do work. So, if you're building any vented apps whether in Ruby or that other thing that's very popular, you can't do work. And we'll talk about why. And what you want to do is write code. So here is the solution, just in case you forgot to write the notes down. Here is the bits and pieces you're going to use for your app. And you're going to write code at the bottom. So you want to use resources better. Let's talk about concurrency. This is how we're going to get all these resource utilization. Now you might think, why would I, why do I get an engineer? I sell memory for a living. I mean, CPU, memory. That's the charge for it. It's good. Good business. You should do it. And specifically with me, not in competition, that we don't have fun at all. So let's see how we can use our resources better. Let's compare the two that are sort of similar. And certainly in Ruby space, we've all gone down the top one and we've not investigated, spent a lot of time convincing ourselves about the second one. So let's talk about process concurrency. If you want to have one requested at a time, that's going to take one process and it rails that much in between 50 and 150 meg. Memory is cheap until you have a need to scale up. Actually, I was really good to the other day that sort of choked around this. What was it? Memory is cheap until you double it every week. That's it. Sorry, 100 requests. Yeah. What do you think out loud? All right. How do we, concurrency is orchestrated by the kernel, a couple of example, abstracts, unicorn, passenger, a mongrel cluster is an example of how you get concurrency there. A thread of concurrency, which you might never have done. You get 100 requests as one thread. Now, how much overhead there is a thread? I just need a number. You might say, well, it's probably 250k, but you just don't get a lot of reuses. It's a number that's substantially smaller in the reality. So 100 requests is still just the cost of one process. That's pretty cool. What that means is that you're bound not by memory anymore, really. You understand this? You're bound by something else, like CPU. So now you get to grow a lot and use your CPUs a lot better. All right. We'll come back to mongrel. So summary. One request is cheap. Take notes. I'm just going to follow the logic. Very simple logic. Just a lot of hand gestures. And here is a very dodgy image that I took from Google Images. When you search for winner, I guess I can't remember now, but it looks really cheap and nasty. I thought I'll do it. So that's why threads. That's why threads in serif process, because you get the code reuse and all that sort of stuff is now not duplicating in memory footprint. You get to be bound by something else. Now, educational lesson. Anyone speak sign language? What's that stand for? WTF. WTF. But in code. It's not rude. What's interesting about this is that if you're going to swear, you need a friend. That's got three fingers. I've got two fingers. I don't know how deaf people can do what they do with only two hands. Anyway. So, we talked about mentioned mongrel. And who still runs an app under mongrel? One. Okay. So two. So it's not worthy why I didn't mention it. Let alone. Talk about concurrency. But I have something interesting to show you. Code. There. Proof. So anyway. So anyway. If you don't use it, what's the point? We'll come back to it. Here is Dr. Nick's guide to is something thread concurrent potential? Business. Okay. So it is a better name. And the premise is, if everything's thread safe or has threading enabled, I just have a graph and a lot of others that I took from somewhere, and it says thread safe, you get the gist. Has threading available. But in 2006 when Rails came out, it was not thread safe because it just wasn't important. Like what's the point? Because Ruby is not thread safe. Or it doesn't have threads. So let's explore what happened over the last five years. In 2008, Rails 2.2 came out and it was the first thread safe Rails ever. Hooray! No one used it for that. Which is a bit sad. And we'll talk about how you use it for. Ever since 2008, is you add this somewhere. Anyproduction.rb in your environment. You do that, you go thread. Booyah! Budget time. You know, just ask for a raise. Look how much money I saved. Now if you're in Sinatra and you're going to need to write this down, you need to add this line somewhere. The hash. Very important. The error message. Not very relevant. So again, close. Rails and thread safe. Sinatra, over all, we're good. So let's look at Ruby's. 186 wasn't, 187 wasn't. 192 came out last year. It's got 19 friends. Woohoo! Yeah! I don't need to have this talk. Problem is, a sad face can be run Ruby once at a time. Which is an interesting interpretation of native threads. And the special mechanism that they achieved this tremendous feature is called the gill. And it has a sad face. It's part of its... And I like to call it the grumpy gill. So sadly, even in 2010, and as of 2011 with 193, it just came out, it's exactly the same. Just not worth another slide. So here we are. Threaded, thread safe, but no threads. Sad face. So you might think, well, what's the point? Okay, we had this conversation. Do we move on to invented now? Is this why everyone's excited about invented? No. People are excited about invented for other reasons. So threads. We have them. In fact, Mac Ruby also has gillers and has threads. So how many people run Mac Ruby in production? I don't... But these two. So how do you get J Ruby? That's pretty simple. And in fact, as of Rails 3.1, if you're in J Ruby at the time you run Rails in my app, it will come ready to run in J Ruby for the first time. And what that means is that your gem file has this sort of thing in it. So they're the sort of bare basics that you need. And if you pick a different database adapter, it'll change to be appropriate. So that's very cool. Most super cool, as you can probably guess, my enthusiasm by now, is that we're all green. And I think maths of concurrency say that we can use 3 concurrency, which gives us this, which means you save money and you get the pay raise that I was suggesting. And if you don't get the pay raise, you just come to me and we'll figure something out. I have no idea what that skin's going to look like. It's going to be dodgy. So how do I use J Ruby in Rails? I think called Trinidad. This is what we use in production. And the reason we use it in production is because it's really good in development mode, because it has a little command line out and pretty much it looks like every other. Because J Ruby isn't about Java. It's about a Ruby implementation, which, and this is just a secret. If you use J Ruby, and you might not care, it's a feature. You can use it. You can not use it. It's just an option. If you want, you can use some Java code. Now, I don't want to make you. But it's purely an option. By default, it's disabled. So J Ruby is about running Ruby. Hence, four of the five letters in the name are the word Ruby. An example app. That's just the one we put up an app card to run. And it has J Ruby sort of enabled. So if you're running J Ruby, that works. By default, so if you run in development mode, for example, if you have the thread-safe thing coming out, it uses essentially when it pulls it to when it's basically a wrap-around Tomcat. Tomcat has five J Ruby runtimes. That's your process concurrency. Put on thread-safe mode. Booyah! One J Ruby and threads. And that was it. Hard days done. Time for the bug. No, we're not here because you'd, you know, it's all shut. In Kansas City, if you wanted a coffee, for example, you have to go to Monday. So we get that. So it's all just normal app code you're writing. You know, none of that's the mysteriousness of threading and thread safety because it's a web app. So let's talk about that. You're saying I'm scared of threads. Okay, you're not going to say that out loud. You're going to say something silly like I don't like Java. Whatever. But see, web apps are sort of implicitly thread safe. And so what I've written for you is a mixed-dweb concurrency. A very picturesque vulgarity of our concurrency. But the summary is you store states somewhere else unless it's safe. And that's pretty much that. If you do that, then you're thread safe. And web apps you do. You don't leave data lying around for the next request to come through. Stateless. You put in no database. You're done already. No reason for that. Another hard day's work. Come on through the pub. You're thinking, so the next question you might ask, well, what about all my libraries? Good question. So you're going to Rails plugins and click on the little thread safety button. There are libraries that declare themselves thread safe. Easy peasy. That was fun. Let's move on. All right. So with that, you're going to use Trinidad and... But in the back of your mind, you've opted to come to this session. You can do something else, I don't know. And you've got to hear about Event Machine. Event is a cool thread or not. And I haven't even heard of that thing once. Let's talk about this. So what is Evented? Evented is basically it's a loop. You've heard of loops. And it loops over things that might be... might have some IOs. It says, do you have any IO? And if you do, it does something with it. That's the point. And I remember... And I decided for the sake of brevity to rip out every other slide about Evented. That's just not that relevant. I mean, the point of this talk is that if you're asking the question, Evented versus Threaded, I answered it. And I'm not going to justify why. You have work to do. You wrote a web app. So let's talk about one of the real cases in a web app where you're going to be doing sort of IO bound things. The request comes in and might be like a page cache or some sort of contact cache files, etc. You ask the question, if it's a miss, go to the web app. If it hits, well, let's move this to make this IO work. Okay? So it's outside our app. You may have seen this pattern before. I didn't make it up. I just put it on a pretty slide. This is Evented work. Our real work is inside our threads. And we're going to do this with a thing called EngineX. It's pretty cool. Who uses EngineX? Who knows how to configure it? That's the implicit part. You know, if you're going to use it, it's great and it's great for many reasons. There's a graph of goodness. The show is known as less memory users. As you get closer to currency. Sorry, that was a request per second. This one is a supply line memory, which is one of the great benefits of Evented Things. But when you start to think Evented versus Threaded, you're talking about optimization questions. And I challenge you that most aren't going to be solved with Evented. They're going to be solved with threads. And if you do have some other stuff, pull it out in the front, or pull it out in the separate parts. So, because I need to give you one point. Who doesn't have so much time? And I'd rather tell funny jokes. So, you put Evented stuff in the front, threads, and then you're out. You want to get this, obviously, amongst other places. Us, if you want a job, we can come work with awesomeness. And me. To greatly distinct groups. You should. And to the goal, as always. I want you to be happy. Because I assume you're a lot like me. And you start with happiness. There's a sad world. People occupying things. If I could be in suicide without leaving a note, I'm just going to stand over here. Why? You wouldn't understand. The first time I got to tell someone else a joke. That's worth it. There's an Irish comedian, Ed Byrne, and he has this bit about... So, you're seeing your girlfriend and your wife, and you're watching TV, and you just say something stupid. Something that only a man would say, like, yes, that's right. Women should be locked up in the kitchen. They should be brought out like that. And then she... You know, all of a sudden, changes. But you don't know why. Because she's looking at you differently. The vibe is different. And you say to her, what's wrong? What happened? What's going on? And she says, and sing it with me, if you don't know what you've done, there's no point in me telling you. What's so logic as that? And there's a lot like saying, if you're hungry, there's no point in me making any dinner. It's the same logic. So, yeah, so there's occupied people. I'm sure they're doing it all for the right reason. Where it happens to be. So, your code wraps up in threads. Your code is normal code doing normal things. You know, threads say fashion, which is implicit. Put any event yourself in the front, and there's some things I think you should use. This is what we put in production. We support it as an example of why I think. There are other options. And if I'd realized, like, if at the time, there's a thing we're building, well, sorry, there's a thing, a group of people are building, that's some of them, a group of media's team, called Puma, pronounced Puma, or however else you pronounce it. And I don't know in America. I'm not sure the right way is anymore. I love the queen. God bless the queen. And for what it is, essentially, it's a fork of mongrel. So mongrel, that threaded thing, mongrel hasn't been touched since mid-last year. But as a code base, it's a great place to start. So basically, they've pulled it out of the dustbin, given it a new name, coded paint, fixed it, changed the readme, and making it work as a multi-threaded app stack. Which we've never needed before, because we've never had a multi-threaded normal Ruby, than how we do with it. So they're building that. And I think they're going to put some other cool stuff in it, that sort of invented business. So this is it. So if you wondered what the point was, and it alluded to you because of my subtlety, this is the last slide. I have one more slide, because I felt that you deserved it. It's a long conference, and I felt you needed one more cow. Thank you very much. I'm taking a lot of room for questions. I don't want any. It's a thread thing. What would you like to talk about? I think it's awesome. We should use them more often. Does anyone remember? Sorry, go ahead. The standard comedy class took years back to help you with your presentation. So, yeah, not the topic. So I tried. It's hard to say how funny it is. There's nothing harder than standing up and having no point to being there, except tell jokes. Like, everything you say may as well be funny, or you may as well not say it. And at the same time, your audience is looking at you going, ha-ha, make me laugh. You don't have those same high expectations. That's a lot easier. All right, you guys are chance. Thank you very much.