rawlinp commented on pull request #6017: URL: https://github.com/apache/trafficcontrol/pull/6017#issuecomment-880002324
> only having Read-While-Writer without a small cache would put constant load on the DB, every time a request finishes another will start, constantly saturating the DB The amount of requests going to the DB would be a factor of how many TO instances there are, and if we're running roughly 10 (which is a lot IMO), TODB should be able to handle 10 concurrent requests for the same thing without tipping over. I know `t3c` requests all the data at once, so let's say 10 concurrent requests per route. That still doesn't seem like something that should overload TODB. What I'm getting at is that RWR without a small cache probably does improve performance quite a bit, but it doesn't have the data consistency issues that a timed cached has. Maybe RWR alone is enough? Queueing updates and t3c processing those changes is just one of the races. It sounds like we can solve _that_ problem, but there is still the problem that if I make a change, I might not be able to read that change back for however long the cache time is. So now anything that makes changes needs to understand that and work around it. I think that is actually why the TO API tests are failing -- they can't read their writes back immediately, which fundamentally breaks the tests unless a 1 second sleep is inserted after all writes (which would be absurd). We definitely want this feature to be tested, so I wouldn't want us to just turn it off for the TO API tests. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
