Load test scenarios for searching article

[michaelhidalgo]

We need to make sure that the Graph Database is not being locked with subsequent and few request when performing search.

[michaelhidalgo]

I found this Package named loadtest : https://www.npmjs.com/package/loadtest It's well documented and the information displayed seems to be meaningful. I'll see which other scenarios can be generated.

[romichg]

This looks promising. Lets see how many random searches we can do (i.e. search for a random string) lets also see how simultaneous navigate requests we can do and full article view requests. An Ideal search would be to take all the words that @DinisCruz had parsed out of the articles, take only unique words, and create parallel search requests, each with a unique word, that does exist. Lets see how many we can do before we bring the DB down :)

[michaelhidalgo]

This is related to https://github.com/TeamMentor/TM_4_0_Design/issues/604

[DinisCruz]

@michaelhidalgo look at these json files for that full list of mappings

[DinisCruz]

also can you trigger this these tests from a mocha test? It might be better to put it on a separate batch of tests

[DinisCruz]

OK, so the DB check for use is now wired and it looks good

@roman87 and @michaelhidalgo can you take it for a test drive?

It is on the https://github.com/TeamMentor/TM_4_0_GraphDB/tree/Issue_504_Load_Test_GraphDB branch (with tests passing: https://travis-ci.org/TeamMentor/TM_4_0_GraphDB/builds/56030859 )

In this version if you generate multiple requests you will see a number of log messages that should look like:

2015-03-26T23:08:05.443Z - info:  method=GET, url=/convert/to_ids/query-6234f2d47eb7
2015-03-26T23:08:05.445Z - info: checking lock: 10 : true
2015-03-26T23:08:05.659Z - info: checking lock: 8 : true
2015-03-26T23:08:05.772Z - info: checking lock: 9 : true
2015-03-26T23:08:05.912Z - info: checking lock: 7 : false
2015-03-26T23:08:06.170Z - info: checking lock: 8 : true
2015-03-26T23:08:06.446Z - info: checking lock: 7 : true
2015-03-26T23:08:06.733Z - info: checking lock: 6 : false
2015-03-26T23:08:06.742Z - info:  method=GET, url=/convert/to_ids/query-b4f75e8db860
2015-03-26T23:08:06.744Z - info: checking lock: 10 : true
2015-03-26T23:08:06.749Z - info:  method=GET, url=/data/query_tree_filtered/query-6234f2d47eb7/query-a002e05770f0
2015-03-26T23:08:07.016Z - info: checking lock: 9 : true
2015-03-26T23:08:07.286Z - info: checking lock: 8 : true
2015-03-26T23:08:07.315Z - info:  method=GET, url=/convert/to_ids/query-a002e05770f0
2015-03-26T23:08:07.541Z - info: checking lock: 7 : false
2015-03-26T23:08:07.969Z - info:  url=/show/query-6234f2d47eb7/query-a002e05770f0, ip=127.0.0.1, agent=undefined
2015-03-26T23:08:07.970Z - info:  user=dinis, action=show, queryId=query-6234f2d47eb7, filters=query-a002e05770f0
2015-03-26T23:08:07.974Z - info:  method=GET, url=/convert/to_ids/query-6234f2d47eb7
2015-03-26T23:08:07.982Z - info:  method=GET, url=/data/query_tree_filtered/query-6234f2d47eb7/query-a002e05770f0
2015-03-26T23:08:08.724Z - info:  method=GET, url=/convert/to_ids/query-a002e05770f0

But I wouldn't expect to the see the Error: [GraphDB] is in use. In fact I would like to know how much traffic we need to sent to TM in order to trigger that message/scenario

Note that his version has the TM Graph REST API cache disabled. This will help to put more load on the GraphDB and trigger the checking lock workflow

[romichg]

No problem: Here you go :)

2015-03-27T14:25:16.148Z - info:  method=GET, url=/convert/to_ids/query-6234f2d47eb7
2015-03-27T14:25:16.174Z - info:  method=GET, url=/data/query_tree/query-6234f2d47eb7
2015-03-27T14:25:16.488Z - info: checking lock: 1 : true
2015-03-27T14:25:16.488Z - info: checking lock: 1 : true
2015-03-27T14:25:16.489Z - info: checking lock: 1 : true
2015-03-27T14:25:16.489Z - info: checking lock: 3 : true
2015-03-27T14:25:16.489Z - info: checking lock: 3 : true
2015-03-27T14:25:16.489Z - info: checking lock: 3 : true
2015-03-27T14:25:16.489Z - info: checking lock: 5 : true
2015-03-27T14:25:16.490Z - info: checking lock: 4 : true
2015-03-27T14:25:16.490Z - info: checking lock: 9 : true
2015-03-27T14:25:16.490Z - info: checking lock: 11 : true
2015-03-27T14:25:16.490Z - info: checking lock: 13 : true
2015-03-27T14:25:16.490Z - info: checking lock: 6 : true
2015-03-27T14:25:16.490Z - info: checking lock: 14 : true
2015-03-27T14:25:16.491Z - info: checking lock: 15 : true
2015-03-27T14:25:16.491Z - info: checking lock: 15 : true
2015-03-27T14:25:16.760Z - info: checking lock: 0 : false
2015-03-27T14:25:16.760Z - info: checking lock: 0 : true
2015-03-27T14:25:16.760Z - info: Error: [GraphDB] is in use
2015-03-27T14:25:16.761Z - info: checking lock: 0 : true
2015-03-27T14:25:16.762Z - info: Error: [GraphDB] is in use
2015-03-27T14:25:16.762Z - info: checking lock: 2 : true
2015-03-27T14:25:16.762Z - info: checking lock: 2 : true
2015-03-27T14:25:16.763Z - info: checking lock: 2 : true
2015-03-27T14:25:16.763Z - info: checking lock: 4 : true
2015-03-27T14:25:16.763Z - info: checking lock: 3 : true
2015-03-27T14:25:16.763Z - info: checking lock: 8 : true
2015-03-27T14:25:16.763Z - info: checking lock: 10 : true
2015-03-27T14:25:16.763Z - info: checking lock: 12 : true
2015-03-27T14:25:16.764Z - info: checking lock: 5 : true
2015-03-27T14:25:16.764Z - info: checking lock: 13 : true
2015-03-27T14:25:16.764Z - info: checking lock: 14 : true
2015-03-27T14:25:16.764Z - info: checking lock: 14 : true
2015-03-27T14:25:16.779Z - info:  method=GET, url=/data/query_tree/query-6234f2d47eb7
2015-03-27T14:25:16.780Z - info: checking lock: 20 : true
2015-03-27T14:25:16.781Z - info:  method=GET, url=/data/library_Query
2015-03-27T14:25:16.782Z - info: checking lock: 20 : true

I did this with this simple script, running around 5-10 of them simultaneously.

while true; do wget http://127.0.0.1:1332/data/library_Query; wget http://127.0.0.1:1332/convert/to_ids/query-6234f2d47eb7; wget http://127.0.0.1:1332/data/query_tree/query-6234f2d47eb7; done & 

@michaelhidalgo maybe your tool gives you better stats?

[michaelhidalgo]

Yeah interesting. I used ApacheBench to generate the request using this syntax :

ab -n 100 -c 100 http://localhost:1332/data/id/article-0026811631be

_-n 1000: ab will send 100 request _ -c concurrent users

Here are the latest results :

Note that at this point cache is not enabled. I will try to see how to automate it to generate new searches when cache is enabled.

[romichg]

I think one way is to come up with a file of random strings, put the strings together in a random pattern of words and then just feed it to the URL.

[DinisCruz]

nice, it will be interesting to see what happens when the cache is enabled

[michaelhidalgo]

I spend more time today with this issue and I think it works fine : Here are the steps I followed :

1. A clean instance of GraphDb and the Design.
2. Using siege, I'm emulating 300 users concurrents, during 1 minute, with 1 second of delay.
3. I generated a txt file with searches URLs, so Siege uses that file to randomly pick up urls and send the request :
4. This is the syntax : michaelhidalgo$ siege -c300 -d1 -t60s -i -f searches.txt

This is how the GraphDb behaves :

[michaelhidalgo]

http://localhost:1332/data/id/article-0026811631be http://localhost:1332/data/id/article-05ae12afcf47 http://localhost:1332/data/id/article-05f70d0c9820 http://localhost:1332/data/id/article-079fa6bf8320 http://localhost:1332/data/id/article-0a879cdedc40 http://localhost:1332/data/id/article-0af26a78d63d http://localhost:1332/data/id/article-0b4a4258cb85 http://localhost:1332/data/id/article-0b85690cb289 http://localhost:1332/data/id/article-0e189f812ff6 http://localhost:1332/data/id/article-0d74e09f3156 http://localhost:1332/data/id/article-12ad6c3c797c http://localhost:1332/data/id/article-141719b1a681 http://localhost:1332/data/id/article-148cd4c75711 http://localhost:1332/data/id/article-158f4a08ce9a