Status page eats all the CPU when large
Bug #1326170 reported by
James E. Blair
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Zuul |
New
|
Undecided
|
Unassigned | ||
Bug Description
When the status page is large, it ends up consuming quite a bit of CPU time. Some of this is likely generating the JSON, and some is the gzip compression, which apparently does a lot of work in python.
We should do the following:
* Ensure that openstack's zuul apache is configured to gzip when proxying
* Stop gzipping internally
* Consider having zuul cache the constructed JSON internally for a very short time (eg, 1 second)
* Consider having something in front of zuul that caches for, eg, 5 seconds (optional, and can do later)
Revision history for this message
| Antoine "hashar" Musso (hashar) wrote | #1 |
To post a comment you must log in.
For caching status.json, IIRC the status page has a cache breaker ?<timestamp>, something to take in consideration.
Would it make sense to split the web server out of the main Zuul process? Just like the zuul merger got split. This way we could have it run on another host / independently from the main scheduler.