Closed Bug 408112 Opened 18 years ago Closed 18 years ago

Progressive rendering of Bugzilla pages broken

Categories

(mozilla.org Graveyard :: Server Operations, task)

task
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bugzilla-mozilla-20000923, Assigned: mrz)

References

Details

As best I can tell, since the move to the load balancing cluster, all Bugzilla pages which are meant to render progressively (search results, dependent bugs in "Processed bug" page) are no longer doing so. Instead, they appear to have the entire response buffered up at the mozilla.org end and sent all at once. This affects the perceived page loading speed quite badly in some cases.
Summary: Progressive rendering of pages broken → Progressive rendering of Bugzilla pages broken
Assignee: server-ops → justdave
Component: Server Operations → Bugzilla: Other b.m.o Issues
QA Contact: justin → reed
Component: Bugzilla: Other b.m.o Issues → Server Operations
QA Contact: reed → justin
Component: Server Operations → Bugzilla: Other b.m.o Issues
OS: Windows Vista → All
QA Contact: justin → reed
Hardware: PC → All
This would have to be the Netscaler's fault. Nothing's changed in the application.
Assignee: justdave → server-ops
Component: Bugzilla: Other b.m.o Issues → Server Operations
QA Contact: reed → justin
Need some more work trying to reproduce this so we can watch it while it happens and see what's going on. I'll attempt later tonight.
Assignee: server-ops → justdave
OK, successfully reproduced... this is real, and it is the Netscaler. If I make a mass-change to a list of bugs, hitting the back-end server directly (I tested with mrapp51) I get the output from each bug touched displayed on my screen as the mail gets sent, one at a time. If I do the same via the public IP that goes through the Netscaler, then it doesn't show me anything until all of the changes have completed. So the Netscaler is holding the content until it's complete before forwarding it to the end-user, instead of passing it through as it gets it.
Assignee: justdave → mrz
FYI to those watching, we have a case open with Citrix, and looks like there's activity on it, so we might have a fix soon.
Appears to be an issue with the Netscaler's HTTP compression. To test, I added a compression policy to match on the HTTP Host header and do a NOCOMPRESS. Progressive rendering is no longer "broken" at the expense of not compressing content. Citrix is still investigating.
Appears to be an issue with the compression engine buffers. In a nut shell, the Netscaler is waiting for enough data to come in before it can run it's compression algorithm. This causes the page to stall until it's done. I suppose on a suffiently large page, where the buffers do get filled up, the page would appear to progressively render. The buffer size is global and I'm not willing to to change that globally. The NOCOMPRESS policy rule is doing what everyone is used to so I'm marking this FIXED.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.