Closed Bug 690453 Opened 14 years ago Closed 14 years ago

port fxfeeds to TrafficScript rule

Categories

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

All
Other
task
Not set
minor

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: mrz, Assigned: mrz)

Details

No description provided.
Assignee: server-ops → mrz
Group: infra
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.
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]);
(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.
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.
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
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.