On Mar 26, 2018, at 2:45 PM, Warren Young <war...@etr-usa.com> wrote: > > On Mar 26, 2018, at 2:15 PM, Svyatoslav Mishyn <svyatoslav.mis...@gmail.com> > wrote: >> >> Here are results of r.sh when stress.sh was run (and all RAM was used >> on VPS):
I’ve thought a bit more about this stress.sh script. It is based on ab, which I presume is the Apache Benchmark program. You aren’t giving it -C, which means it’s just bouncing off that URL and sending you back to the login page on each HTTP hit. Thus, it is not at all like a real user trying to use the fossil-scm.org repository remotely. Monitor your HTTP traffic to the Fossil server, and I think you’ll see that you aren’t actually pulling vdiffs with this test. > It is bad science to change more than one variable at a time. You’ve got a > multiply confounded result set here. It might help to list the confounding factors: 1. Different network path between the two servers under test. 2. Different hardware for each server. 3. Probably different VPS technology on each host. 4. Different repository? (It’s not clear to me whether you’re working with a clone of the same repo on both sides.) 5. Real users vs ab(1) faux users. You can’t isolate causes until you control for each of these variables. On top of that, you’re taking Fossil’s reported time deltas as if they’re high-quality benchmark data, when I’ve already shown that the numbers are biased by +1ms, which is on the order of the time differences you’re working with. You need to be getting your timing information from a purer source. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
