Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance issues by many reports in the database #77

Open
filipwoz opened this issue Apr 30, 2021 · 4 comments
Open

Performance issues by many reports in the database #77

filipwoz opened this issue Apr 30, 2021 · 4 comments

Comments

@filipwoz
Copy link

Unfortunately the new KLOV has still the same problem as the old one: When database is growing the performance of loading the reports is continuously falling until it exceeds user acceptance boarder.

I observed it for example with the following number of records in the Mongo collections:

Table | Record Count
project | 18
report | 340
test | 15.230
log | 198.085
media | 25.388
exception | 502

After deleting projects and getting below the log < 110.000, media < 15.000 it was acceptable again, but sorry it is quite unprofessional that here no strategy is offered to help that situation. Have you through an optimizing the queries?

This ways actually my main reason why I have not bought the KLOV professional licence for the old version and why I evaluated the new one. In such a shape I am also no willing to spend money on the new KLOV.

@filipwoz
Copy link
Author

filipwoz commented Oct 1, 2021

I have helped myself temporarily by writing a utility working on MongoDB level which is deleting reports older than X working days and X is configurable per KLOV project name. I am scheduling it every day, keeping my KLOV usable this way.

But at the end the performance is an issue here and you should work on it. I have an impression that you are not using the advantages of No-SQL DB properly. Why to use No-SQL when at the end you are keeping the test reports decomposed in different collections and you have to join it before rendering. With such data model a normal SQL DB would be quicker in my opinion.
In a No-SQL DB like Mongo you could have been saving the complete test reports as JSON documents in one collection (report/test/log/exception all in one collection) without a need to join anything after that. Then the real benefit of No-SQL would be utilized. I am not sure about it because I am also new to No-SQL but this is how I understand it. No-SQL at the end should boost performance and not the other way round - it is its main benefit.

@iamakshayshar
Copy link

@filipwoz : if possible, can you please share the utility and its documentation with me.
email : [email protected]

Thanks in advance.

@parkerqian
Copy link

I have helped myself temporarily by writing a utility working on MongoDB level which is deleting reports older than X working days and X is configurable per KLOV project name. I am scheduling it every day, keeping my KLOV usable this way.

But at the end the performance is an issue here and you should work on it. I have an impression that you are not using the advantages of No-SQL DB properly. Why to use No-SQL when at the end you are keeping the test reports decomposed in different collections and you have to join it before rendering. With such data model a normal SQL DB would be quicker in my opinion. In a No-SQL DB like Mongo you could have been saving the complete test reports as JSON documents in one collection (report/test/log/exception all in one collection) without a need to join anything after that. Then the real benefit of No-SQL would be utilized. I am not sure about it because I am also new to No-SQL but this is how I understand it. No-SQL at the end should boost performance and not the other way round - it is its main benefit.

I have helped myself temporarily by writing a utility working on MongoDB level which is deleting reports older than X working days and X is configurable per KLOV project name. I am scheduling it every day, keeping my KLOV usable this way.

But at the end the performance is an issue here and you should work on it. I have an impression that you are not using the advantages of No-SQL DB properly. Why to use No-SQL when at the end you are keeping the test reports decomposed in different collections and you have to join it before rendering. With such data model a normal SQL DB would be quicker in my opinion. In a No-SQL DB like Mongo you could have been saving the complete test reports as JSON documents in one collection (report/test/log/exception all in one collection) without a need to join anything after that. Then the real benefit of No-SQL would be utilized. I am not sure about it because I am also new to No-SQL but this is how I understand it. No-SQL at the end should boost performance and not the other way round - it is its main benefit.

agree with you .
My other problem is that my testng.xml includes so many case (perhaps more then 800) .Every case will output log info .
At the end the total document is more then 16MB , mongodb can not hander that @iamakshayshar

@iamakshayshar
Copy link

I have helped myself temporarily by writing a utility working on MongoDB level which is deleting reports older than X working days and X is configurable per KLOV project name. I am scheduling it every day, keeping my KLOV usable this way.

But at the end the performance is an issue here and you should work on it. I have an impression that you are not using the advantages of No-SQL DB properly. Why to use No-SQL when at the end you are keeping the test reports decomposed in different collections and you have to join it before rendering. With such data model a normal SQL DB would be quicker in my opinion. In a No-SQL DB like Mongo you could have been saving the complete test reports as JSON documents in one collection (report/test/log/exception all in one collection) without a need to join anything after that. Then the real benefit of No-SQL would be utilized. I am not sure about it because I am also new to No-SQL but this is how I understand it. No-SQL at the end should boost performance and not the other way round - it is its main benefit.

I have helped myself temporarily by writing a utility working on MongoDB level which is deleting reports older than X working days and X is configurable per KLOV project name. I am scheduling it every day, keeping my KLOV usable this way.

But at the end the performance is an issue here and you should work on it. I have an impression that you are not using the advantages of No-SQL DB properly. Why to use No-SQL when at the end you are keeping the test reports decomposed in different collections and you have to join it before rendering. With such data model a normal SQL DB would be quicker in my opinion. In a No-SQL DB like Mongo you could have been saving the complete test reports as JSON documents in one collection (report/test/log/exception all in one collection) without a need to join anything after that. Then the real benefit of No-SQL would be utilized. I am not sure about it because I am also new to No-SQL but this is how I understand it. No-SQL at the end should boost performance and not the other way round - it is its main benefit.

agree with you .
My other problem is that my testng.xml includes so many case (perhaps more then 800) .Every case will output log info .
At the end the total document is more then 16MB , mongodb can not hander that @iamakshayshar

Yes, this is also the issue with Klov. One other problem is lack of support. 😟

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants