You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In comparison to REST world, Appwrite's functions introduces new delay when the request is in waiting state. There is no way to prevent this as you never know how many requests you can expect.
The problem with this is that at some point you might create more executions than you can handle and you will end up in an infinite loop where new executions take multiple hours to run.
The solution I can see is to introduce deleteExecution in the API (both client and server-side) that would simply switch the status of the execution from "waiting" to "stooped" or "timed-out".
Specific example:
A great example of this is a monitoring tool that pings your websites every minute. Sure, with 10 websites and an average ping time of 200ms, everything will go smoothly. The problem is if you have too many websites or your websites slow down and ping time will go up to 5 seconds. With 100 websites and 5 second response time, We will need 500 seconds of execution time every 1 minute to keep up. This could be possible if we scale the application, but we didn't expect this many websites at lunch... Also, running too many pings at the same time will make information responseTime irrelevant, since this might not be the issue on the website itself, but on the monitoring server.
What the result would be? After few days, we would run few hours old executions. If we don't address this, we could end up with millions of executions waiting in the queue.
A solution to this problem could be a cleanup function that lists all executions and if they were created more than 60 seconds ago, simply stop (delete) the execution. Ten we just shuffle the order in which we create ping executions and in the end, we will still have a fully functional app with no infinite bottle-neck. The only disadvantage is that some pings will be missing for some websites, but that is a natural problem if we don't scale our app.
General use-cases:
Server spawns a lot of executions but the server is not scaled properly. We want to delete old executions so new ones can run. We pretty much invert the current behaviour where appwrite runs the oldest executions. By removing them regularly, it will run our latest tasks
Any execution that takes more than a few seconds (mainly due to waiting on the queue) and was triggered by the client should be cancelable with a button
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
In comparison to REST world, Appwrite's functions introduces new delay when the request is in
waitingstate. There is no way to prevent this as you never know how many requests you can expect.The problem with this is that at some point you might create more executions than you can handle and you will end up in an infinite loop where new executions take multiple hours to run.
The solution I can see is to introduce
deleteExecutionin the API (both client and server-side) that would simply switch the status of the execution from "waiting" to "stooped" or "timed-out".Specific example:
A great example of this is a monitoring tool that pings your websites every minute. Sure, with 10 websites and an average ping time of 200ms, everything will go smoothly. The problem is if you have too many websites or your websites slow down and ping time will go up to 5 seconds. With 100 websites and 5 second response time, We will need 500 seconds of execution time every 1 minute to keep up. This could be possible if we scale the application, but we didn't expect this many websites at lunch... Also, running too many pings at the same time will make information
responseTimeirrelevant, since this might not be the issue on the website itself, but on the monitoring server.What the result would be? After few days, we would run few hours old executions. If we don't address this, we could end up with millions of executions waiting in the queue.
A solution to this problem could be a cleanup function that lists all executions and if they were created more than 60 seconds ago, simply stop (delete) the execution. Ten we just shuffle the order in which we create ping executions and in the end, we will still have a fully functional app with no infinite bottle-neck. The only disadvantage is that some pings will be missing for some websites, but that is a natural problem if we don't scale our app.
General use-cases:
All reactions