Details
-
Task
-
Resolution: Won't Fix
-
Major
-
2.5.1, 3.0
-
Security Level: Public
-
Single Node running version 3.0.0 enterprise edition (build-918). Running on VirtualBox, assigned 8 vCPUs and 8GB memory. (host has 24 cores, 128GB RAM).
Description
Hi Alk,
I can demonstrate the behaviour of views periodically taking 2 orders of magnitude longer with 3.0.
(Similar to the issue we were investigating relating to Stats Archiver).
See output-3.0, x-axis is just a count of view queries. Test ran for ~53 minutes and completed 315408 view (~100 second). The y-axis is view response time (in seconds).
In general the response time is < 0.01 of a second. However occasionally (9 out of 315408 views) it takes > 0.1. This may be considered acceptable in the design of the Server, but wanted to get confirmation.
To replicate the test, run...
while true; do ./curlscript.sh >> times2.txt 2>&1 ; done
I have provided curlscript.sh as an attached file.
The generated workload is test data from the same customer that hit the Stats Archive Issue
Create a bucket named "oogway" and then do a cbtransfer of the unpacked backup.tgz file (see attached).