Opened 18 months ago

Closed 5 months ago

Last modified 4 months ago

#30238 closed defect (duplicate)

OnionPerf json analysis file is different than the one recreated from logs

Reported by: acute Owned by: karsten
Priority: Medium Milestone:
Component: Metrics/Onionperf Version:
Severity: Normal Keywords: metrics-team-roadmap-2020
Cc: acute, metrics-team Actual Points: 0.5
Parent ID: #33321 Points: 2
Reviewer: Sponsor: Sponsor59-must

Description

OP creates json analysis files at midnight from the logs collected on the respective day. Recreating the json analysis file from the logs collected on 01-13-19 on op-ab yields a different result than the json analysis created by onionperf at the time of analysis. We should investigate why OP was cut short in the middle of the analysis for that particular day (my file is 16MB, op-ab's is 7.7MB). When I recreate any of the other json files from their respective logs (have tried for ~10 other days), the contents and sizes match up.

We should prevent this from happening as we may use the json logs for analysis.

Child Tickets

Change History (8)

comment:1 Changed 14 months ago by irl

Resolution: invalid
Status: newclosed

comment:2 Changed 7 months ago by acute

Resolution: invalid
Status: closedreopened

Moving all gitlab OP tickets back to Trac.

comment:3 Changed 5 months ago by gaba

Keywords: metrics-team-roadmap-2020 added
Points: 2
Sponsor: Sponsor58

comment:4 Changed 5 months ago by gaba

Sponsor: Sponsor58Sponsor59

comment:5 Changed 5 months ago by karsten

Cc: metrics-team added
Owner: changed from metrics-team to karsten
Status: reopenedaccepted

I'm grabbing this ticket for a day or so. I'm going to reprocess past log files from op-{ab,hk,nl,us} to see if this has happened before other than the day mentioned in the summary.

comment:6 Changed 5 months ago by karsten

Actual Points: 0.5
Resolution: duplicate
Status: acceptedclosed

I found the issue!

The difference comes from running the analysis with or without the -d or --date-filter parameter:

  • Running it without that parameter produces an analysis file that is 16 MiB large in uncompressed form and that contains measurements from that day and the day before. This is what I assume acute did when recreating files.
  • Running it with that parameter produces an analysis file that is 7.7 MiB large in uncompressed form and that contains only measurement from that day. This is what OnionPerf does by default at midnight.

I think this is closely related to #29369 or even a duplicate. It happens when OnionPerf wasn't running at midnight. We need to fix what we do in that case, but it seems like #29369 is the better place for that. At least we now know that this ticket is not about some entirely unknown issue and the files produced by OnionPerf are usable. In fact, OnionPerf was doing exactly what it was supposed to do in both cases, just not what one might expect it to do.

This only took a fraction of the expected time, because the bug hunt was comparatively easy and no reprocessing of past measurement files to be served by CollecTor was necessary.

Closing as duplicate.

comment:7 Changed 5 months ago by karsten

Sponsor: Sponsor59Sponsor59-must

Moving to Sponsor59-must, because we should really do these in order to call Sponsor59 done.

comment:8 Changed 4 months ago by karsten

Parent ID: #33321
Note: See TracTickets for help on using tickets.