Tune Applications with Data Replication like a NASCAR Pit Crew

        

At one time or another we have all watched some form of racing. Whether its Formula 1, Sprint Cars or NASCAR, we have sat in rapture as the cars go around the track until one crosses the finish line first…. What we never see is what it takes to be the first to cross that black and white checkered flag.

I have had the great enjoyment of working on a pit crew in NASCAR for a few years and I can tell you the race is only the culmination of weeks and months of work in preparing and tuning for that one single race. Tuning that starts in board rooms, in the drafting rooms, with the engineers, owners, crews and drivers. Tuning that continues up to and through the race.

There is not much difference between racing and our IT environments. In order to achieve the maximum performance for our applications, we have to apply the same dedication to tuning that is applied to racing.

From drawing board to deployment and beyond, it is vital that the systems be tuned so that maximum performance can be achieved. If this is not done then it will show up in slow response times, which will lead to unhappy users and customers, which will lead to potential loss of revenue, which then will lead to unhappy board members and stock holders.

If the underlying system is not tuned, it doesn’t matter how good the application is, it will not be able to perform at its peak capability either.

I ran into this a short time ago on a POC we had. We were demonstrating how SharePlex could be beneficial to the client during a migration. The source system had been tuned and was at its peak performance, BUT, the target environment had not. The target environment had been built and the database created with no tuning at all. I’m sure you can imagine the result when we setup data replication and tried to demonstrate it.  On the source side, there were no issues or backlogs, we were pushing data from the source as fast as the database could produce it. Then the data got to the target. Like one of our racing cars that has suddenly hit the wall in turn 1, so did SharePlex. On the target side SharePlex was running so slowly that it seemed that it had actually frozen and stopped responding. We were getting backlogs that were just getting larger and larger and no data was getting into the database. Imagine how that looked in front of our potential customers. We had everyone from support to R&D looking in to the reason why SharePlex had stopped working. After a lot of time and researching of the log files, it turned out that SharePlex had not stopped working. In fact it was working, it was working as best it could under the circumstances. The underlying environment could not provide the performance needed to keep up with SharePlex and this was causing the backlogs.

Their DBA then made some adjustments to the database increasing the buffer pools, page size and changing the SQL capture timings and we re-ran the replication. This time we were running on a system that had just some of the most basic tuning done and the results were amazing. SharePlex was able to replicate faster than the clients source database could create the data. There were no backlogs on either the source OR the target. The data was there and available as fast as it was being created on the source database. Needless to say the client were very “enthusiastic” (Their words not mine). Keep in mind, this was after doing the most basic of tuning, imagine what can be happen when tuning has been thoroughly gone over and completed on the environment.

To recap, this just shows you that it doesn’t matter what your application is, if the system has not been tuned for the best performance it can produce, you will never be the first to see the checkered flag

Take a free trial or learn more about data replication.

Anonymous