Closed
Bug 690453
Opened 14 years ago
Closed 14 years ago
port fxfeeds to TrafficScript rule
Categories
(mozilla.org Graveyard :: Server Operations, task)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: mrz, Assigned: mrz)
Details
No description provided.
Assignee | ||
Updated•14 years ago
|
Assignee: server-ops → mrz
Group: infra
Comment 1•14 years ago
|
||
In the meantime we're going to just move this directly off of the Ace in SJC and over the the PHX1 Zeus cluster.
IP 63.245.217.212 allocated for this, and added to Zeus. Need to set up the vserver and point it at the static pool... looks like the static pool in phx is already set up for fxfeeds, just like the one in sjc is.
Assignee | ||
Comment 2•14 years ago
|
||
jake, this is way more complex than i thought. Several of those are regex, not sure how to do that with a hash.
Plus, you still need a vserver to point at an active pool otherwise the whole vserver is offline. You could dummy something up I guess.
Look at zlb-stage01 and the fxfeeds rule but it's something like:
$fx = [ ... bunch of key/value pairs ...];
$path = http.getPath();
http.redirect($fx[$path]);
Comment 3•14 years ago
|
||
(In reply to Jake Maul [:jakem] from comment #1)
> In the meantime we're going to just move this directly off of the Ace in SJC
> and over the the PHX1 Zeus cluster.
>
> IP 63.245.217.212 allocated for this, and added to Zeus. Need to set up the
> vserver and point it at the static pool... looks like the static pool in phx
> is already set up for fxfeeds, just like the one in sjc is.
With the current state of zeus in phx1 I'd rather not add this load to it..
We still don't have a solid answer as to why the pp-zlb nodes have problems talking to each other, and we are walking a fine line of this issue affecting our services on that cluster.
Comment 4•14 years ago
|
||
Agreed... we had discussed this and I'd already forgotten about it.
At this time, fxfeeds is in a DNS round-robin between acelb/zlb01.nms and pm-zlb-amo01.
The ACE is still handling *far* more traffic though, even though the TTL on that record is only 60s. Don't know what we can do about this.
We tried bringing this up on pm-zlb-generic02, but apparently the load was too much for it... don't know why, exactly.
Comment 5•14 years ago
|
||
This is appearing to be somewhat non-trivial, because some of the redirects are actually regex's. It's probably still doable, but we'd need to be more careful.
However, it's also more or less unnecessary now. Jeremy and I brought this up on Edgecast CDN, and it's working very well there with a nice high cache hit rate.
We also removed one of the Zeus TS scripts for this already in place, and replaced it with some simple mod_expires settings on the server nodes. The other pre-existing TS is still in place because it's needed to ensure that Zeus caches properly.
fxfeeds is being served from pm-zlb-generic02, pm-zlb-amo02, pm-zlb-amo03, and ams-zlb*.nl (as a multi-hosted vserver, pointed back at the other three). Edgecast points at all 4 in a round-robin.
The Zeus nodes achieve 100% cache hit rate on this almost all the time. Edgecast is not quite so good, but still over 90%.
I'm going to WONTFIX this bug, in favor of the CDN approach that's now in place.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Updated•10 years ago
|
Product: mozilla.org → mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•