Issue in SQL testcases including ExecuteBatch function
kishan-k2io opened this issue · 6 comments
Hi
I was using the Owasp benchmark application for testing purpose. During testing the SQL APIs, I found that sometimes DB was responding very slowly.
On debugging, I found that Some of the SQL testcases were using executeBatch function and the connection object "conn" was a static object due to which we append the SQL in existing SQL statement. In this way SQL queries in "stmt" object were accumulating all the queries on every request.
e.g. If I run 5000 http requests for SQL testcase BenchmarkTest02647 then we will start with 1 query in stmt, on next request there will be two queries and.... so on. So on 5000th http request, there will be total 5000 SQL queries to be executed in batch leading to performance degradation for Database. and this number will continue to increase when we increase the number of request.
Testcase on which issue can be reproduced: BenchmarkTest02647
OK. I'm happy to fix all the executeBatch tests if you can explain to me the best way you think it can be fixed. Is there a way to discard any previous queries on each request? Or create a new connection object each time in order to throw away the previous queries? I'll admit I haven't focused on performance much, but happy to help make it better when issues are identified.
Hi
According to me, the best way will be to create a new statement on every request.
E.g. in this function, we should avoid checking for statement as NULL and everytime create a new connection object and it will even not require storing the statement object.
https://github.com/OWASP-Benchmark/BenchmarkJava/blob/master/src/main/java/org/owasp/benchmark/helpers/DatabaseHelper.java#L119
Awesome. Any chance you could fork the project, implement the change, test it, and if it works, issue a pull request for me to merge the change in? Seems like a quick fix.
Yeah, I will perform the required changes and then will create a PR
Hi @davewichers
I have created a PR with the fix for above issue.
#210
This was fixed when #210 above was merged.