by Sean
"In a single day, armed only with OPNET's AppTransaction Xpert, I found the real problem."
I recently visited a healthcare technology manufacturing and services company to assist them with upgrading their APM processes. One of their biggest pain points was an application that uses wireless handheld devices to track and ship products out of their many warehouses. When scanning products, the mobile devices were supposed to connect to a server in the company's datacenter that handled the transactions. When uploading data to these servers via the handset clients, wait times regularly exceeded 50 seconds. A complete non-starter...
This issue was not only affecting employee productivity and profit margins for the company, but had also consumed key IT staff in fruitless troubleshooting exercises for almost an entire year! An OPNET partner engaged to assist with managing the network was convinced that the problem was somewhere else. I received a pretty intense introduction to situation -- the company's IT team and the partner kept expanding their list of complaints about the mobile application as the conversation went on. The vendor that authored the mobile application apparently refused to take responsibility, stating that the problem was anyplace but the code.
In a single day, armed only with OPNET's AppTransaction Xpert, I found the real problem.
Working with the IT team at a single warehouse, and having installed AppTransaction Xpert agents on the servers, I did ‘On Demand Captures’ during times users felt the performance pain. First, I filtered out irrelevant conversations so I could focus on the mobile applications. I then immediately noticed a dominant delay pattern of SOAP (Simple Object Access Protocol) transactions between the server-side code and the mobile clients. A closer look revealed a reference within the communications to another website that did not exist -- it looked like an erroneous variation of a well-known address.
When these specific calls were made to the mobile clients, the ridiculous 50 second+ wait times followed. By itself, this evidence pointed only to a possible "root cause" or "smoking gun." But it was not conclusive. However, the IT team brought the evidence to the application vendor's attention to confirm that the incorrect URL reference was in fact added to code at about the same time users started to complain of bad performance many months ago.
The tables turned right then and there. A fix is now in the process of being made.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment