-
Notifications
You must be signed in to change notification settings - Fork 164
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
Slow route server config generation with v6.0.0. #732
Comments
Thanks for the detailed report @ichilton. It looks like the queries did get less optimal in v6.0.0. This is a combination of Doctrine ORM vs Laravel Eloquent; their hydration methods (or at least the way we were doing it); and the actual query structure itself. Regardless, we've known for sometime that the generation time was quite sub-optimal and looking at that has been on the list. The tl;dr is that in commit b852c1f we've gotten the speed / usage down as follows:
NB: this is on my development laptop with local MySQL and webserver. YMMV for production environments but the speed up should be proportional. This is now live and working on release-v6 and once we've watched it for a couple days we'll stamp a new release. There is a further optimisation that could be made which would probably reduce the memory usage but push up the generation time - I think the above is okay for now. Anyway, route servers are top-tier production services so we'll iterate in baby steps. Caching Detail for Those InterestedWhen we refresh the database's IRRDB records for prefixes and ASNs (per these instructions), we now also cache those arrays on a per-customer and per-protocol basis to the file-backed caching system. We specifically use the file-based system here to not push memcached / redis memory up for these large data sets. The goal is not lightening fast access but rather to avoid querying the database. The caching itself is not done at the point where bgpq3 returns the data. This would be the ideal place to do it but that would yield randomly ordered data. Now, naturally, the Bird BGP daemon doesn't need this ordered but as engineers it's useful: we often diff generated configs when iterating changes - unordered prefix sets cause diffs with tens of thousands of changes; our continuous integration static files would also fail; and lastly when actually looking through the config to solve issues, ordering is useful. So. the IRRDB update scripts will run longer because of this. These are background processes that run automatically so this is a compromise worth living with. For now at least. |
Hi @barryo, Thank you for this! - I have tested this and it is indeed really fast now! Running the above tests again on 6.1.0, I now see: v4: 0m6.559s Thank you! Ian |
ISSUE TYPE
Bug Report
OS
Ubuntu 20.04
VERSION
ENVIRONMENT
CONFIGURATION
SUMMARY
Route server configuration is very slow compared to our old host on 5.8.0.
We have set up a new host with Ubuntu 20.04, IXP Manager v6.0.0, PHP 8.0 (FPM), Nginx.
Old host is the same spec VM, on the same VM cluster, but running Ubuntu 18.04, IXP Manager v5.8.0, PHP 7.3, Apache.
Same MySQL server, using a copy of the production database (with migrations ran for v6.0.0).
STEPS TO REPRODUCE
EXPECTED RESULTS
Similar results to the old host/version.
ACTUAL RESULTS
v5.8.0:
v4: 1m11.659s, 0m55.893s, 1m11.338s, 0m51.738s
v6: 0m33.376s, 0m32.611s, 0m33.523s, 0m34.540s
v6.0.0:
v4: 2m56.270s, 2m53.221s, 2m44.164s, 2m47.211s
v6: 0m55.845s, 0m54.098s, 0m58.139s, 0m59.906s
IMPORTANCE
RELEVANT LOGS
The text was updated successfully, but these errors were encountered: