Percona Community Live Stream for PostgreSQL will focus on How to Benchmark Your PostgreSQL Database. This is a part of our bi-weekly meetup to develop open-source database skills. Come up with your questions and get an answer straight forward to all your questions.
Hello, folks, let me bring Charly again, and hopefully, we can hear him unfortunately, it was fighting this data for a little bit. And the solution is how to benchmark your Postgres database. But this is something we actually beat to hear Charly. We’re going to have to post apologize for that we’ll work out the technical details. I have support from our person for our streaming source, and they just came online and detected a couple of questions. So hopefully, we’ll get a simple thing to come through. Unfortunately, without audio, I know Charly is talented, but I’m not sure. interpretive dance puppets and I know we can’t write fast enough to write this on a sheet of paper flashed up.
I will have to go back and capture that, and make some news for Charly just for that. So I apologize. Currently, folks, we will redo this and reschedule it, and it’ll be even bigger and better. And Charly is unmuted I can see that. All right. Alright, let’s get the screenshot here
We can get a screenshot of it you’re on now Charly, and we’ll try to figure out what’s going on. Well, folks, I’m going to wrap this up since this is all we just sent it to me I think he probably sent it to me persecute see that I will save another copy.
Maybe anybody else can hear me? Folks, can you hear me? Can somebody say something?
I don’t know if anyone in the audience maybe someone on YouTube can hear you. Let me turn on my audio on YouTube. As we debug all this turned on, on YouTube. Please.
Yeah, try to say something. Okay.
I can hear Charly on YouTube. Oh, okay. So we’re, we’re just gonna go with what we have dala? Out in the terminal on YouTube and myself. I’m here. And we’ll go as best we can. And over to you, Charly.
Well, that’s right. So that’s, that’s interesting. Well, at least somebody out there can hear me. Right. Well, welcome, guys. It’s been a couple of minutes with troubleshooting some technical issues. And so the slot could not hear me, but looks like the old is going through. So we will try to make it happen again. Next time. Yeah. Yeah, some technical issue sometimes happens. Well, anyways, hi, today we’re gonna talk about benchmark and database, right, especially benchmark and Postgres. It’s an interesting topic. It’s a interesting discussion. And it’s complicated. Actually, it’s easy and complicated that lads put on this way. Because when we were going to benchmark something, is because usually we try to improve some right to improve performance or to improve availability, all those things. So the first challenge that we have, when we are going to try to benchmark is what problem we are going to solve, right? I’m sharing my screen here. Actually, I think I’m sharing the wrong screen, I want to share this window here. So you can see my win, right? So I have a very simple database, he actually I just installed my database. And I started when one benchmarking to put something. Usually, when we go for benchmarking, we need to define what’s the problem, we want to solve what kind of information we want to define that, right? Because when you go for the database, is a complex piece of software. Right? And it depends on even more complex infrastructure to work. Right, then we can have problems, performance problems, or any other problems on the database related to too many different layers when it comes to the database. And a very common one is IO. Right? So are you is usually a very source of problems when it comes to the database. Right? So one thing that we’ll usually do when we go to benchmark is okay, how can we prove the value? How can we get the value better? Right? So, well, first thing we need to do easier, okay, define the target define the problem. So let’s say, now my problem is my database is low. And I want to improve performance. Right? As I was saying, we have insurance lives. So the easiest way to improve performance on database is obviously animal hacker, right? So if I can add more CPU, if I can add more memory, if I can add faster IO, right? So I can always improve the performance with my database, adding more hardware. But there are two problems with this approach. Well, first one is cost. It’s, it’s costly, right? So if we go out there, let’s say we go to AWS and we are on whatever tier, we can always go to the next one. So but sometimes, just going to the next year, double the cost. And it might not be a choice, an option of putting more costs when you’re doing those things. Another problem is just adding a yo has a limitation, we get to a point that doesn’t matter how much more memory, for example, we add to the database, it won’t get faster, it won’t get better, right? So in all those things, we need to understand if adding more and more resource to the database can make any difference. So then, to be able to understand we need to understand how our database is working at the moment. How are our resources, right? So and this is when this benchmark thing comes to place. Right? So let’s say here, I have this, this database. So I don’t have any table here. No relations. We create a table to one very simple table. I only put an ID. We’ve got be integer, no index mapping. So, very simple table. And what we’re going to do is we’re going to insert into select going to insert here the minerals All right, so you’re gonna insert your fan heroes, this is basically an AI operation on my database, right here, my database gonna be quite an IO intensive. So but one thing that we can do, it’s very naive approach, we can run some tools like. So, as you see here, I don’t have much happening on my database languages before I start. So, you’ll see CPU is almost doing nothing is sitting here. So the memory consumption, I have 62 gigabytes on my box here. And we’re using almost nothing here on my database, right? So if I go here, let’s see what happens. See here that I have basically one CPU core from time to time has been switching from Port core, but I basically have one CPU for doing all this operation here. So we can see that this is not intensive operation, right? Look at this naive approach here, I can see that okay. If it’s not CPU intensive, the memory did increase. So then this specific load here was IO intensive. So for this very specific thing here, can we make it faster? Is it possible to make it faster? Do we have anything on the database, then configuration and thing that we can do to make it faster before we go for better a decent, for example? So those are the questions that we start asking when we start to benchmark the database. Right. So those are the things that we need to enter one to benchmark database. And that’s the major thing to benchmark the database. What are the problems we want to solve? I got a problem here, I have this insert that took 11, almost 12 seconds here. So how can I make it faster? All right. So I saw with this very naive benchmarking approach, that’s well, it’s not CPU intensive, it’s not memory intensive. So one thing that I might be able to do is trying to change some IO parameters, right? So, let me go here to my database folder. Well. So my configuration here is very, is the default configuration. So, it’s very basic. I didn’t change anything. I just installed this database. So everything that you want to see are the default. Okay, I got a problem. I have an operation that this is all I using this naive approach of troubleshooting of benchmarking. I saw that while it’s C, IO bound, it’s IO intensive. How can I solve like, How can I try to address this problem? Well, the first approach, before we spend money, we go for the database configuration. Right? So what are the parameters that we might have here on the database configuration that you can allocate the I O pressure on my database? Well, we have a few of them. First thing is, when we go to rotate, we can disable some stuff on the wall files, right? So for example, I might do not want to have synchronous comments. Let’s disable this one is a synchronous comment. Well, one thing that I always tell people, I’ve seen many, many, many tutorials on the internet asking to disable that I’ve seen because it will help improve performance. That might be true. Well, after that’s true. If you disable that think that it will help improve in especially audio performance. Let’s do this. But never, ever, ever do this in a production database or even in a test database and then do it for your database. Because if you disable F sync, you can re have data corruption, so there is no way to the database tell that the data is safely written to the disk, this is a very stupid and naive approach of improving performance. I never do it at all. So we do here, because be some stupid thing I use to prove a point, but never disable that thing for the database. Okay, I’d say, well, those things I go on. Before I do, let me drop my database, at my drop table. And I gonna restart my database
I want to restart my database I just restarted my database, I got just to do the operation here, again, create the table. And now I gotta do my insert here. So let’s see what that does. But we just did to change. We change it the one, I forgot to put my baseball here. And I forgot to find it again, I gotta drop the database, I gonna drop the people actually gonna restart here. Because they don’t want anything on the database crash. It might get us to a few milliseconds here for this operation. And then, well, actually, it didn’t improve much yet didn’t prevent, right? So this change, just in my specific case here didn’t improve, literally. So but it depends on your disk, it might, you might get really a good performance improvement. Because what happens when you disable F sync, the data will not be forcefully flush to the disk, every time that you do a commit. So then it might get some improvement. But then I’m thinking that my happens is you have data corruption, because as it’s flush, so production might happen. But well, all the parameters here, we can, for example, foot wall compression. To make the wall, like to write last things to the wall files.
We can disable some checkpoints, we can increase the demand for offside, I don’t think that marks or size is a problem for myself, because it’s too small, but we can increase the window the whole size. So there are a lot of parameters here that we can go and start changing and troubleshooting when to to prove to change this benchmarking. And one thing to note, when doing when troubleshooting and benchmarking the database, that every time you want to change something, don’t change many parameters at the same time, change one parameter, see what happens, change another parameters, see what happens. And so forth. So if you get an improvement, you know what? Which parameter help it to get the improvement, right? So don’t change too many parameters at the same time. Try to make things in smaller chains. So you can always trace back to what where’s the parameter that you change it that help it with that? Okay. So yeah, this naive approach didn’t take us too far. Right? So, it’s, it’s it was basically trying to go here for the IoT things. We can get better. We can, we can get better. And there are tools out there that help us to get better at when benchmarking the database. One of these tools is I need to save all right. I say one of these tools is Sysbench. Suspension is a very powerful tool and works not only with horses, we’re supposed to use MySQL on a database and we can even excrete these matrices which we can create scripts in the past in my installation here is sure Sysbench. Here we can scrape seas by inch to, to do some more customized tests, or we can use the worst has been written there. So one that we are going to use here now for for sometimes is a legacy one oil should be legacy for oil. Okay. This is another thing that we need to take in consideration. Alright, so the first thing, we need to have a specific problem, why we are benchmarking the database? Okay. Are we benchmarking for performance? Yes, we’re benchmark for performance, we have a range where the problem is yeah, in that case, we saw the problem it might be in our case might be IO, or might be some problems and some cash and we don’t have enough memory for the database, right? Still, I ovulated.
Okay, then the next step is, how is our workload how our application works because there are many types of workloads out there. So the most common is one, or the online transaction, or LTP. Right. So it’s like, when you have a mix of writing and reading operations, most of the websites, what they do, or applications, all the, so you have a lot of writes and reads to your database at the same time. So you have a mix of load of writes and reads for your database, usually, the reads are not so long. You don’t send a query that takes like one hour, 30 minutes, then certain minutes. So those are not counting for OLTP applications. When you send a select for well TP application, usually you want to get the response really fast, within less than a second, right. So this is very important to understand. Because the load that we put on the database for our LTP application for these, this type of world is different from another one, for example, for all, all AP is more designed for reports and business intelligence and all this kind of stuff. So is usually readings, mostly readings, almost no writes. And usually, when we send a query for an online application, we expect that it’s a really heavy read inquiry and going to the mail takes some time. So the way to benchmark those different loads, the way to approach those different ways, then those different types of loads, they are not the same. Right. So as the most common of database out there, well, TP we have a lot of quality key benchmarking tools. So, in this case, here, we’re going to use I’m going to use for this example, the Sysbench. The first thing that we need to do when doing the load is to seed the database, we need a test database. So I did it in advance here because it will take some time. So I created this database. And it has 24 tables every table has around Jr under megabytes. And this is an important information. Remember, I have 64 gigabytes of memory on Omnibox. If my database is a lot smaller, like it is in this case than the amount of memory that I have, it can performs a lot faster than if I had less memory. Right. That’s another piece part of the puzzle that we need to understand. How is our database box how is the box itself? How is it configuration Just is the data set? Can the data set feed only memory? Or is the data set a lot larger than the amount of memory they have on my database? How does it work? How is my dataset how those things are being setting up there? Because the results, they can be totally different, we can have totally different results. So for the same machine, the same box with different data sets, we can have hopefully different values, different results. So it means that a major ah, to be reproducible, we need to have even the similar data science. What else you cannot compare one benchmark with another benchmark? I’ve seen people comparing benchmarks out there. When but okay, yeah, look, I have the same box, but the benchmark that you teach. But one benchmark, the amount of data, so the data set was like three 410 times larger than the amount of memory and not a benchmark will fit all the members. So we cannot compare those two different benchmarks. They’re not it’s not fair to this comparison. But okay, so yeah, I did here. So I have this. And now, let’s run our first benchmark. And in my case here, I want to run its formula.
Last week here, so it will connect to our database.
In this case, here is a Read and Write benchmark that I’m doing, it’s not read-only in that write-only benchmark. So it’s mostly OLTP benchmark. So it’s read and write. And same thing here. I’ve asked him to report every two seconds. I gave him a table size. So we want to ensure that our load fits in this amount of science. So also, I gave him how many threads I wanted to open, because that’s a lot, a lot of things depends on how many connections are we open to the database, we can have more or less transactions per second, or credits per cycles as we do. Okay. It’s gone. It’s been shared. And now we have a report. Right? So in this box on my database, I had impressive 29,000 queries per second. So but not so impressive transactions per second, it’s like 1400, almost 1500 transactions per second. Right. So why might that happen? Way ahead. I could have so many reads, and but not so many transactions per second. So it looks like we’ve been impacted for something. Right? Well, we can probably make things better. Let me go back to the configuration. And, okay. Usually, a very simplistic way to improve performance is even more memory to the database. Okay, let me give more memory to the database. So on both of these, we have these shared buffers. And here I have 128 megabytes. We’re gonna give it eight gigabytes. Oh, it’s all right. It’s a law. And that’s the only change that I want to do here. I will save and then I will restart my database. Let me copy this value and see it somewhere. I’ve said somewhere and now I just restarted my database. Okay. Let’s run it again. Reversing. So let’s see what happens. One thing folks that you need to keep in mind is those tests, those benchmarks we’re doing here, they are not reflecting anything, because while we’re writing for one minute, if we really need one to understand how the database works, we need to run benchmark for a while longer period, because there’s a lot of things that happens inside of the database. First of the things is, every time I run a test here, I restarted the database, right? Because I want my database code. So what it means I don’t want the data to be in memory from the previous execution. So it means that one middle benchmark would not probably not be able even to warm up my database. So in this warming app on App time, can impact a lot on the performance for my database, see, the difference that we have here for the transactions per second? It’s pretty minimal. Actually. It was a smaller than the odd one.
Even the number of queries per second here was mostly for the other one. So what does that mean? Like? Does it mean that given more memory to the database doesn’t improve anything? Like everybody says, if we can get more cash, most things, they need to be the database needs to run faster, right? And this is when this happens. So we don’t we need to run benchmarks, when you do benchmark we need to run depends on the database side, like if it’s a small database, like this one, probably 30 minutes benchmark would feel cage to have a more accurate information about how the database is working, how the box is working, if it’s a larger database with a larger box, so you can give it five, eight hours on the benchmark. So the more you give to the benchmark, the better gonna be the results, the more accurate gonna be the results. Right. So yeah, we saw here that it didn’t do anything. So but what happens if we run this again, now that we, we don’t, haven’t restarted? So let’s give it one more try without restarting. Right, see what if anything, changed, anything happens. So one thing that I see here is, obviously, it started with 22,000 queries per second one to like, around 2728 28. And now it came to 30 or 3130. Cube. And we didn’t change anything. Alright, so this value here, we probably a bit larger than the previous one. And we didn’t change anything on the database. The test is the same, we didn’t change anything. So this is our our facts of the database being one up. Right. So we’re given that the data is now being pushed from disk, and it’s been sitting in memory. So we got an improvement. It was before a huge improvement, but it’s it has improvement. Probably if I run it one more time, we’re gonna get a bit more improvements until it gets stable to the point that it gets a stable. So that’s the point that you see in your application. And that it’s another thing. So if you have the habit of restarting your database every night, I’ve seen a lot of companies they do okay, oh yeah, we’re going to restart the database every night. So we want to design it fresh. It’s not good for performance. It’s, it’s pretty bad. Because all those cash that’s been washed up, now we’re just fortunately moving on them. And then application needs to start fresh from scratch and put everything in memory and the database is going to be there. And this also happens to the benchmarks. So not only the database, not only the two, right, so let’s come back from wherever we are now. So Okay, first thing first, we need to define the problem. Okay, what’s the problem we want to solve? Okay, I have a performance problem. Right? So do you have a hinge of why the problem might be Yeah, we got the hinge for that naive approach, that probably in mice in one case, seems to be related to IO. So can we improve the parameters while we can In a couple of parameters, can we make the the load less IO bound and more memory bound? While we try to we change the memory parameters on the configuration, right? Did we get any improvement? Yeah, looks like we’re getting some improvements. Probably, if we let it running for like, 30 minutes, one hour, we might, we will see the improvement that’s happening here. Right. So those are some of the pillars whether you’re doing the benchmark. Okay. Nice. Okay, what can we do? From here? Are all the things that we can change here on the database side? Anything? So we can change anything?
We can, for example, change the different buffers, okay? I want 84 megabytes. Or, in our case we’re not working on shouldn’t be a problem. Let’s just change amount econometric. I don’t want to mess up with vacuum at the moment. I think is on synchronous call me is off. Oh, I don’t want to wait, right? Well, while it’s, in some circumstances, it’s needed, especially when we have a crash, or we want to do a big rewind, if I’m not mistaken. So for now, I want you try to make the rights a bit faster. And I want to run the database, right last. Because Postgres has a huge problem of double writes. Every time that we do a commit, we send data to the database to to Postgres, when you do a commit, it needs to go to the wall files, and then from the wall files, then it’s copied from the wall files to the page files, or the tables itself. So this is a double Right, right. So there are some ways we can try to reduce the impact. One of them is do not have full peaks. Oh, it might have a problem. If we do not have a good 100 Or in some crashes, circumstances, it may make things harder to recover. But if mathematically, can we reduce the number of writes from from the database, so it will reduce the fact of patrons let me make it we don’t have logins. So we will have more compression that’s been from before. And the checkpoints before, before we mess up the check once. Let’s see those enemies. And again, we started the database, we’re getting cold again. So probably the first run here, we may not get much. We started going from 26. Oh, looks like that. That did something. This is those violins are already the same as we did before. So looks like those she’s gotten some improvement. We’re running, we’re going to do looks like we’re going to the right way. And the thing is because we understand the problem that we’re trying to solve, it’s not only benchmark, but we do understand we sort of understand what is causing the problem here. In my case, in this very specific case, here we can see that the problem is sort of related to their final operation. So we are trying to minimize the impact of the ILO on the database and that’s why we are getting some results here. So the first one we just got as we had the last one and the database like it’s a comer. So we’re getting we’re getting there. I said hopefully I did, but we also can play with the checkpoints. So I have checked one to five minutes or more in fact here because we are running one minute. I got see that’s how it’s naive to run a one only one minute a benchmark tests. So we cannot even from the default configuration, even see what happens with when we start checking points, because our SharePoint find out because our test is happened in less than five minutes. It’s one minute, right? So when we do benchmark we need to properly properly prefer for a long run batch one, as I said, leave it run for queue for eight hours. Leave it run at night. When you go back in the morning, we’ll see the results right.
But anyways, so yeah, this here will not be any difference 30 minutes or maybe it’s those elevate something because it will make the checkpoint worse price mark. So even though we right oh, I’m going to leave it the default here. My back offsides goes off, we have sois mobile, it’s probably not even getting two to one gigabytes. We’re here right? So we did not have archiving because I do not have replication here. It’s just okay, no recovery, no recovery, replication, we don’t have anything for replication, so doesn’t matter, you still have replication. Okay, I think for now, we don’t need to do and career planning. Alright, so we’re not logging anything. This is something that can impact performance log. Log is important. But if you have your production database you write a lot better. And depends on the verbosity of your log, you can get a huge performance impact. So I want to just start by database you will see that the last thing to do admin right so probably going to be the same night or two seconds. Let’s after this run, I’ll try to enable the log I’m gonna try to make it for you, we will see the impact even problem in these smaller bets here we can see that it can be can this is something that we need to keep in mind. If you need if you need more than you need to make sure that your logging facility or assignment will be log Masuda buffers the log so it gets back to the database really fast and then it washes a synchronously instead of just sending the log to the system of facility that’s going to try to flush it as fast as possible. And if we didn’t as expected we didn’t have any improvement because we’re just one meal is not enough. So I’m gonna label here we’re gonna send to the login directory on our filing I gotta put your patient sighs one gigabyte en GB
You saw my database and lights do overseas match. Let’s see how they look where they happen I think we got something right here, right? So from now we are down to 10,000 this is the sort of impact we can have, because of IO, in my case here, because of London, right? It’s a huge the Mongols in a year. So, what’s happened to my database, because I’m logging like crazy. On my database here, let’s wait to finish to see the final results. And see how amazing that’s going to look to less than 1000 queries per second. 500 transactions per second and 1000 graduates it’s amazing how we can not only improve, but how we can prove a point that having too much walk is really harmful to the database performance. Right. And this happens to the same when we have a huge, huge query, it’s breaking a lot of template files. So every time that we make our load, or you’re bound, in my case, I’ll tell you about them, it’s not because of the data is but because of the mortgage, the performance will crazily down and well my audio is not that bad. Like Well, it’s an SSD it’s not a an expensive SSD who like it’s not a server grade SSD, but it’s still just your SSD, right? And you can see how amazing the performance went down and this is one thing that we need to be very careful, right. Well those are things that we can do like when we are benchmarking. So, we need to follow some of those basic rules you need to know what we want while want Batman The reason why I went with my what is the problem I tried to solve the approach that we have. So and then as I mentioned there are many many tools out here this oversamples I was using but we can their audit tools we can use audit tools like for example here.
Okay, can you guys see my screen here? So we have all the tools out there as well. So we have seen specifically for Postgres, and we can find some documentation on the Postgres here. So also on the Postgres documentation, we can, we can find some things here. If you go for Percona blogs, we’ll see some blogs about using tools like physicists bench, the one I was using here, also using PG bench for some sort of order benchmarks. An order today, it’s amazing. It’s nice. You may take some time to understand how it works is how do you see if I’m able to get how my GPS coordinate here is to show you so how many of you has this nice interface?
Yeah, we are having a lot of technical issues here. Okay, can you guys see my screen? Okay. I think now you can see. Okay. So this is 100 DB. I create the DBS here. Yes, right. Let me open this test file. So this is 100 DB has this nice interface here that we can use to run some tests. And we can also use the CLI interface that we can script and automate and everything, right? But if we just whoops, let me change the number of users here. That is fine.
Okay, I drop in my database, so we need to build the schema. Let’s build a schema. All right. So it’s building a schema, you take a couple of probability minutes. So how many DB it’s, it’s very good, especially if you want to go forward TPCC type tests. So it’s really powerful. It works. Using the notion of warehouses, right? So the company has, can have one or manual houses, when we have our products in an ever warehouse can work with one or any customers. So when one of any deliveries, and every delivery or every order is what the how many of you gonna go to start tracing is not only about transactions per second, not only about insights per seconds, but like orders and the whole operations per seconds is something closer to how the application would work. Write it’s very interesting the approach that they use. And so it’s really, really nice. Nice to hear, as I mentioned, so we can script is has a nice CLI or we can use the graphical interface. In my case, here, let me see I have harmony. Okay, briefly users. And I got around here for two minutes, so we don’t have that much time anymore. It also has if you see here, it also has the ramp up time so you got to try to do some warm-up. So we’re gonna create here And we’re going to run well, we can see how many transactions per minute How many operations per minute the database is starting to do. Right? As it will update here every 10 seconds. So in my case, here, I’m running 31 virtual users. So the virtual user is like, the application that doing the order is the user, the person that goes to the internet, to buy your stuff, buy, this is how it works. And we can have, we can see here on real time, how that things are working. And after finishing. We also see here on the monitor, how it will show how it presents us the information here. But let’s give it a couple of more minutes, we are about on the top of our hour. But as we had some technical issues, I think we can go a couple of minutes. For right, so that should be fine. Okay, it just finished with the one up. So it will now it’s now doing the transactions. Don’t get depressed with those numbers. Because those are transactions per minute. If we get a calculator and divide TQ, nine to six, by 60, we’re gonna see that we have 3821 transactions per second. So that is somehow compatible with the information we got from sysbench after we enabled that amazing login, remember, so we’re not expecting to get a lot better here. Because well, the logging is still hurting the database performance. Right? I do not expect to get anything even closer to 250,000 transactions per minute. Right? That would be around 4000 transactions per second. Right? Because well, we did an amazing job of putting content into our database. Okay, it’s almost done. Or middle.
And it’s almost there. So why it’s finished? What was the wrap-up here? What we were discussing? Yeah, it’s got so it’s what we see an average of transactions per second. Right? And how they said it’s amazing to Sysbench boxes, which is major, as well as another amazing tool. But depending on how you will the type of tests that go to your database, you probably want to go for hammer TP, right? So it’s incredible. It’s an amazing tool, then that to wrap up here. So the benchmark is a very powerful tool like benchmark database or benchmark anything else? It’s very powerful to like a question that we have here. Can we run a benchmark to test a new hardware? Yes, we can. Right? Actually, it’s advisable not only that we can, I would say we shoot like, every time that we get a new harvest, every time that we get something, we shoot benchmark. And there are many different types. When it comes to her. There are many different types of benchmark, right there is specific benchmarks for their hamper, so we could match the days. So we can bypass the last catch, we can benchmark the memory performance, where instead of bypass there was cash, we write a lot to the west cash, we can benchmark CPU. So we do a lot of CPU operations. So we understand how the new 100 performs better or waltz from the old hardware. And remember, a new hardware does not necessarily mean that it gonna make the database runs better and faster as the old one. Right. But yeah, if the hardware is better, it’s a high chance that thing’s gonna gonna gonna be better. But yeah, we should definitely benchmark when we get new hardware So, but as I mentioned, like wrap it up. So it’s a very powerful tool we can use for the database. When I say powerful tool, I mean benchmark is a powerful tool, we can use for the database, we can read for the heart, we can use for the wires we can use even, for the network, right. And when we define the specific problem, we want to solve the specific problem, we want to benchmark. So we have those guidelines, then it’s, it’s easier to get more accurate information. And remember, if you go to benchmark, don’t do five minutes, of benchmarking. Maybe not even 30 minutes benchmarking, let it run for a couple of hours. So let your database or your heart to show what it’s capable with, because it still it needs to, it needs to in case of the database, it needs to do up the cache and all this kind of stuff, right? So on. And you can have a huge performance difference in both sides of good performance, because now it’s put a lot of things on the cache. Or you can see how you can hurt performance with the checkpoints. Right. So those things they don’t happen in one to five minutes, benchmarking. You need to leave it a benchmark to our Well, thanks, folks. Those are the things that I wanted to share. We weren’t up to top bar. It’s not the top of our but like we had those scholarships in the beginning. So I think it was five minutes after here. It’s fine. Thanks again for being here. I hope you enjoy it. And that’s it. Thanks, baby. It’s with you.
Well, thank you, folks. Thank you, sir. Have a good night, folks. And we’ll be back in two weeks with another talk with Charly. So have a good day.
Thanks, everybody. ∎