You have probably encountered a situation where pre-launch load tests did not correlate with the way it performed in production.  There are a lot of reasons why this can happen, but for now, I want to focus on 3^rd party content providers and Content Delivery Networks (CDN).  Almost everyone running a business today has some part of their application or Web presence farmed out to a 3^rd party.  Think about what happens when you go online to buy gifts for the upcoming Holidays.

As you browse for that perfect tie for your dad, the site is likely to be serving static content from Akamai or Limelight, adds from 3^rd party providers, and a shopping cart that may not be hosted by the company you are dealing with.  When you actually purchase that Tickle-me Elmo for your niece, the site processes your credit card by interacting with a financial institution and provides shipping tracking numbers by interacting with a major shipping company behind the scenes.  All that typically happens as you wait for the page to return in a few seconds if all goes as it should, but any of those 3^rd party providers have a strong likelihood to disrupt the page load and make the site look like it is not responding.

Increased delays from these and other 3^rd party providers do happen and you should definitely test for those scenarios, but how do you do that when you really do not have control over those sites. You definitely should perform load tests on the site as a whole to ensure that each 3^rd party provider will scale to your targeted peak traffic and perform within their SLA as expected. In addition, you should think about how slow your 3^rd party providers can get without affecting the performance of your site.

“How Slow Can They Go?” Yes, a corny statement, but to the point! You definitely need to identify how slow your 3^rd party providers can go before it starts to affect the performance of your sites.  The real dilemma is replicating the traffic from the 3^rd party site, which in the case of financial transactions can be very difficult plus your team can waste a great deal of time trying to do this. I’m suggesting that you don’t try to replicate that traffic, instead use the actual 3^rd party traffic from the 3^rd party site during the test. Here’s the catch, you impair the traffic coming from the 3^rd party site real time. Simply single out that traffic in your usability studies using a tool like Shunra’s VE Desktop to measure performance of the site with the 3^rd party adds impaired or by slowing down the response from your credit card processing partner using a Shunra VE Network Appliance on your backend systems during a maintenance window.

Now think about scalability load testing for a minute. I recommend that you do not implicitly trust 3^rd party and Content Delivery Network (CDN) provider’s scalability estimates and guarantees. You are probably scratching your head thinking that your CDN’s and other 3^rd party content providers have massive server and network infrastructures that are impossible to overload. While it is true that the major 3^rd party providers have massive infrastructures, the real question to ask yourself is this, “How much of that infrastructure is your content riding on?” Let’s just say that you actually do know how much of their infrastructure is dedicated to your cause, you still have to ask yourself the question, “Do I know for sure that it will handle the peak traffic?” Adding in impairments during a load test is easy using Shunra’s VE Suite or Shunra for HP Software which works seamlessly with Load Runner.

During my career I have load tested literally hundreds of different sites, and many of those sites had CDN and 3^rd party content provided by very large companies that did not hold up to the load during a stress test. Let’s face it, regardless of the size, the CDN or 3^rd party provider’s service can only scale to the level of infrastructure that is available to your site.  CDN content can fail to scale due to complex caching configurations that can get screwed up with one incorrect setting.

In more than one situation, I had a customer tell us that they were going to inform their CDN or 3^rd party providers to “be ready” for the peak traffic that our load test was going to generate. They were usually shocked when I asked, “Why?” Their answer was typically, “We need to be responsible partners and let them know anytime we are doing testing.”  Clearly, I would normally agree with that statement for many different kinds of testing, but not in the case of load testing against an established Service Level Agreement (SLA)!  Here is the bottom line, if the CDN or 3^rd Party has agreed to an SLA then that system should be ready to handle that load any time (barring timeframes specified in the SLA for maintenance windows, etc.).

In several load testing engagements, where the client let the CDN or 3^rd party know about the load test, there were “additional resources” stood up to support the load test. Surprisingly, the system scaled during those times, but failed to scale when no notice was given ahead of time. Does that sound suspicious to you? If the answer is yes, then we are on the same mental wavelength. If you encounter problems with your 3^rd party provider not scaling during your load test, and they will probably insist on “supporting” you during the next load test. Be sure that you ask your 3^rd party providers the following questions:

What did you do to support this load test Vs. the last one?

What did you change in your infrastructure that allowed it to scale successfully this time?

Did you add infrastructure or change a setting?

In one situation, I heard a 3^rd party provider tell my client that they stood up an extra bank of machines to support the testing that was happening that evening. My question to the customer was, “Does that sound strange to you?”

At the end of the day, we all need to admit to ourselves that even our monstrous 3^rd party CDN partners can slow your site down, so you really should test how your site performs to the end user and how the infrastructure scales when they do slow down. Try to find out how slow each 3^rd party provider can get before it impacts your site and ultimately the end user’s response time and build that into your Service Level Objectives and ultimately let that drive your Service Level Agreements with 3^rd party content providers.

Now that I’ve startled you out of your summer doldrums, let’s talk about how you can perform your tests most accurately. First, let’s talk about an all-too-common pitfall of not taking network latency into account when building the load test. Most teams will load test their site to ensure it will hold up to capacity, but all too often the team fails to take into account the implications that network latency will have on their load tests. As a result, testing teams will run load tests from a single location, often the same location that the Website is hosted or from within the lab itself.

If you just asked yourself, “What’s the problem with doing it that way?”, then you seriously need to read the next two paragraphs!

Unfortunately, our web sites have finite resources resulting in limited scalability. Yes, even cloud sites  occationally suffer from this affliction, here are a few examples from this year http://www.crn.com/software/225701829. Load testing without taking latency into account gives the site an unfair advantage during load tests, which does not exist in the real world. This is especially true when your internet traffic hits on Cyber Monday. Think about it this way, when your load test generators are on the same network or physically very close to the Website, then packet round trip time is less than 1 millisecond. Now contrast that with users across the internet with packet round trip times of 30 to 50 milliseconds (that’s if your user is in the same country as the web server) or even 100 milliseconds or higher going to different continents. That translates into network connections staying open for 30, 50, or 100 times longer with internet user traffic compared to your lab setting. This is a significant difference which results in longer HTTP sessions, longer page downloads, higher simultaneous HTTP and application server sessions. This can even impact database activity. Ultimately, means Internet user traffic consumes more site resources compared to testing without the correct network latency.

I’ve conducted numerous load tests in a previous role, and I have literally seen websites crumble under Internet traffic that was less than half the load tested traffic where no network emulation was used during the load testing. Now think about all the other parameters that you should be thinking about, like packet loss, jitter, and the impact that the end user’s bandwidth has on the test dynamics.

Now, let’s re-run your load test and add in end user network impairment (latency, packet loss, bandwidth, and jitter) into the mix using Shunra. Because the network latency that we just discussed now matches that of the end user, you can expect an accurate estimation of the site’s true scalability. With Shunra, you can replicate users coming from a variety of locations so you’ll be correctly replicating the latency of users from multiple geographies for even higher accuracy.

To bolster the accuracy of the network emulation, Shunra has a Network Catcher technology that records network latency and other impairments, and then allows you to use those conditions in products such as Shunra for HP Software while testing your systems. This is important because network latency changes throughout the day depending on internet traffic.  Thus internet latency at noon is not the same as it might be at 2AM, when many sites conduct their off hours load test.  With Shunra all the network guess-work is taken out of the load test process and you are left with a more accurate load test. That’s powerful! And it’s one of the reasons that I joined the team here at Shunra.

There are many challenges organizations face when it comes to administering and maintaining a dedicated pre-production or staging environment for which accurate performance testing can be conducted. The cost to manage and maintain infrastructure, along with personnel and facilities, can be fairly sizeable and are only a subset of the overall costs to be considered. So, in many cases performance testing can be rather expensive and this is exactly why virtualization can provide significant benefits because there is cost reduction across the board. A prime example is in many performance labs there are a variety of application performance tools typically utilized for testing – one such tool is HP LoadRunner or Performance Center. These tools are a primary part of a performance lab as they provide load generation capabilities and can accurately test applications under real world load and stress scenarios. However, these solutions require a significant amount of infrastructure and resources (A Controller to execute tests, LoadRunner Generators to produce user traffic, Virtual User Generator to record scripts, etc.) and this can make it very difficult to manage the environment when it has to scale to meet higher demand. In this case, virtualization saves time, effort and cost because resources can be allocated dynamically within the environment and any number of virtual machines can be leveraged when needed to handle these resource intensive applications. This is also enabling many organizations to architect and customize elegant configurations that more closely align with their testing requirements – which can minimize unnecessary infrastructure and resources. Yet, the prevalent issue many organizations still grapple with is how to execute performance tests that accurately depict the network for which the application will be deployed across.

The most pervasive approach that many organizations would take is to physically deploy hardware (remote load generators) in offices that they wanted to test an application from. This process was not only time-consuming, but also expensive, inaccurate and cumbersome to manage. For this reason, HP decided to form a partnership with Shunra to develop a seamless solution that provides this capability within the HP LoadRunner and Performance Center solutions – Shunra VE Desktop for HP. This solution aligns very well with the virtualization movement because it is simply a plug-in within the HP products that introduces the network into the existing test bed and can be leveraged across most virtual platforms. For LoadRunner 9.5 and later, there is simply a “WAN emulation” tab that can be accessed from within the Controller to introduce the latency, jitter, packet loss and bandwidth constraints directly into the test. With Performance Center 9.5 and later, this capability can easily be configured directly from the browser UI to allocate WAN emulation parameters across any number of desired load generators. A consequence of this is that organizations can leverage on-demand performance testing from a dynamic virtual environment that is agile, flexible and robust. This therefore eliminates the need to manage testing cycles across multiple time zones and remove any need for additional hardware. Additionally, all of the network metrics from each generator utilizing WAN emulation within the test will automatically be imported into the controller, which can save a significant amount of time when collating results and generating analysis reports. These reasons are precisely why numerous organizations have decided to improve their existing performance test environment with the VE Desktop for HP Software  solution. Not only does this solution address a strategic gap within the functionality of the HP solutions, it embraces virtualization as a means to more effectively administer performance testing. Overall, the VE Desktop for HP Software solution was co-developed with HP to considerably enhance the accuracy and value of these application performance test suites.

While actual deployment may be month away, it is important to remember that the transport mechanism, open Internet over an IP Core will require substantial testing of the end user experience. IPTV is a protocol sensitive to network conditions, like latency and packet loss.  Any successful implementation will have to include significant bandwidth allocation testing, as well as load under latency, jitter and packet loss.

Are you migrating over to the Web 2.0 world or considering adding modern architecture and components? If so, take a look at this interesting video I came across, in which Mark Tomlinson and Steve Feloney from HP, our partner, tackle the challenges of load testing Web 2.0 applications. It will be well worth your time to check out Mark and Steve as they address the top issues that make LoadRunner web testing much harder and more complex. Very helpful and it’s only 4 min long!

In this video, Mark and Steve talk about real challenges their customers faced when migrating to the Web 2.0 without considering the impact of WAN latency, and most importantly how to solve this! Anyone using VE Desktop for HP Software should also definitely check this out and take a light-hearted look at web load testing.

This video is the first in a series put together by Steve and Mark covering some top issues that make LoadRunner web testing much harder and complex. Stay tuned for the next part of “Real Stories of Load Testing Web 2.0: Impacts of WAN latency of Web 2.0 apps”.

…will Steve end up going to Paris? and what will Mark find on google? the plot thickens…

That sounds like a lot of clouds!  What we are simply trying to understand is where and how to deploy your application in the cloud, so it will perform well for your customers.

If you take the case of deploying an online store into the Amazon EC2 cloud, there are many things to consider that will impact your customer’s experience.  Two of the most important are where to deploy what, and how your store will function over the Internet.  To compound the issue, where you physically deploy machines within EC2 is not clear.  Amazon goes to great lengths to avoid you knowing where their zones are.

Fortunately, you cannot only find solutions to these problems, but with cloud computing the process gets a lot easier.  To break the problems down into a logical flow, you’ll first need to know the demographics of your customers.  Where are they?  How will they access the store?  What needs to happen for them to have a positive experience at your store?  If you can answer these questions, you’ll likely come up with some numbers that place percentages of your users in different regions around your target market (US, EMEA, global, etc.).  Further, you’ll know the top two browsers they’ll use and with what kind of connections they’ll access the internet (e.g. Firefox with a 768/256kbps DSL, or IE8 with dial-up – yes people still use dial-up!).  Finally, you’ll have some way to quantify a “positive user experience”.  That usually involves consistency (does it work?) and speed (how fast?).

Using the information above and HP LoadRunner with WAN emulation, you can quickly build a to-scale test in your cloud-based lab and understand what would happen if you hosted your application all in one place and serviced your entire customer base.  Odds are that the test will not meet all of your performance goals the first time you run it.  Most likely, you will need to adjust some things in your store (e.g. reduce chattiness and image resolution, optimize Web 2.0 use) and then begin the discussion about where to deploy what.  Can you keep all of your database servers in one place?  If you have to split your database servers, how will that affect performance?  Will you need to deploy web servers in every zone, will you be okay with one in each region, or will you need something in-between?

Again, not only can answers to these questions actually be answered, but by using cloud-based testing you can arrive at valid conclusions faster than ever.  To understand the network impact of deploying machines in different zones, network performance measurement tools like VE Network Catcher can run in each of the zones to measure network performance between zones and to customer representative endpoints.  Importing that data directly into HP LoadRunner with WAN emulation and using the flexible cloud environment, you can rapidly form and either dismiss or validate hypotheses about how your application should best be deployed.

The benefit of testing in this way is that you can experiment with many different configurations in rapid succession to find the one or few that are most appropriate for your needs.  Trial and error with a live application is not advisable.  And building a test lab with physical machines to simulate the same thing is not only significantly more expensive, but a lot slower process.  As I pointed out in my previous blog, the same ROI formula that explain and fuel the explosion of Cloud Computing for hosting applications are also relevant for using Cloud Computing to test your applications with.

Now you know what I think.  What do you think??

The following posts will answer this question and more, but in order to get answers we need to first address additional questions:

Consider the remote user in Tokyo, he is accessing multiple applications that are all hosted in the remote NYC data center.

Will all these applications perform the same way once hosted in a remote data center?

The obvious answer is NO, some applications will perform well even when users are remote to the data center, while others will provide intermittent poor performance and some will always perform poorly for a remote user.

The answers to the next questions are less obvious:

• Why do some applications perform well in remote data centers while others fail miserably?
• What is it about the way applications are designed and architected in a remote data center that allows some applications to perform better than others?
• What are the key design flaws that cause applications to perform poorly in a remote data center?

Since there are a lot of different applications, there are also a lot of different answers to these questions. In the next couple of posts we will focus on enterprise-data-driven- transactional applications and their performance flaws over the network (ignoring for a moment back-end or desktop related bottlenecks). We will further limit this category to client server based applications, ignoring for a moment the complexity of N-Tier applications and multi web service based applications, these will be dealt with in future posts.

Over the years I was asked to analyze performance problems for many transactional applications and specifically analyze their performance degradation when users are remote to their data center, the following are the key application metrics that I found are related to performance degradation over the network:

1. The number of application turns per transaction (or how chatty the application is)
2. The transaction size (or how much data needs to be downloaded from the server to the client in order to complete each transaction)
3. The transaction efficiency factor (how much data a transaction downloads per application turn)
4. The blocking nature of object retrieval (can the transaction retrieve multiple objects concurrently or is each object download blocking other object requests from being processed)
5. The transaction redundancy metric (or how much of the same data is being retrieved by all the requests made by this transaction). It seems like this metric should always be zero, but you will be surprised how often this is the single reason behind performance problems.
6. The transaction initialization size (how much data does the transaction download initially Vs. sequential navigational steps)
7. The caching ratio (how much data is cached locally as a percentage of the overall data needed by the application)
8. The latency scale factor (How does the backend’s ability to scale change when network latency is added between front end clients and the backend)

Measuring and observing these metrics allows for the deep level analysis that is required to identify performance bottlenecks. This information also helps to point out to application developers and system engineers what needs to be changed in order to remediate application performance problems.

In the next couple of posts I will explain each of the above factors and describe how each of them impacts application performance, so sign up for the RSS feed to get notification on these future posts.

Until then…

Amichai Lesser

Performance Test Lab testing

Pros: Controlled, repeatable, relatively easy to debug observed problems

Cons: Expensive to build and maintain, commonly implemented without real world network considerations

Live Network testing

Pros: Cheap, good for periodic sanity checks of performance

Cons: Puts non-revenue generating load on the production network, very difficult to debug, high volume testing is not an accurate depiction of end user performance

The good news is that developments in cloud-based testing and in HP LoadRunner have been able to improve the accuracy of Performance Test Lab testing while also reducing the complexity and overall cost.  By moving HP LoadRunner load generators into a cloud-based testing environment, your testing can immediately benefit from the flexibility and scalability of the cloud.

One specific use case is for Peak Testing.  Peak testing is simply another name for load testing.  What “peak” implies is that it is at a scale that is not common.  If you are running, or want to run a test that is not commonly run in your environment, then it is fair to assume that you’ll need to plan ahead to gather the necessary resources.  Working in a cloud environment makes gathering and configuring extra resources on demand easy.  Need an extra five load generators?  No problem; just clone your existing one and wait for them to start.  Need more RAM?  No problem; just shut the machine down, configure more RAM, and restart the machine.  Working with the latest version of HP LoadRunner with WAN emulation makes the story even more compelling.  Need load generation from LA, London, and Tokyo?  No problem; just configure the load generators to emulate those locations and they will.  Sound easy?  It is.  Companies like Skytap already have thought this scenario through and have a great subscription-based model built for you to use today.

The real benefits of peak testing in the cloud are that you can quickly scale your lab up and down without the burden of maintaining a lab large enough to support your peak needs –saving time and money.  It is the end of costly lab build-ups, running tests during maintenance windows in the middle of the night, sending load generators to all corners of the world, and putting test traffic on your production network!

Of course, there are a lot of other ways Cloud Computing can be used in a QA environment; validating new versions of test products and proof of concepts are two that immediately come to mind.  In the end, the same ROI formulae that explain and fuel the explosion of Cloud Computing for hosting applications are also relevant for using Cloud Computing to test your applications with.

Now you know what I think.  What do you think??

P.S. Stay tuned for a coming blog on location-aware deployment testing in the cloud…

In alignment with global trends, more and more clinical trials take place outside of the United States, while the documentation and analysis is done in the US for submission to the FDA. So it is not out of the ordinary to find an Oracle Clinical user in Eastern Europe or in China submitting data to an Oracle Clinical Server hosted in the united states.

Unfortunately, as commonly found with an off the shelf software package that gets customized over time, this type of application can easily morph into a performance challenged application, especially for remote users. The following analysis shows an example of an Oracle Clinical transaction that completes in 8 seconds for local users, while extending to over a minute when users in E. Europe tried to use it.

Transaction Response Time Analysis for an Oracle Clinical Application Accessed by Local Users Vs. Remote Users in E. Europe

Obviously, that big jump in response time was a great cause for concern with my client’s management. Which is how I got the privilege to be asked to analyze the root cause of the poor performance.

The first thing I noticed was that one particular transaction (Connect to DB) had an extremely high jump in TRT from 8 seconds locally to over a minute when accessed remotely, so I focused on that one first.

Looking at the network fingerprint of the transaction you can observe the following things:

The transaction size (amount of data downloaded from the server required to complete the transaction) is extremely high (over 5 MB).

The transaction generates 34 HTTP calls. Some of those calls take disproportionally longer time than others (notice the Get jar file calls that each exceed 19 seconds marked below, click on the image for a larger view)

Oracle Clinical, Transaction Analysis for "Connect to DB"

When inspecting those JAR files, we saw that they were very heavy in size, over 1 MB each which is pretty big for basically a collection of Java classes that are zipped into a JAR file.

You can also observe in the next bounce diagram that most of the JAR files are downloaded in a serial fashion, blocking other objects from downloading in the mean time. Notice the delta time displayed on the right column

Bounce Diagram for an Oracle Clinical Transaction

What can be done to improve the performance of this application?

Oracle Clinical uses JAR files to package Java code that will run on the client. It is not uncommon for customized off the shelf applications to increase in code size over time until the code is very bloated.

There are several best practices that developers can follow to reduce the size of JAR files:

1. Rationalize the code – as applications develop over time, multiple classes and sometimes adjacent projects might reference similar libraries and other assets. If not careful those libraries and common assets end up packaged multiple times inside the JAR file, causing it to inflate in size.
2. Minify the code – a quick Google search for “reduce the size of JAR files” will reveal several free tools that can minimize the size of JAR files, usually through eliminating white spaces, comments, shortening variable names, etc.
3. Defer loading – chances are that not all the code in the JAR file is needed for the “connect to DB” transaction, which means that users that only want to perform a small transaction are penalized by the download time of code that will never get executed by them. Deferred loading is a design pattern that simply says “only download assets or code when it is needed” I wrote more on that design pattern in this previous post “http://www.shunra.com/shunrablog/index.php/2009/01/29/content-loading-when-being-lazy-pays-off/”

In summary, as more and more web 2.0 technologies hit main stream, new forms of performance pitfalls may present themselves, requiring us to consider application performance for remote users even for applications that traditionally were considered “remote user friendly” such as web based applications.

How was this Analysis Performed?

This analysis was used by integrating a HP LoadRunner script modeling an Oracle Clinical business user with Shunra VE Analyzer. So as the scripted transactions executed across a virtual WAN (simulated by the Shunra VE) the beginning and end of each transaction were marked by the VE Transaction Manager. At the end of the test, the VE Analyzer had sufficient data to generate the attached reports, enabling us to pin point the root cause of the performance problem. You can learn more on how to set this up by going through Shunra Certified Performance Engineering training, either on site or at the next Shunra University. Learn more about Shunra training here:  http://www.shunra.com/shunra-university-overview.php and here http://www.shunra.com/training-overview.php?keyword=services

Questions, comments, feel free to write me at amichai.lesser at Shunra dot com. Or comment on any of my posts.

BTW, we just created a new Application Performance Management Group on LinkedIn, feel free to look it up and join here  http://www.linkedin.com/groupRegistration?gid=2200667

Best,

Amichai Lesser

In the next 2 posts, I will address the first 2 questions, the third one is probably a good topic for a book, so I will attempt to address that one over several future posts.

Should you really test all your applications for latency prior to a data center relocation?

Before jumping into a direct answer with examples of horror stories from past data center relocations that didn’t test all applications and the consequence of that excessive risk taking I want to first provide a conceptual best practice answer.

I recently received my Six Sigma Champion certification and one of the concepts in Six Sigma and in management for quality in general is “Don’t mass inspect, build quality into the process instead”. This concept was one of Deming’s teachings that revolutionized the Japanese manufacturing industry in the 1950s. So one would think that according to that best practice, we shouldn’t test all applications prior to a data center move, since that would be the equivalent of mass inspection. However, that would be a miss interpretation of that statement, an organization can shift from mass inspection to more statistical sampling only if quality is built into the process and when mission critical processes are in control. To complete the analogy, an organization can settle for sample testing a subset of applications only if application development processes have quality built into them, and specifically with a data center move, application development processes have network aware best practices embedded in them. I have yet to find an organization that reaches that level of maturity prior to a data center move. Usually the causation is reverse, first a firm relocates their data center, then IT realizes that they need to adopt a new application development paradigm since from now on applications will access remote servers in a remote data center and thus network aware best practices (like using VE Desktop as part of the development life cycle) are added.

So this brings us to the reasonable assumption that most companies will have a portfolio of applications that weren’t developed with a distributed WAN in mind and now have to adjust to operating in a remote data center. If that is the scenario your company is facing then mass inspection is your only way to mitigate the enormous risk associated with such a move.

Now if you don’t buy into the conceptual answer, consider the following:

1. In an average data center relocation project, we usually find that 20% – 40% of applications experience performance degradation ranging from visible to severe. (visible means that a user notices the slowdown in response time, severe means that an application stops being usable under latency conditions).
2. Many of the problems we uncover end up being show stoppers for the DCR project and need to go through remediation before the project can complete.
3. The mitigation path varies between applications and is very dependent on the type of problem that causes the performance degradation. Hence, a typical remediation solution may include WAN Acceleration for some applications (mainly server-to-server copy utilities and file services), terminal services (Citrix, remote desktop, VDI, etc.) for other applications, code fixes for some applications and architecture changes for the rest. Therefore engineering a solution based on a sample of applications will results in a sub optimal solution that doesn’t address all the performance problems that will manifest post the move.
4. When a large NY based insurance company relocated their servers from NY to Atlanta, GA without testing, they ended up rolling back the first phase of the relocation when several mission critical applications became unusable due to poor performance.

In summary, unless IT has built network aware best practices into the software development process, an organization planning a data center relocation must test all of its applications to analyze the performance impact that new added latency will have on application performance. More best practices on this topic can be found in my recently updated white paper that can be found at http://www.shunra.com/predicting-the-impact-of-data-center-moves-on-application-performance-whitepaper.php

The next post will cover the question “Which applications are the most vulnerable to the added network latency?” small example, any applications that are running executables from a shared network drive, will experience severe performance problems, that and more will be covered in the next post.

In the meantime, I am curious to hear your experience with data center relocations, what approach did your IT group take? Test all, sample test or cross your fingers and just move? Let me know.

P.S. as part of my Six Sigma Certification, I developed a dashboard and a flow chart for a data center relocation performance analysis, it needs some work before it can be shared, but if enough readers ask for it, I will try to clean it up and post it.

Till next time,

Amichai Lesser