-
Notifications
You must be signed in to change notification settings - Fork 264
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
Loading the GUI for prefixes takes more than 60s #947
Comments
Thanks for the report! What "per page" setting are you using for this table view? Decreasing it may help in the interim while we investigate this issue. (I've done some initial profiling of this issue with the Django Debug Toolbar and it doesn't appear that the database queries are the slowest part - something in the page rendering logic instead, perhaps?) |
It's set to 500. I tried reducing it to 250, and it then only takes about 13s - which is much better, but still too long in my opinion... |
Probably the way this will need to be addressed will be with some data model changes - actually representing parent/child prefixes as a tree in the database, using common table expressions, something along those lines. This is somewhat related to our use of django-mptt in other models, and the need to replace it throughout (#510). |
This has also become a show stopper for me lately. I have been playing with a new setting |
It is positively the query in the SELECT "ipam_prefix"."id",
"ipam_prefix"."created",
"ipam_prefix"."last_updated",
"ipam_prefix"."_custom_field_data",
"ipam_prefix"."status_id",
"ipam_prefix"."network",
"ipam_prefix"."broadcast",
"ipam_prefix"."prefix_length",
"ipam_prefix"."site_id",
"ipam_prefix"."vrf_id",
"ipam_prefix"."tenant_id",
"ipam_prefix"."vlan_id",
"ipam_prefix"."role_id",
"ipam_prefix"."is_pool",
"ipam_prefix"."description",
(SELECT COUNT(*) AS "count"
FROM "ipam_prefix" U0
WHERE (U0."prefix_length" < "ipam_prefix"."prefix_length"
AND U0."network" <= "ipam_prefix"."network"
AND U0."broadcast" >= "ipam_prefix"."broadcast"
AND COALESCE(U0."vrf_id", 3def19a1-48cb-4fa9-a98a-5e48a3c24cc0) = COALESCE("ipam_prefix"."vrf_id", 3def19a1-48cb-4fa9-a98a-5e48a3c24cc0))
LIMIT 1) AS "parents",
(SELECT COUNT(*) AS "count"
FROM "ipam_prefix" U0
WHERE (U0."prefix_length" > "ipam_prefix"."prefix_length"
AND U0."network" >= "ipam_prefix"."network"
AND U0."broadcast" <= "ipam_prefix"."broadcast"
AND COALESCE(U0."vrf_id", 3def19a1-48cb-4fa9-a98a-5e48a3c24cc0) = COALESCE("ipam_prefix"."vrf_id", 3def19a1-48cb-4fa9-a98a-5e48a3c24cc0))
LIMIT 1) AS "children"
FROM "ipam_prefix"
LEFT OUTER JOIN "ipam_vrf" ON ("ipam_prefix"."vrf_id" = "ipam_vrf"."id")
ORDER BY "ipam_vrf"."name" ASC NULLS FIRST,
"ipam_prefix"."network" ASC,
"ipam_prefix"."prefix_length" ASC
LIMIT 50
OFFSET 29700
Because there are no direct relationships between prefixes, a full sequential scan is needed, followed by further index scans for parents and children. I don't see a way around that in the current data model. The key to the slowness is the limit in this case. Meaning, try the difference between these two and you will see where the problem is (provided you have this much data):
|
Environment
Steps to Reproduce
Expected Behavior
A snappy respone
Observed Behavior
Load time is more than 60s
Possible workaround
As it seems now, the default is to load all prefixes in all VRFs etc in the background,
but only render the first ones.
Either the query in the backend has to be limited to only load what will be shown,
or:
When accessing the prefix page, nothing is loaded until a specific search criteria is entered.
This criteria can be saved as a default per user
The text was updated successfully, but these errors were encountered: