[00:00:00] Mark Tomlinson: So hopefully with all these videos, you have enough information to get yourself started with your first exploration, but I thought of a few extra tips to share with you from my experience that go above and beyond the outline that I came up with you today. And there's a few challenges that you will get if you get into this mode of exploring and working your way through the map of all the components across the system, measuring everything and the first tech critique and thought that I had, you might get challenged on the idea that there's inside out or outside in performance measurement and performance analysis in terms of load testing and such. [00:00:42][42.4]

[00:00:42] And you'll find this a lot with database people. And part of the idea is that I showed you the way I traverse the system today in the map was outside in, I was going from the external systems to the left and working across the map to the right. So as we moved across to the right, then we were at the data tier we are at the central systems distributed. So and that's called outside in performance testing. And if you, if you are in working with a DBA or a database person, oftentimes they're like really bored for the first week of performance testing because you're fixing and tuning all the bottlenecks on the frontend and you're not actually putting any load on the back end. [00:01:24][42.0]

[00:01:25] So there is an approach that you can do, which is to start inside out, which is to actually generate database load specifically and so you're going to maybe generate load scripts or load tests at the database here, a JDBC, ODBC, OCI or even dotNet, SequelNet type of traffic. But you're basically going to load the database first and then as soon as that's tuned up, then you add the next layer and start generating load on the app into the database. Then when that those two layers are good, you add the third layer and then you put that in there. And the iterative process is adding more and more activity or more and more layers to the architecture as you go. [00:02:12][47.2]

[00:02:12] So that's inside out versus outside in. And you might it's good to be familiar with them, even though 90 percent of the time you're kind of starting usually from the middle or from the outside in the way things are built. But you might be asked to do that. And it's tricky. Another thing you might hear challenge about as a thought or a tip, another critique you might hear is that the end to end versus API performance. And particularly, what this particularly means is somebody wants to test before the client presentation layer, the web tier, the mobile app tier before any of that is done, they want to make sure the APIs are fast because there's the entire Internet or lots of latency on the front end. And they don't really they want to make sure the backend can scale before the frontend is added. A. [00:03:07][54.4]

[00:03:07] Nd if you go to the functional testers, they're like we do end-to-end testing meaning they don't really slice and dice at the API level in the middle, but they just do the same steps that you would do in the GUI or in the frontend of the application. And mostly they're measuring end-to-end response time. And the truth is for performance, as you understand the whole topology horizontally from front to back, you can actually think of it as this is just another tier, end-to-end is all the backend tiers one, two, three, maybe. And then add the client here and you've got end-to-end. [00:03:41][34.1]

[00:03:42] So if you have to do end-to-end performance, typically your web scripts are GUI-based web scripts. You might use Jmeter with the WebDriver add in for Selenium or like SauceLabs could be, have the same solution. Or most vendors have a solution that can do that versus Jmeter or Octoperf sponsor could just do API calls in the middle tier, specifically calling it. So it's good to understand end-to-end versus API testing as well. The last tip I have for you is there's a lot of people out there doing load testing that are not monitoring anything. [00:04:19][37.3]

[00:04:20] They don't monitor physically CPU, disk, memory network. They're not monitoring the logical app tiers through JMX or through dotNet. They're not looking at the number of threads, queued requests or anything like that or the heap and hand, why the memory is being used? So or the database here. They have all sorts of internals from an EWR reporter from all the different parts. So one thing I'll say about resource monitoring is you can see from all the examples I have today that it's really essential, it's an essential part of doing performance exploration because as you move from each layer into the next tier of the map, when you're exploring, you're making decisions on, is the CPU high? No, is the disk high, slow, no. Is the network slow? No, hmm this tier looks pretty healthy, but still it's slow so maybe it's not. [00:05:14][53.8]

[00:05:14] So you really have to measure and get those measurements at each tier as you progress across the map. So just keep in mind, if you don't have access to monitor CPU disk memory network or monitor the app, then you really need to request that if you're going to do performance exploration and dig deeper and you don't have a tool that does it all for you, like Dynatrace, New Relic's another good one, or, you know, any of the Impulse or a sense I think Neoload, NeoSense from Neotys pretty good for that as well. [00:05:44][30.1]

[00:05:44] So just keep in mind, you have to have some kind of monitoring even you're just manually opening perfmon or opening a top monitor, top, htop, any of these Unix commands that as well. And that's and that's and that brings me to the end, actually, of our summary for exploration of performance. Looking back on everything we we talked about today, it's important to explore performance when you're failing. If you're succeeding, you might not and you don't have any risks on the horizon. You know, nothing, nothing coming down the road, then you don't I wouldn't really worry too much. [00:06:20][35.8]

[00:06:20] But if you're failing before you get into production or you're in production, you're failing. That is exactly when these techniques for traversing the map and exploring performance are so critical and absolutely something that you need to look at doing. The the other thing I will say is that it's probably not acceptable to the stakeholders of your company to just sort of well, there's nothing we can do because there will be another person, another test or another engineer, another developer who knows what to do and will dig in. But if they don't, you might have to motivate people. You might have to instigate them. So if they're lost or they're like, I don't know, I'm just trying things willy nilly, grabbing at straws. [00:07:01][40.9]

[00:07:02] This is the kind of thing you're going to want to look to do. Right. The other thing I can tell you is that remember those three concepts, right? Remember that even though it's intimidating at scale, these huge systems, everything is a computer. Right. And computers are connected to other computers. Right. Even if they don't look like a computer internally, they probably are a computer. Right. The other thing to think about is that all of those computers inside the computers connected to other computers, inside the computers they're all have resources like CPU, disk, memory network or logical resources and frameworks like number of connections, licensing and things like that. [00:07:43][40.7]

[00:07:44] So every time you jump to the next tier and dig in, there's going to be resource limitations and they're not going to be equal. You're going to have three lanes over here and two lanes over here and one lane back there, just like we did in the example. Right. So you're looking to make sure I can do 10 requests per second at the same time on the frontend, I can do ten requests for second in the middle tier and I can do ten requests for second on the backend. Ten, ten, ten. You're going to be at a 10 lane freeway is going to be great. Keep in mind that you should map your topology and do some visuals like I showed you here. The the mapping like Impulse or Dynatrace or some of those other topology tools are nice. Even though they look 3D, they really are two, they're really a two dimensional layer. You're looking at sort of a top down view of the topology. And I just encourage you to think of it as the map, meaning there's there's not just one plane, there's multiple layers. [00:08:40][56.8]

[00:08:41] So these these systems are really dense that way. And then as you work through the map, the one thing to keep in mind is look for resource exhaustion, right? Look for max CPU 100 percent, look for memory heap that's completely exhausted. Look for slow networks where all of a sudden it's like boom time outs. Look for exceptions in the app stack where things are like, I can't, I'm out of memory. I can't do what you want me to do. I don't have threads, I can't allocate a thread, I can't allocate a connection. [00:09:12][31.0]

[00:09:13] So you're looking for exhaustion to get you from one tier to the next tier to the next component. And last but not least, have fun. This is a really exciting job and you get to learn a lot really fast. So even if you're overwhelmed and it sounds, you know, painful, it's drudgery, be sure to just remind yourself to have fun. This is exciting stuff. And blowing things up is is very rewarding. And thank you very much for taking your time for the PerfGuild. And on behalf of all the instructors, good luck with the rest of your learning. Thanks. [00:09:13][0.0]

Conclusion and Valuable Tips

You must be logged in to access this course.