Inaccurate Response Timer
have other external tools measuring the response time (Introscope as well as some database inserts) of an http soap request, and the response time reported by soapUI isn't even close, relatively speaking, to the response time reported by Introscope and the database records, which are consistently similar to each other.
For example, we have the following setup: soapUI makes the http request to the server. When the request hits the server Introscope starts its timer. The application picks up the message and a timestamped database record is written after the objects are deserialized. The message is processed by the application, another timestamped record is written to the database, the response is serialized, Introscope stops its timer, soapUI receives the message. So the timing should look something like this: (soapUI start (Introscope start (database start, database stop) Introscope stop) soapUI stop). If each measurement was accurate you would expect the database time delta to be a little less than Introscope, which should be a little less than soapUI. In reality, I got the following, in one real world example:
database: 1523 ms
Introscope: 1794 ms
soapUI: 666 ms
The soapUI duration, which should be the longest, was half as short as the others.
Given this, I can't effectively use soapUI to test the SLA of my services for even one request, let alone under a load. I've tried this in both soapUI 3.6.1 and soapUI 4.0.1.
For example, we have the following setup: soapUI makes the http request to the server. When the request hits the server Introscope starts its timer. The application picks up the message and a timestamped database record is written after the objects are deserialized. The message is processed by the application, another timestamped record is written to the database, the response is serialized, Introscope stops its timer, soapUI receives the message. So the timing should look something like this: (soapUI start (Introscope start (database start, database stop) Introscope stop) soapUI stop). If each measurement was accurate you would expect the database time delta to be a little less than Introscope, which should be a little less than soapUI. In reality, I got the following, in one real world example:
database: 1523 ms
Introscope: 1794 ms
soapUI: 666 ms
The soapUI duration, which should be the longest, was half as short as the others.
Given this, I can't effectively use soapUI to test the SLA of my services for even one request, let alone under a load. I've tried this in both soapUI 3.6.1 and soapUI 4.0.1.