[00:00:00] Mark Tomlinson: So one of the starting questions is why do you want to explore performance? And the biggest thing I can tell you is that if you're on your happy little iPhone device, some kind of mobile device doesn't matter what it is. And you're connected out here into the cloud, across the Internet. And there's of course, there's probably some sort of little Wi-Fi tower, you know, with signals that RF transactions are happening. The why you want to explore performance is that let's say I'm over here and I'm happily using my device. But at the same time, there's an earthquake about to happen underneath my feet. And I need to finish my transaction online and then I need to run to safety really quickly. Right. I only have a few minutes to get my transaction done. And so if this app is too slow and I can't run out of the way, then I will die here in a terrible death, in an earthquake. This is probably very relevant for anyone on the West Coast or in an earthquake. Ring of fire around the Pacific Rim, which I think is very interesting. [00:01:01][61.6]
[00:01:02] But all of this transaction maybe goes back here into a Web server, another couple of app servers, a third party call. Maybe there's a database back over here at the end of all of these transactions that have to happen really quickly in order to get me my data back here at the client. OK, so why do you need to explore performance? Well, if you're about to roll out an application that no one even asks the question right here, hey, how fast does my app need to be? Your app needs to be fast for various reasons. Among them. [00:01:33][30.3]
[00:01:33] Maybe one condition would be what if our user is trying to escape an earthquake so performance can be inadequate. So you need to explore to find out what part is it? The tower, is it the cloud? Is it my RFP or is it my local device that's actually slow here on the device? Is it the Web server? Is it the app server? Is it the data source itself? Right. So I ask all of those questions about why performance is there is because slow is bad, right? Slow is bad. But you just need to figure out whether you really want something to be slow or whether it really needs to be fast. Right. So when does system performance need to be fast? When you're feeling right, when you'll not make things will not go fast. You can look at the ballots from Scott Barber and the greater context for the performance objectives that you have for the application. Right. So if you do your first test load test, everything goes super fast and everything's, wow, this is really great. We really nailed the architecture. That's awesome. You know, what do you trust that it's you maybe have a false negative. [00:02:53][79.2]
[00:02:53] Maybe in the real world, the wi-fi or the RF signal would be worse. The reception throughput would be bad, maybe the power consumption, different types of devices. Maybe there's something in the Web service that you're in the lab, you're not out in the real world. Right. So there are lots of reasons that things might appear to go really, really fast. [00:03:12][18.4]
[00:03:13] So the greater context is, one, you need to explore performance issues and performance problems. If you see that other engineers who are responsible for the database, the Web server, the app server, maybe even the ISP, the providers who are going to be hosting where you're hosting the site if they seem clueless or they don't know what they're doing, they're a little lost. Raise your hand and say, hey, I think we should maybe bolster our confidence in the code by doing a little more exploration to make sure we're totally sure that it's going to scale. T. [00:03:49][36.4]
[00:05:22] The other thing you may find is there's a previous fix that you don't really trust. Like somebody said, oh, not a problem. I'll just tweak these number of threads or all just up. It's this simple thing and one little tweak and you don't trust that. And that's a healthy skepticism. Right. So that's a good thing to say. Well, I understand you're telling me it'll scale if we do this thing and this little thing, but I know that real systems in the real world are much more complex than that. So why don't we not trust that a previous fix to performance? Let's make sure we're going to explore to make sure that we're really confident about that tweak to the number of connections to the database. That would be good. T. [00:04:28][-54.3]
[00:04:28] The other thing that would maybe tell you when you should go exploring for performance is that you have a moment of insight or some intuition where you're like, you know, I can see the whole topology here and I can see what's happening. I don't obviously, I care a lot about the earthquake and the guy that's going to die. And I know that being slow is bad. But I have an idea. We have this array of different Web servers here and they're all kind of clustered inside the same area. You have some inside. This is what if we tried a slight. Different architecture and actually put some Web servers geographically in different parts of the world and so that we could buffer the presentation layer differently and present that faster if you come up with some insights like that or some intuition. [00:05:13][45.0]
[00:05:13] That's another reason to say, well, let's explore that as an option and then move forward to see if that's actually something worth doing. And that's the idea of why you would explore performance and when to best explore it. [00:05:13][0.0]
Comments are closed.