[00:00:01] Mark Tomlinson: So there's a few other concepts that you need to keep in mind as you're exploring performance with your map, and I call them exploratory patterns, and this could just be modes of working or modes of thinking. And I just wanted to share them kind of quickly here. [00:00:15][14.4]
[00:00:15] Mark Tomlinson: One is research and verify. So you do want to verify and confirm a standard kind of measure. One thing you can always say is, hey, this response time should not be more than 10 milliseconds in the industry. That's a good, that's a great number of connections to the database shouldn't be really small. So in terms instead of navigating through the entire map, you might just look at one component and say, you know, everyone else on the planet has like 50 or 100 connections in a connection pool. Why do you have 10? You might also say that's just a that's the default. You might know the default and nobody in production like that's just there for testing purposes or development, you know, so you might research and verify that's one mode of thinking. Instead of going through and traversing the entire map, you might say, well, this is a pretty common Java thing. And one of the, one of the main Java bottlenecks I always run into is people just have the default memory configuration and it's 512, 512 Meg. They don't they don't know to change the, go do the basic stuff. So you want to research and verify and confirm some kind of standard measure. [00:01:27][71.3]
[00:01:28] Mark Tomlinson: Another thing you might look for is that you, a mode of thinking is that you have what I call a loose thread. You find one little exception or one thing that's slow and you're like, huh, this is, this looks like it's kind of a bottleneck. Like why is that particular API in the web tier slow compared to everything else? And you might specifically go to exploit or dig and explore, you know, like on a sweater, you pull a loose thread and it just sort of unravels right in front of you. So find a loose thread, find something that doesn't look quite right, database connection pools, you know, that's a common vulnerability and go exploit that particular thing. [00:02:06][38.1]
[00:02:07] Mark Tomlinson: A third way of the mode of exploration is to be an interrogator, go to a specific component, like the web server, like an app server, like maybe even low level network. Just flood the router and just go to that specific component and overload it. And you basically get to understand some underlying single point of failure and interrogate that particular component for its vulnerability. This happens a lot in architectures where you introduce some new idea. Right. And you want to interrogate that. [00:02:40][32.5]
[00:02:41] Mark Tomlinson: Another mode of thinking is trending. Right. So as you improve the performance of one component, maybe the next component gets slower like we saw in the model. So if you solve the CPU bottleneck in the middle tier, you end up pushing more IO onto the database. And that's that's so that's trending. What's the trend? Is it inverse? Right. [00:03:03][22.3]
[00:03:04] Mark Tomlinson: Which brings me to relativeness. One of the other ways to go through the mapping and understand what's happening. The mapping is that is it, is is relative. Right. Is a relative mutual or inverse correlations. As I increase load, the CPU goes up and my memory usage goes down for some reason or the inverse. Right. As my memory utilization goes up, my CPU goes down because I am actually slowing down what I can do. So think about trends and think about how different measurements relate to one another as you're observing each level of the map. [00:03:38][34.3]
[00:03:40] Mark Tomlinson: And an optimizer. Another way to say is, look, I'm going to try to improve on our ten second end to end response time. I want to cut that time in half and do double the throughput. So target some percentage of improvement on an overall response time or overall throughput and you'll be good to go. I guess the real point at the end for exploration is that you have a framework and you have a time frame, so you kind of have to choose what are my real objectives, right. I have this map. I have the way to explore the system horizontally and vertically at each tier and at each component. So what am I really trying to do? Am I going to interrogate one particular component? Am I going to look for some weird loose thing? I'm going to do a research to say you're following best good practices across every component, or I'm going to try to optimize overall end to end finding bottlenecks and tuning them and improving them for sure. [00:03:40][0.0]
Comments are closed.