Allow to set values for MaximumNumberOfResults and MaximumNumberOfEvents

[danilvoe]

Describe the feature request

There is a need to store more monitoring data. In particular the event.

Why do you personally want this feature to be implemented?

It is required to have data for a longer period of time, when checking every minute, data is stored for a small period of time.

How long have you been using this project?

No response

Additional information

I understand why such numbers are indicated in these constants (MaximumNumberOfResults and MaximumNumberOfEvents), so it’s easier to implement the optional setting of these values. By default, you can leave 100 and 50. :)

[mani9223-oss]

@danilvoe What is the response time for you for this API api/v1/endpoints/statuses?page=1. Is it because of MaximumNumberOfResults? For me, it's taking more than 25 secs and fails at the end. I am using PSQL as my DB.
@TwiN Any reason for this slowness?

[TwiN]

@mani9223-oss It definitely shouldn't take that long. How many endpoints do you have?

[mani9223-oss]

@TwiN I have 292 endpoints. What are the recommended hardware requirements for PSQL DB? I have increased my DB resources to 2vCPU (from 1vCPU) and 4GB RAM (from 2GB) and reduced maximumNumberOfResults to 10. So now it's 15 secs. But I still feel 15 secs is long.

[TwiN]

@mani9223-oss I'll try to see if I can replicate it on my end when I have some time, but if it really is that slow, then yeah that'll have to be fixed. Might need to finally implement endpoint paging (currently, only result paging is implemented).

In the meantime, you can try using memory instead of postgres as storage type - it'll be much faster; at the cost of persistence.

[juanfont]

@TwiN would you accept a PR making this fields configurable from the config.yml?

[TwiN]

@juanfont Sure! It'll also require some changes on the front-end.

You'll also probably have to use this and this to pass the parameter from the backend to the frontend so that the frontend knows how many pages there are.