Limit of measurements

[jimaek]

Limit of measurements

[jimaek]

I think the complexity comes later, like the user asks to do 200 tests and during the tests 10 probes go offline. Now the system has to wait a timeout and then figure that that it needs to deduct 190 points. And what if during the timeout the user sends another measurement for 200 tests? In theory the system would allow it since its still waiting for the previous results.

If we do the deduction immediately, before we even run any tests, based on how many points we have to deduct in theory assuming perfect conditions we solve almost all complexities. Of course the system will not guarantee 100% accuracy, but it should be fine. That part can be solved by better heartbeats, notifying the users and generous limits.

[patrykcieszkowski]

so the penalty points should be assigned after the result is back? Sounds like we gonna have to store user's ip address alongside the measurement request.

[jimaek]

Probably not when its back because it would be too complicated, but during the routing logic when the API is figuring out which nodes should get run the test. So the API can see that since it has 50 probes online available for the test it can already deduct 50 points from the 200 limit right then.

[patrykcieszkowski]

it actually wouldn't be that complex, if we had the IP address of the client; the rate limiting library we use allows us for manual points manipulation. If we don't wanna store requester's details, we can obfuscate the ip address and use it as a key instead.

[jimaek]

measurement = a single POST requesting a number of tests to be made by setting the limit parameter
test = the command the probes process. A measurement with limit of 10 would result in 10 tests

My proposed limits are below. There is no real reasoning behind them, just what feels right, small enough to avoid abuse, but large enough to be useful and not run out in the middle of testing. Feel free to comment.

Global for everyone:

• 100 POST requests per minute per IP
• Unlimited GET
• Max total 500 probes per measurement
• Remove limit per location (current 200?)

No auth - Per IP:

• 100 tests per hour

Free user - API key present - No IP limits

• 250 tests per hour

Paid user - API key present - No IP limits

• $5 for 2000 credits? Where 1 credit = 1 test

So instead of creating plans I suggest we simply add credits based on the $ sponsored.
That should work both for one-time donations and subscribers.

So if you just need to run a few tests for a single problem you donate one-time $5 to get more credits. But if you're writing a script or app that will use Globalping continuously then you would subscribe to a monthly GitHub Sponsors plan.

If a user has 1000 credits and starts running tests, he will first eat up the free 250 tests and then instead of get rate-limited he will go above the limit by using the credits until they run out.

This would require a complete credits system that can:

• Understand hourly limits that reset and dont add up
• Pick up GitHub Sponsors changes. One-time/subscription/cancelled...
• Adopted probes generate credits every day that can be used
• Admin can add/remove credits per user

[MartinKolarik]

@jimaek since the auth and related features will be live soon, can we agree on the final limits here to use and document? I think the numbers above are fairly reasonable, maybe for credits, we could go with a simple $1 = 1k credits. Right now, we actually have $1 = 10k credits, which seems too high.

[jimaek]

I made a table here, check and comment where needed https://docs.google.com/spreadsheets/d/1wxpOye5Io9bgeeMO8KDq2dMbpfNAHj4H0yATsd1BeMk/edit#gid=0

[MartinKolarik]

Closing as this is partly implemented, and the rest is covered by other open issues + the table.