Opened 7 years ago

Closed 2 years ago

#7516 closed task (wontfix)

Track down Will Scott's torperf-like scripts, make them public if needed, and do a trial deployment somewhere

Reported by: arma Owned by:
Priority: Medium Milestone:
Component: Archived/Torperf Version:
Severity: Keywords:
Cc: wrs, iang, ln5, karsten Actual Points:
Parent ID: #7168 Points:
Reviewer: Sponsor:

Description

Will Scott says he's

using the code to actively look at the performance impact of
proxies on web page load time.  Essentially it's a wrapper around
http://phantomjs.org/ with some aggregation and reporting added.

He adds that there are two design things that ought to get figured out

Where the monitoring should live.  I have servers I can use to get a system
working at UW. At some point in a few years I'll graduate, and my
experience is that things which get left behind decay pretty fast, so I'm
somewhat hesitant to go that route.

How to get a stable / meaningful measurements. We need enough aggregation
across both the circuit and the destination domain to dampen individual
server issues and be able to say something about tor as a whole.  Are there
other factors I'm missing that aggregation + setting up a new circuit
before each measurement won't be able to overcome?

Child Tickets

Change History (10)

comment:1 Changed 7 years ago by arma

As to where it should live long-term, I think we should have several of them running, just as we have several torperfs running right now. We can get one going on torproject infrastructure, but we should also have one of each of several universities, on (at least to start) both continents.

comment:2 Changed 7 years ago by arma

Will, can you point us to the current code? Hopefully with a readme or something to get us started on running it? :)

comment:3 Changed 7 years ago by arma

Ian, can I ask you to lend us a grad student, to help us sit this up but also to help think through Will's second question above? I think the answer is (so long as we set it up so it uses a new set of circuits for each fresh fetch) that if we get enough tests per time period to be statistically significant, we're good to go. But what is 'enough'?

comment:4 in reply to:  1 Changed 7 years ago by ln5

Cc: ln5 added

Replying to arma:

As to where it should live long-term, I think we should have several of them running, just as we have several torperfs running right now. We can get one going on torproject infrastructure, but we should also have one of each of several universities, on (at least to start) both continents.

I can run one at SUNET.

comment:5 Changed 7 years ago by karsten

Cc: karsten added

comment:6 Changed 7 years ago by wrs

The current scripts got more entangled into the measurement stuff I was doing than they should have.

Here's a first attempt at splitting out the page speed measurement into a stand alone component.
github.com/willscott/pagespeed

This is a core set of scripts that measures speed for a fixed list of URLs. I've written some additional automation on top of them to start the process on machines with less setup effort, and I'll commit those in the next couple days as I disentangle them.

comment:7 Changed 7 years ago by arma

Cc: wrs added; wrs@… removed

comment:8 Changed 7 years ago by wrs

Is there an existing reporting system for tor metrics? It seems like results from the page speed experiments should get aggregated and saved in the same system.

comment:9 in reply to:  8 Changed 7 years ago by karsten

Replying to wrs:

Is there an existing reporting system for tor metrics? It seems like results from the page speed experiments should get aggregated and saved in the same system.

That would be metrics-db. It's currently fetching and processing five different types of data, and I wouldn't mind adding a sixth. That new code doesn't have to be Java, but it can also be Python. The new module should behave similar to the current five modules by storing files in the same directory structure that can provided via rsync and via daily updated monthly tarballs.

Do you have a description of the data format, similar to the current metrics data formats somewhere?

comment:10 Changed 2 years ago by karsten

Resolution: wontfix
Status: newclosed

We officially switched from Torperf to OnionPerf for Tor performance measurements. We don't need these tickets anymore and will use OnionPerf's issue tracker for OnionPerf-related issues. Closing them all as wontfix.

Note: See TracTickets for help on using tickets.