Closed Bug 1301741 Opened 4 years ago Closed 4 years ago

Stand up a 6th webhead


( :: Infrastructure, defect)

Not set





(Reporter: dylan, Unassigned)



Per Bug 1301541, it would be valuable to separate out the requests that hit the bzapi to a dedicated webhead. How much effort would it be to stand up a new webhead for this? Is this possible in a small (say, 1 month) time-frame?
Should be possible. I'm out the last half of September, but will try throwing dhouse or dividehex at it.

* What percentage of the traffic is bzapi? 
* Is one dedicated webhead enough?
* What is involved in separating out requests, is this a matter of configuration or will it require a new bmo release?
Flags: needinfo?(dylan)
What can be done to expedite getting more webheads stood up?
Flags: needinfo?(klibby)
We have talked in the past about having a dedicate webhead or more for all API requests so could we combine rest/jsonrpc/xmlrpc/bzapi together for routing to this dedicated system? Or would that not solve the bzapi problem?

for measuring performance, it would be helpful to split out REST and bzapi. Right now, we know bzapi is slower so splitting it out speeds up all other requests.
Flags: needinfo?(dylan)
note to self: set up a failover pool in zeus, so that if web6 dies the traffic goes to another node rather than failing
Flags: needinfo?(klibby)
Taking out the part about redirection, that goes in a separate bug
Summary: Stand up a 6th webhead and redirect /bzapi/ queries to it → Stand up a 6th webhead
Blocks: 1304171
Blocks: 1035804
No longer blocks: 1301541
fixed the perl dependencies that was causing apache to not start. perl-IO-Compress from rpmforge conflicted with perl-core, which is required but not actually installed anywhere (the parts that bmo needed were getting pulled in from other stated deps in puppet).

updated nagios checks for it as well.
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.