Create and deliver personalized experiences across digital properties at scale
Build engaging websites with intuitive web content management
Leverage a complete UI toolbox for web, mobile and desktop development
Build, protect and deploy apps across any platform and mobile device
Build mobile apps for iOS, Android and Windows Phone
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate UI, load and performance testing for web, desktop and mobile
Host, deploy and scale Node.js, Java and .NET Core apps on premise or in the cloud
Optimize data integration with high-performance connectivity
Automate decision processes with a no-code business rules engine
Globally scale websites with innovative content management and infrastructure approaches
Content-focused web and mobile solution for empowering marketers
Faster, tailored mobile experiences for any device and data source
UX and app modernization to powerfully navigate today's digital landscape
Fuel agility with ever-ready applications, built in the cloud
In this podcast, Rob Steward offers insights into overcoming the performance penalties associated with data encryption. The podcast runs for 3:04.
Click on the following link to listen to the podcast: http://blogs.datadirect.com/media/RobSteward_PerformancePenalties_Encryption.mp3
Rob, it's nice to be here with you today. I have a couple of questions regarding The Data Access Handbook. In particularly, in The Data Access Handbook, you write about the performance penalties associated with data encryption. Do you have any tips for improving throughput? We're just talking about the data encryption topic.
Great question, Mike. What we’ve found in our lab when we do benchmarking of using strong encryption versus no encryption when it comes to data access (all that data that you’re requesting from the database that flows back across. Particularly when we talk about data encryption most people mean SSL – some sort algorithm through SSL to encrypt the data), what we’ve found in the past in our benchmarking is that the encryption itself causes about 100% overhead. In other words, if I were to fetch a result set and it were to take ten seconds, if I were to turn on and strongly encrypt through SSL that entire result set would probably take 20 seconds instead of 10 seconds. So it about doubles the amount of time involved in communicating with the database. So it’s a very good question, particularly in the regulatory environment today where a lot of government regulations are forcing people to encrypt a lot of data that they weren’t in the past.
What I can tell you is that overhead – that overhead about 100% that goes along with the data encryption – I have not seen any way to significantly reduce that. You’re kind of stuck. You’re going to take a penalty, and I think everybody knows that. But that penalty, from my experience, is about 100%. Now, what that does do is make it even more important that you follow the tips that we give you in The Data Access Handbook in order to reduce the amount of data and reduce the amount of roundtrips across the network. So, if I can take that result set and reduce it in size, the amount of time that it’s going to transmit that data to the client is going to be significantly reduced, obviously – even without encryption. But again, if you’re going to take your existing application, or you’re going to take some piece of code that you’ve got that is accessing data, it’s even more important that you make sure that it’s tuned to reduce the amount of data.
There are a lot of tips and tricks in the book that talk about how to reduce the amount of data that comes across the network, and I’ll refer you to the book. But particularly with encryption on, you really need to reduce the size of that data.
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 © 2016, 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 or appropriate markings.