Project

General

Profile

Bug #13593

Updated by Lucas Di Pentima about 5 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 

Back