GitHub user ArtyManyMan edited a discussion: Slow loading of large published dashboard in Superset 3.0 - API responses delayed compared to draft copy
Hi Superset team and community! 👋 I’ve encountered a performance issue in Apache Superset 3.0 on our production environment, and I’d appreciate any insight or guidance. **Environment:** - **Superset version:** 3.0 - **Backend DB:** PostgreSQL - **Setup:** Gunicorn + Celery - **Auth:** LDAP ### **Problem** We have a dashboard with: _~70 charts Published state Assigned to 7 roles ~10 users with access_ When a user opens this dashboard, the initial page load takes ~1 minute. Importantly, the slowest part is not the chart queries. The slowness is caused by the initial metadata API calls: _/api/v1/dashboard/<id> /api/v1/charts /api/v1/datasets_ These 3 calls take most ### Comparison scenario: I created a copy of the same dashboard: _It’s not published It’s assigned to no roles or users, except the creator_ This dashboard opens in ~5 seconds. ### What I’ve checked so far: I enabled SQLALCHEMY_ECHO = True to compare SQL queries - the queries between the two cases look very similar I compared the HTTP responses from /api/v1/dashboard etc - also very similar in size and structure. ### Questions: What is the root cause of this slowdown when the dashboard is published and assigned to roles? Is it related to permission checks, security manager evaluations, or something else in the access control system? Are there known performance bottlenecks in get_user_roles(), security_manager, or ownership filtering for large dashboards? Any hints where to dig deeper (especially related to RBAC or ownership logic) would be greatly appreciated. Thanks in advance for any help or discussion! GitHub link: https://github.com/apache/superset/discussions/33785 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
