Bug #13593
Updated by Lucas Di Pentima almost 6 years ago
A user reported that creating many projects at once resulted in extreme slowdown and eventually crashing the API server unless the create requests were throttled. Creating a project (or any other group) also refreshes the permissions graph in the same transaction. This makes the API call slow, but we intend/expect that other API calls can proceed while the update is in progress, so other (non-permission-modifying) API calls aren't expected to be slowed down. The approach would be: h2. Avoiding impact on other API requests Problem TBD. Try to reproduce. To avoid impacting other api calls, we could use the CONCURRENTLY param on the view refresh execution: https://www.postgresql.org/docs/9.4/sql-refreshmaterializedview.html h2. Faster "create" calls Possible approach, covering both serial and concurrent updates: * Accept -Accept an @async@ param to permission-changing calls "asynchronous update" flag with create/update requests, indicating the client doesn't need a guarantee that would delay the permission graph update for a server configurable number of seconds in the future. is updated when it receives its response.- (moved to #13688) * When updating Update the permission graph asynchronously, use _after_ the @CONCURRENTLY@ parameter to avoid blocking @SELECT@ while it’s being updated. (PostgreSQL 9.4 feature, check API server’s dependency requirements). create/update transaction is committed, and skip redundant updates. Skipping redundant updates: * Use status 202 (Accepted) on async call responses. Acquire lock * Make a performance analysis comparison to make sure Check whether any updates have occurred since the issue is solved. lock was acquired for the existing version of the graph * Update documentation. If so, update graph * Release lock