Version 3.1 brings a huge improvement in terms of response time performances.
We've done this to better serve our customers that have more and more distributed worldwide teams. While these customers were deploying Master-Master replication, it came with some constraints in terms of data backup complexity and infrastructure cost.
Starting with 3.1, even a remotely isolated user can use XStudio, still having an extremely responsive interface. Large team and cloud-based users will also see the same benefits of an x6 increase of performance in average.
Based on our internal tests, using real customer data, the improvement ratio is extremely important and up to 'x 38' when placed in the worst conditions.
To provide a much better-perceived response time we have upgraded our data load and caching strategy.
- Data is now loaded incrementally 'per tab' rather than all together 'per object' - so users are not impacted if they do not view/modify some data (e.g. coverage, version, changes ....)
- Full object trees (e.g. tests tree, requirements tree) are now loaded in background
- Many data requests have been optimized for high-volume
- Caching of tree data has been further extended to reduce the number of reload
- The connection string now allows supporting native Data Compression from the RDBMS you use.
Response time, as perceived by users, is the result of a combination of factors from which the most 2 important are:
- Network Latency
- Data Volume transferred
With 3.1 the maximum response time performing the most 'expensive' action you can do in XStudio with high latency network (over 160 ms round trip) with a volume of 100,000 tests is under 10 seconds in 99% of the cases. Well, being in such bad conditions should be rare and we don't think many of our customers have met such ones.
Prior to 3.1 , based on the most 'expensive' action you can do in XStudio, the response time would grow exponentially (see Graphic below). This was making it necessary to deploy a DB replication to support widely distributed user workforce.