-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rule out w3c-test.org #758
Comments
a comment I made to @plehegar
|
100% agreed |
It's useful to have some server I can link to to see the live test running, so people don't have to figure out how to stand up their own wpt instance just to look at tests. If w3c-test.org isn't good for that, we should get something set up for that somewhere else. |
Anybody can set up an alternative instance — it’s pretty straightforward: git clone the wpt repo onto some server for domain It’s not that w3c-test.org isn't good for looking at tests — it is and of course that’s what it’s intended for. But it’s not officially maintained by the W3C systeams team and anyway there are quirks (bugs, really) in wptserve that cause it to wedge itself up pretty regularly when it’s run under load for hours or days at a time as a persistent process. That makes it hard for us to guarantee the availability of w3c-test.org as a stable service that people can rely on. Publishing specs that link to it — at least without some kind of very prominent warning to let people know it’s unstable — risks giving people the impression that it’s more stable and reliable than it is. |
This is "straightforward", in that there's a published list of steps, but it's also extremely non-trivial and far too much work to expect the average person to do who just wants to review some tests. So having a stood-up instance of wptserve to link to is still of very high value, I think. I'm not going to plaster a disclaimer about the live test link onto every single test line in the new Bikeshed feature (it would be ridiculous), and putting said disclaimer anywhere else in the spec would just mean it won't get read (so it would be useless), so I don't have a good solution for advertising the stability of the live test viewer. Thus my statement that if w3c-test.org isn't reliable enough to link to, we should make sure we have something that is. (And I guess fix the bugs in wptserve that wedge it.) |
So that’s the thing: Anybody setting up an instance of wptserve that runs persistently under load in the way that the w3c-test.org instance does is going to run into the same problems that has. So far nobody’s stepped forward to put the time needed into investigating the wptserve issues. If somebody can commit to doing that, then I’m happy to give them shell access to the w3c-test.org server so they can get on there and investigate. Until that happens we’re going to remain in the same state we have been for the literally several years now that we’ve known this is an issue and been discussing it — and w3c-test.org is going to remain unstable. So personally I think what would be far better instead at this point is that we move the hosting to some shared server that a number of us have shell access to — and quit calling it w3c-test.org but instead call it wpt-test.org or something (and make w3c-test.org just redirect to it). Then we could work together on debugging and fixing the problems needed to make it stable. |
It would be good to get a sense for how unstable the current deployment really is. @sideshowbarker can you speak to this anecdotally? Do you think that we'd get an accurate picture by cURL'ing http://w3c-test.org on a fixed interval for a couple of weeks? Or is the uptime too irregular for that to be representative? |
Looks like @foolip already set up some monitoring. I wrote a script to summarize that data (below); here are some quick calculations:
Script used to generate that summaryfrom __future__ import division
from datetime import date
import json
import time
import urllib2
HOURS = 60 * 60
DAYS = HOURS * 24
YESTERDAY = time.time() - DAYS
LAST_WEEK = time.time() - 7 * DAYS
def get_json(url):
request = urllib2.Request(url,
headers={'User-Agent': 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0'})
response = urllib2.urlopen(request)
return json.load(response)
def calculate(series):
total = reduce(lambda x, y: x + y, series)
mean = (total / len(series))
variance = reduce(lambda x, y: x + (y - mean) ** 2, series) / len(series)
return {
'total': total,
'mean': mean,
'variance': variance
}
def summarize_availability(availability):
start = availability[-1]['Start_Unix']
end = availability[0]['End_Unix']
down_durations = []
for event in availability:
if event['Status'] == 'Up':
continue
down_durations.append(event['End_Unix'] - event['Start_Unix'])
total_time = end - start
stats = calculate(down_durations)
print 'From %s to %s' % (
date.fromtimestamp(start).isoformat(),
date.fromtimestamp(end).isoformat()
)
print ' Down %d times (%.2f events/day)' % (
len(down_durations), len(down_durations) / (total_time / DAYS)
)
print ' Down for %d hours (%.2f%% availability)' % (
stats['total'] / HOURS, 100 * (total_time - stats['total']) / total_time
)
print ' Mean downtime: %.2f minutes' % (stats['mean'] / 60)
print ' Standard deviation: %d' % (stats['variance'] ** 0.5)
def summarize_response_times(respone_times):
start = response_times[0]['0']/1000
end = response_times[-1]['0']/1000
stats = calculate(map(lambda event: event['1'], response_times))
print 'From %s to %s' % (
date.fromtimestamp(start).isoformat(),
date.fromtimestamp(end).isoformat()
)
print ' Response time'
print ' Mean: %.2f seconds' % stats['mean']
print ' Standard deviation: %.2f' % (stats['variance'] ** 0.5)
response_times = get_json('https://app.statuscake.com/Workfloor/Influx.php?Ref=Public&Type=Chart&TestID=2526304&All=true&TestType=HTTP&_=1530046510252')['All']
availability = get_json('https://app.statuscake.com/Workfloor/Get.Status.Perioids.php?PublicID=kbUT7hiAxw&VID=2526304')
summarize_availability(availability)
summarize_availability(
filter(lambda event: event['Start_Unix'] > LAST_WEEK, availability)
)
print ''
summarize_response_times(response_times) |
@sideshowbarker my co-worker @bmac is up for the task! His handle in IRC is also "bmac"; do you think you could share access credentials with him? |
Confirming @jugglinmike's assertion that I'm going to start dedicating some time investigating improving wptserve's reliability under load as a persistent process. |
Thanks @jugglinmike and howdy @bmac! I’ve provisioned an account for you on the w3c-test.org host. Access to it is ssh-only, so to finish getting you set up, I’ll need your ssh public key. |
Thanks @sideshowbarker. I sent you an email with my ssh public key. |
* add link check, Fix #758 * Update lib/rules/links/reliability.js Co-authored-by: Denis Ah-Kang <[email protected]> * Update lib/rules/links/reliability.js Co-authored-by: Denis Ah-Kang <[email protected]> * Update lib/rules/links/reliability.js Co-authored-by: Denis Ah-Kang <[email protected]> * Update lib/rules/links/reliability.js * fix test Co-authored-by: Denis Ah-Kang <[email protected]>
We shouldn't have links in spec headers linking to w3c-test.org this is un unstable server and shouldn't cannot be relied on.
@sideshowbarker , feel to pitch if you think otherwise.
The text was updated successfully, but these errors were encountered: