Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[discussion] Reduce startup time #90

Open
jason-curtis opened this issue Mar 18, 2024 · 6 comments
Open

[discussion] Reduce startup time #90

jason-curtis opened this issue Mar 18, 2024 · 6 comments

Comments

@jason-curtis
Copy link

jason-curtis commented Mar 18, 2024

Spinning this discussion off from prisma/prisma#12735 (comment) .

Yates provides a straightforward way to add RLS to Prisma-Postgres setups, but there is overhead at startup:

This compute and check process adds some overhead to the server startup time, on our production system at Cerebrum, we have 148* default abilities and 133 custom abilities and it takes ~2.5s to get through the setup process for Yates.

In serverless configurations, 2.5s on startup of each compute instance can be substantial. Are there ways that we can reduce the startup time? Maybe by moving the DB role validation to a script that can be run asyncronously as part of a build/deploy process?

@LucianBuzzo
Copy link
Contributor

@jason-curtis I'm open to offering DB setup as a separate process, allowing a migration step to be run separately.
Something like npx yates migrate, and a flag in the setup function that skips the migration code.
I would also like to see if the setup code can be optimized for reduced startup time, as I think there is low hanging fruit that will improve performance without modifying the interface.
In a serverless architecture, what's your threshold for an "acceptable" startup time? Obviously the faster the better, but having a target would be good.

@jason-curtis
Copy link
Author

Something like npx yates migrate, and a flag in the setup function that skips the migration code.

Love this! Maybe npx yates sync? Looks like createRoles is already organized in a way that would make this easy to factor out https://github.com/cerebruminc/yates/blob/master/src/index.ts#L558 👍

I would also like to see if the setup code can be optimized for reduced startup time, as I think there is low hanging fruit that will improve performance without modifying the interface.

That would be great! Like maybe only generate the roles that are actually used, rather than all of the generic CRUD roles?

target

Hmm, off the cuff, 100ms would be an easy yes. I'm assuming here that the vast majority of the startup time is mostly due to interaction with the DB, and that the npx yates migrate approach would cut it way down. It would be good to know how much the startup time is compute (/might scale with the number of models) vs. db time.

@LucianBuzzo
Copy link
Contributor

LucianBuzzo commented Mar 28, 2024

@jason-curtis With the latest v3.5.0 release, subsequent startup time is ~100ms for our big schema (309 abilities), and I think there is still some more performance that can be squeezed out of the system.
Initial bootstrap is still about the same time (assuming you have never run Yates before), but I've been able to make a lot of improvements in how abilities are checked to see if we need to update/create them. This means that once the initial abilities are created, the startup time is really fast. If you make changes to abilities later down the line, only the affected abilities will be changed in the DB, meaning that you won't see much slowdown there either.

@LucianBuzzo
Copy link
Contributor

That would be great! Like maybe only generate the roles that are actually used, rather than all of the generic CRUD roles?

This is an area where we can get some more speedup I think

@hongkongkiwi
Copy link

hongkongkiwi commented Apr 12, 2024

I would really love to have support for creating policies in a migration step instead. One of the things I like about Prisma is that it generates a client statically that can be pulled in based on the schema.

Doing live DB modifications at startup seems to bypass that logic completely and could make migrations more difficult.

It would be great to have an option so that yates can just perform checks based on the schema but not actually perform any updates. Then be able to have a separate migrate step that can be run.

@sebmellen
Copy link
Member

It would be great to have an option so that yates can just perform checks based on the schema but not actually perform any updates. Then be able to have a separate migrate step that can be run.

@hongkongkiwi this is not something that we currently need for our use-case, so we won't be able to dedicate time to it. However, if you can open a PR for this, we'd love to review it and merge it in. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants