First, determine the size of the packets the database returns with the data. Some experts recommend fine-tuning the packet size with which your database communicates, but this is risky. Such fine-tuning can degrade performance, and a database application rarely requests chunks of data in a single size, so don't change this setting without understanding the potential impact. You can get more information on how to fine-tune packet size from your database vendor (see "Sites To See," below).
The sniffer, meanwhile, lets you determine how many times database connections are made. In our sniffer tests, the databases we examined exchanged multiple packets when establishing a connection. This can increase traffic if connections are being reopened consistently.
And finally, measure the size of the query result sets the database returns to the client. We parsed through the result sets and determined the quality of the application vendors' code. If you find that a particular application is pushing many large data sets across your network, you can work with the application vendor to improve the software. If you're having problems sniffing traffic from a particular database, meanwhile, you can set up a port mirror on your switch. That ensures you receive traffic for that machine, and not traffic destined for others.
Once you've gathered all this information about the application's behavior, you can simulate a single client and predict the impact of multiple clients. If the database performance degrades in other ways when you add clients--producing more I/O than your disk can handle--it will appear to lessen the load on the network. But don't be fooled. The minute you fix the bottleneck on your server, you'll encounter traffic problems again.
Now that you have data on how your database traffic affects your network, you can reduce that traffic. Like any attempt to tune a database, the quality of the SQL query hitting your database plays a big role. Cleaning up SQL usually solves database performance issues.
Then look at connection pooling. The concept may seem simple--keep connections open between the database and application or application server so you can reuse them right away--but it has several facets.
To realize the benefits of cloud-native software, an application must actually be cloud-native—designed to run in the cloud, interacting with disaggregated cloud services, fully manageable as code—to deliver the expected benefits.
By combining resources and expertise, the AI-Enabled ICT Workforce Consortium will offer a blueprint for how industries can adapt to an AI-dominated future.
IT leaders should heed the guidance of cybersecurity insurance providers who think businesses should prioritize security education, incident preparedness, regular internal audits, and ongoing vulnerability scanning and patching.
