 Hello and welcome to the Windows Server Summit. My name is Anatham De and I am a Cloud Solutions Architect at Intel. In today's summit, we're going to talk about Accelerating Microsoft SQL Server Performance using Intel QAT, which stands for Quick Assist Technology. In today's agenda, we're also going to cover what is Intel's in-built accelerators and how to use Intel QAT with Microsoft SQL Server led by a demo. Intel Accelerators on Xeon. Intel has recently launched its FibGen CPUs, designed for AI analytics with optimized workloads, performance, and improve energy with data security. With FibGen Accelerator, we basically get four different types of accelerators with Intel Advanced Metrics Extension with AMX and AMX Advanced Intel Data Streaming Accelerator called DSA, Intel In-Memory Analytics that are known as IAA and Intel Quick Assist Technology called QAT. With AMX, definitely this is designed for mostly AI workloads where we can get up to 99x performance increase with AMX Advanced up to 7x depending for what workload we are running. Intel Data Streaming Accelerator, mostly designed for network storage and memory copy. In-Memory Accelerator using databases like ROXDB and Cassandra, all in-memory database up to 3.x performance, and we're also going to cover about QAT which provides higher compression rate and decompression rate for Microsoft SQL Server. This is a quick brief architecture, how basically it works. With QAT technology, what we can do is we can basically offload CPU tasks to a device, so that device is called QAT, and that device is not a PCI device, it's basically a device that is part of the CPU, which means that additionally you don't have to go and add on-card into your systems, and this task can be completely performed by the device. Definitely it provides the hardware acceleration by offloading the task from CPU to the device. The best use case is the system performs best when the underlying system is quite high or the CPU utilization is getting very higher. With this, we basically see there is a speed-up in database backup time, which is around 2.3 percent, and definitely we're going to talk about a little bit more when we actually go and conclude the demo. These are some performance benchmarks that we have done with all the new instructions set and all the accelerators that we have, and today's focus is since on QAT, and we're going to deep dive more on QAT as we go through Microsoft SQL Server configuration and to see how backup is performed through QAT with Microsoft Express and also a full backup. And what is the reduction in TCO, in OPEX, and KPEX, okay? And let's go back to the demo. So in this demo, we have taken a database size of around 100 GB, 110 GB, and we have named the database called QAT benchmark. And in this benchmark activity, we're going to run a couple of benchmarks simulating kind of a production environment, right? Before doing that, I want to also highlight that once you have a system enabled with QAT, you basically see that the QAT is not being configured although it is present in the system, right? So if you select parse this command in SQL Server, you should be able to see the QAT is available in the hardware or not, right? And now we're going to do hardware offloading. So we just know enabling the hardware offloading to QAT for SQL Server. Once we do it, we need to restart the SQL servers and on the hardware offload, right? So right now we are just making sure that the SQL configuration is set correctly to use QAT and we can alter the server configuration. And as you can see, without any error, we are able to alter server configuration and we just need to restart SQL Server. When the SQL Server is restarted, we should be able to see QAT in active state, right? So let's wait and see if the QAT is now enabled. Yes, it is now enabled. As you can see, QAT is now enabled and configuration state is in one, right? And it has also picked up the hardware enterprise addition. And right now this system is configured with one QAT device. So you can go up to four QAT devices each socket and depending on your system configuration, you can have multiple QAT devices. This is basically what we're also trying to simulate here is a kind of a production environment where we will be creating multiple warehouse and creating some transactions using HammerDB. For this demonstration, we have taken only nine virtual users and then we're also going to start the transactions and if you can see the transaction is now started and the CPU usage is quite low. So in order to simulate, for example, if you have other application is consuming more and more and more amount of CPU, right? So at that point of time, if you perform a backup operation, what we see is that the backup operation really gets low, right? And during that case, what happens to either end up restarting the SQL services or taking a backup or restarting the server, which basically includes all the downtime that has been involved throughout this activity. So in order to simulate such kind of environment, what we're doing, we are basically running some background jobs to load the CPU. In this situation, we load the CPU and we're going to keep some struggling happening in the CPU itself, right? But we'll keep the CPU load up to 85% to 90%. We are just keeping some headroom just in case something spikes up and we will be able to demonstrate that how fast in a peak environment, right? You should be able to take faster backup, right? So faster backup reduces time. At the same time, since it's a compressed backup with hardware QAT, what we'll also notice is that the compressed backup size has also been reduced. And as you can see right now, we loaded the CPU roughly around 87 to 85% in the system and we're going to perform some of the backups. So the first backup use case that we have taken here is basically to take a full backup of the database, right? And the second use case would be, you know, taking a backup using MS Express, which is kind of a compressed backup using Microsoft Express software backup. And then we're going to take a backup using QAT hardware which will basically use QAT deflate, right? To initiate backup. So this is the first backup that we are going to initiate here. And as we initiate the first backup, let's wait and see how much time the full backup takes without any compression and no formatting of the database. So we have taken the backup and we have mentioned basically without QAT and the backup name, right? And it's a full backup. Let's run this. And we'll wait here for some time to see how much time it takes to actually backup the whole database. And meanwhile, what is also happening in the backend is that we are not stopping the transaction. So assuming that your system is still going to transactions of all insert, update, delete, and all the operation in your SQL server is continuously running, right? So CPU utilization is still high. We are still ballparked at around 87 to 90% in the CPU, pretty much 85 to 87% of the users, we are not spiking it up. And as you can see, we have completed 40% of the backup. We wait for some time to see how much time it takes for a full backup to be get completed here. Yeah, the backup is still running, we are at 90% and it should be completed in couple of seconds. So the backup is now completed and it can tell you how much time it took to process all the pages. It took around roughly two minute 49 or you can, we can consider around two minutes, 50 seconds to come for the full backup to be processed, right? But just let's keep in mind, the full backup will always consume almost the near the same capacity of the transaction that is happening in the database, right? So if I'm taking a backup of 100 GB, 110 GB is going to be approximately 100 GB of storage space, right, for every full backup. And then the remaining one would be, you can take all this transactional backups every time when we are running this. So the next backup we're going to use is using Microsoft SQL Server Compression, basically using an MX Express method, right? Which also helps in using space. But what we've observed through this process, right? The compressed backup is that the time it takes, right? It's a little bit higher than a full backup, okay? Since the data is being compressed and I think everybody is, everyone today takes a compressed backup in order to save storage and other networking cost. So this is where we execute and take a compressed backup. And here we can see pretty much from 87 to 89%, right? So almost like 2% of CPU increment using the software that we see here because it's now right now trying to consume more and more CPU cycles. Although this system has a larger number of cores, 224 cores, but even though if you consider around 2% of 224 is roughly around like 4 to 8 cores it's been consuming, right? So when it goes to cloud we talk about all the CPUs and not. So the consumption would definitely come down and we can have the right sizing of the right instance in the cloud. While this has been processed, we'll just give it some time to complete the full backup throughout this. And so we are now at around 80% and we'll wait a couple of seconds to see how much time it took for a compressed backup. Okay, so it's been done. So the backup just got completed. We're just waiting for the process data. So it took roughly around four minutes and 24 seconds, right? So four minutes. And also the throughput that we see is pretty much less right now because it's compressing a lot of data around it. Now the transaction is still running, right? So we have not touched this hammered EV yet, right? We have not stopped transactions of the database, right? Because right now we want to take up another last backup within the hardware Q&A team. And we also may want to make sure the CPUs are up to around 85 to 87% here, right? And while we run this, okay? I will wait, we'll give it a minute to initiate the backup sequence once again. And for each backup files, what we've also taken the snapshot, we will be able to see how much of storage has been saved, how much of storage is basically being processed, right? And saved into the disk. So we are at 50%. So we are almost done processing the backup. We'll see how much time it took using Intel hardware Q&A team. Okay, so it took roughly around one minute, 59 seconds, right? So definitely we see the improvement around 2.23% of the increment. And as you can see, the storage has really been reduced, right? And per GB cost also matters for larger infrastructure. So with Q&A team, it was around roughly 55 GB and without Q&A team, it compressed it to 56 GB and the full backup was around roughly 90 GB. So in this case, we're gonna stop the transactions, right? So the thing is the backup is successful, but the thing is we also wanted to showcase one more capability is that we wanted to restore the backup, right? And we want to make sure the restore is completely successful because it was taken on a hardware outside of the C2 cycles, okay? So for this demonstration, we'll be only backing up the file which has been backed up using Intel Q&A team. So the blue Q&A team stands for with Q&A team and we're gonna initiate the backup process or initiated the backup process and we'll give it some time to process the whole backup. Okay, so roughly we are here and we can see that the backup is getting successfully restored. With this, there's one more thing we really want to talk about is about data resiliency, right? Data, you know, how good the data is all up after this. So we're gonna, after the restore, we're gonna do a sandwich test, basically, you know, querying top 1,000 customers from the restored backup. And we can see that there is no data corruptions. All the header files has been retrieved successfully into this. Yeah, I think that's all I had in the demo. And definitely we'd like the team, you know, to work more with us to basically, you know, drive more of accelerations in the cloud, in on-prem, basically to have Microsoft SQL so it will also help customers to reduce space and accelerate all the backups. Thank you for attending the summit.