Network virtualization and efficient mobile apps
The O’Reilly Podcast: Guy Rosenthal on network virtualization.
Close-up of cell phone (source: Samantha Celera via Flickr)
In this episode of the O’Reilly Podcast, Doug Sillars, author of High Performance Android Apps, spoke with Guy Rosenthal from Hewlett Packard Enterprise on network virtualization (NV), and how NV can help mobile developers build applications that run more efficiently on cellular networks.
The full conversation is available through the embedded audio. Highlights from the discussion are noted below.
Learn faster. Dig deeper. See farther.
These highlights were edited and condensed for clarity.
What is network virtualization?
Network virtualization is the ability to capture and emulate real-world network conditions, in order to test applications in the real-world; you can analyze the test results and remediate performance bottlenecks before deployment.
I treat network virtualization as a performance booster or companion to other testing tools and practices; whether it be load testing, functional testing, or mobile testing. It aims mainly to fix or to optimize the performance of the end-user experience and the back-end servers.
What problem does network virtualization solve?
The problem is that when you are testing in your labs as a developer, you don’t have the ability to emulate or to imitate how your real users will experience your application because you have very limited resources. You have one or two devices at most. Even if you have more than that, they are not spaced around the world with different network conditions and different carriers.
Some of your users might experience 2G or even worse in network conditions … If you use network virtualization, you can actually emulate any network conditions that you think of, regardless of your testing cycle. You can measure the transaction response time and can understand the experience of your end users.
Once you are done with your test, you can get an understanding of how your application performed for the network. What are the bottlenecks? You can see a waterfall to detect the specific resource that was problematic. You can get a very thorough root cause analysis to improve your application.
Can you run these tests as a part of your continuous integration testing?
We are providing an SDK or API, wrapping our REST API. We are going to soon provide even more comprehensive means to do that by giving JavaScript and Java libraries so you can actually run or emulate your tests with the network conditions that you like from your testing framework—whether it’s Appium, Selenium, Gatling, or HPE tools such as LeanFT, Unified Functional Test (UFT), LoadRunner, StormRunner, etc.
The second thing that we are going to provide is a Jenkins plugin so you will be able to use your current assets without using the SDK, and encapsulated with emulation. If it breaks some threshold, you can break the build. In addition, if it’s breaking the build, you can get, as a developer, some kind of identification of what happened. Our analytics report provides a drill down to help detect the root cause for the failure.
Network virtualization can speed up your mobile app, but can it help your back end?
You have a lot of users from all over the world and some of them are mobile users with often low connectivity. It means that your servers are working hard because of those slow users. It means the connection pool is being occupied faster, the CPU is increasing, the thread context switches are increasing. This is one thing you need to understand: how bad networks can influence your back end.
Most of the transaction response time is spent on the network, so if you optimize your applications for the network, you should see strong results. As a by-product, it might also impact positively on the server because you’re optimizing your application—and the connection to the server will be better with less overhead.
Want to learn more? Get a report about your web application performance in less than three minutes.
This post is a collaboration between O’Reilly and HPE. See our statement of editorial independence.