On Sat, May 14, 2016 at 4:55 AM, sebb <[email protected]> wrote: > On 13 May 2016 at 17:25, Sam Ruby <[email protected]> wrote: >> TL;DR: whimsy3.apache.org is now operational. Details below. >> >> On 2016-04-23 10:49, Sam Ruby <[email protected]> wrote: >>> We just got settled into whimsy-vm2, and I've already started working on >>> whimsy-vm3. >>> >>> The precipitating factor was >>> https://issues.apache.org/jira/browse/INFRA-11723; where the solution >>> was to cache content that was statically being served by Apache httpd to >>> another machine on another network... where it would be statically >>> served by Apache httpd. >> >> I wonder if it would be worth undoing this? Either that or changing the >> code to try to fetch from whimsy and then fail back to a local cached copy >> on failure? > > Although the problem with *really* slow responses was a temporary > issue, it's definitely slower using remote access. > > Compare the current local access: > http://home.apache.org/phonebook.html > > with whimsy access: > http://home.apache.org/whimsybook.html > or > http://home.apache.org/whimsy3book.html > > Clear the browser cache to see the full effect.
whimsy3book is equally as speedy for me. The concept of "remote" makes no sense to me in this context. The phonebook consists of a static HTML page, a static JS page, and a small number of static JSON pages. All are served using Apache httpd running on ASF infrastructure. One host has more recent data, another has slightly older data. The speed should be no different. If there is a reason why apache httpd serving static files runs faster on home.apache.org than it does on whimsy-vm3.apache.org, I would want to understand why that is and how it could be fixed. > Using a fall-back mechanism would inevitably be slower for the cases > when Whimsy was not responding promptly. > Also I don't know how easy that is to do in Javascript. There is code in the javascript to fetch pages (getAsyncJSONArray). It sends an alert on failure. It could, instead, try a different URL. But if people are happy with the phonebook as is, there really is no need to change it. >>> This supports the notion that the problem is either the network or the >>> proxy. So I requested and obtained a new VM on a different colo >>> facility and network: >>> >>> https://issues.apache.org/jira/browse/INFRA-11725 >>> >>> As a testament to puppet, the site is already sorta there >>> (http://whimsy3.apache.org), the largest thing missing is the svn >>> checkouts that the code requires. >> >> Puppet really made this easy. Only differences I noted: >> >> 1) on whimsy-vm3; most of the space is on /x1; so I changed the directory >> layout >> >> 2) no proxy means that a signed cert is needed, and the apache configuration >> tweaked accordingly >> >> 3) the HOME directory is different for CGIs; this affects the secretarial >> workbench. Might be a consequence of #2 above. >> >>> Note that for the moment, the site is accessed via http instead of >>> https; that's because this vm is NOT currently accessed via a proxy. >>> I'd like to keep it that way at least initially so that can more easily >>> determine where the actual problem lies. I'm working out the mechanics >>> of obtaining an SSL cert for this, and that should be resolved in a few >>> days. >> >> This is indeed fixed now. >> >>> If all goes well, I'll ask that the DNS entry for whimsy.apache.org to >>> be updated to point to whimsy-vm3 before the next board meeting, and >>> then to release whimsy-vm2 after that point. >> >> As this point, I'd rather wait until after the next meeting to make this >> switch; I'll be using whimsy3 during the board meeting, and will be >> encouraging others to do likewise. >> >> If anybody has any remaining need for whimsy-vm2 please speak up now; >> otherwise it will likely go away by the end of the month. >> >>> The original whimsy-vm still hosts some unrelated tools (e.g., >>> infra.apache.org and etherpad), and that would need to be addressed >>> before that machine is released. >> >> I have no further need for this vm; but haven't spent any cycles trying to >> figure out who else might. > > OK by me. > > I think we need to switch off most of the cronjobs on VM2 as soon as > we can - the notification messages are currently duplicated. > However this probably cannot happen until PingMyBox is talking to VM3. Instead of turning off the cronjobs, perhaps notifications could skipped if `hostname`.include? 'vm2' ? - Sam Ruby
