Build, protect and deploy apps across any platform and mobile device
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate decision processes with a no-code business rules engine
Build mobile apps for iOS, Android and Windows Phone
A complete cloud platform for an app or your entire digital business
Deploy automated machine learning to accurately predict machine failures with technology optimized for Industrial IoT.
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
In the second half of this two part podcast, Rob Steward provides examples of the impact reducing network traffic can have on database application performance. The podcast runs for 3:18.
Click on the following link to listen to the podcast: http://blogs.datadirect.com/media/RobSteward_ReducingNetworkTraffic_2.mp3
One of the examples we use in the book is you should be in manual commit mode as long as that makes logical sense for your application. What do I mean? The tip that we give in the book is every standards based data access API that you can think of, ODBC, JDBC, ADO.NET, OLE DB, they all by default put you in what’s called auto commit mode. Now what auto commit mode means is that when I execute a statement, it is automatically committed; therefore, I do not have to start transaction, execute a statement, and then do a commit. That just all happens when you begin transaction, the commit happens under the covers. I don’t see it as the application programmer. But on some databases that can incur an extra round trip because if the underlying database does not natively support an auto commit mode – some of them do, some of them do not – what those drivers, or those ODBC drivers, JDBC drivers, ADO.NET data providers, what they’re required to do by the specification is they have to issue those commits underneath the covers.
So if you do 1,000 inserts, what you may actually be incurring is 2,000 network round trips. One round trip for each insert, and then a successive round trip for a commit. Most programmers do not realize that that is the case. But if you go with the manual commit mode, where you explicitly – through the API say, ‘begin a transaction,’ you put this in your code, ‘give me 1,000 inserts,’ and then you explicitly, through that API, do a commit – now what you’ve done is instead of 2,000 network round trips, you have 1,002. So you’ve got a begin transaction, you’ve got 1,000 inserts, and then you’ve got a commit. That’s 1,002 versus 2,000 round trips in an auto commit, where even though you don’t realize it, you’re doing an insert and the driver underneath you is also issuing a commit as soon as that insert is done.
So, those network round trips can be a significant amount of time that you spend accessing data. I’ve seen cases where – particularly over a WAN, and I mentioned this earlier, or over a VPN, because of the package sizes of the latencies within those networks – when you tweak a few things like I just said, you may see 150% improvement on your overall performance because you’ve reduced those network round trips in half.
Is network traffic important to the overall performance of your application? Absolutely! It will always matter. It will matter even more in conditions where your network latency, like on the internet or across a wide area network or a VPN, where that network is a little bit slower than say your local area network within your building. Network traffic is a big deal. Reduce the number of round trips, and use all the techniques you can to reduce the actual size of the data coming across the wire.
View all posts from Rob Steward on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2017 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.