search

ubiquity-os / ubiquity-os-kernel

1 stars 13 forks source link

Speed Optimization: Configuration Caching #21

Open 0x4007 opened 7 months ago

0x4007 commented 7 months ago

This still requires research on the best approach but currently the bot replies to events in a relatively slow manner. I think that some of the largest time overhead is due to the multiple network roundtrips that are incurred for compiling the configuration for every run.

Some other remarks is that I'm curious to see some type of caching approach because on Cloudflare Workers in our current state of research, it must fetch both the organization and repository configurations within the GitHub webhook event handler function.

This means that before it can respond to the user invoked event, the Worker needs to make a couple of fetches to those repositories and merge the configuration before it can respond.

The configuration is needed to modify the behavior of the Worker response for most situations I can think of so it seems like an optimization that will affect most use cases.

We also made a handler for pushes that validates the yml configurations which could be a good time to write to cache. Maybe we can write the cached configuration to Cloudflare KV storage or something.

Originally posted by @pavlovcik in https://github.com/ubiquity/pay.ubq.fi/issues/135#issuecomment-1943089107

whilefoo commented 7 months ago

That's a cool idea, we can just listen for push events and if the config changed we can save it in Cloudflare KV.

However I don't think this is the bottleneck. I think invoking a workflow dispatch and the time it takes Github to launch the Action runner and execute it, is much larger than just a few network roundtrips.

0x4007 commented 7 months ago

invoking a workflow dispatch and the time it takes Github to launch the Action runner and execute it, is much larger than just a few network roundtrips

I agree. I think we can set up continuous deployment for those repositories on their main branches and then use those Cloudflare Workers deployments as an endpoint instead.

To clarify this topic is not a high priority. It's just an optimization I want to bear in mind as we continue our r&d on the kernel.