The relay needs to get twin information from the chain before it can forward the message to be able to decide if it needs to federate the message to a different relay or serve it locally.
This greatly slow down the routing of a message because for each message the twin information has to be retrieved. To improve this while not risk using a stall twin information, we cache twin information for around 60 seconds before it will be needed to refresh the twin information.
This has a HUGE impact on the performance of the relay because unfortunately we can only fetch twin information sequentially this can cause messages to timeout before they get a chance to be forwarded.
(notice that clients suffer from similar issues)
Suggested solution
Obviously caching is the right solution, it's how the caching is implemented is the problem. We can't ask the chain every time we need twin information, and caching 60 seconds is not enough but also sitting this timeout to a longer time is not a good solution because it also means we may server stall twin info.
What if instead we make the cache permanent (hear me out) twin info (if not in the cache) will have to be fetched from the chain and stored permanently, BUT at the same time, the chain need to listen to chain events (in the back ground) for any twin create/update event and based on that update the cache on the fly. Means that any new twin that is created or updated will reflect in the cache almost in real time. Means the cache will always have a fresh data for the twin without slowing down the process!
The relay needs to get twin information from the chain before it can forward the message to be able to decide if it needs to federate the message to a different relay or serve it locally.
This greatly slow down the routing of a message because for each message the twin information has to be retrieved. To improve this while not risk using a stall twin information, we cache twin information for around 60 seconds before it will be needed to refresh the twin information.
This has a HUGE impact on the performance of the relay because unfortunately we can only fetch twin information sequentially this can cause messages to timeout before they get a chance to be forwarded.
(notice that clients suffer from similar issues)
Suggested solution
Obviously caching is the right solution, it's how the caching is implemented is the problem. We can't ask the chain every time we need twin information, and caching 60 seconds is not enough but also sitting this timeout to a longer time is not a good solution because it also means we may server stall twin info.
What if instead we make the cache permanent (hear me out) twin info (if not in the cache) will have to be fetched from the chain and stored permanently, BUT at the same time, the chain need to listen to chain events (in the back ground) for any twin create/update event and based on that update the cache on the fly. Means that any new twin that is created or updated will reflect in the cache almost in real time. Means the cache will always have a fresh data for the twin without slowing down the process!