1. 15 Aug, 2018 1 commit
  2. 05 Jun, 2018 1 commit
  3. 30 May, 2018 2 commits
  4. 28 May, 2018 3 commits
  5. 19 Apr, 2018 3 commits
  6. 05 Apr, 2018 4 commits
  7. 01 Mar, 2018 1 commit
    • Tomas Krizek's avatar
      orchestrator: exit when resolvers aren't responding · a4ab0e3b
      Tomas Krizek authored
      If one of the resolvers doesn't respond to N queries in a row, exit
      the script. This should help to avoid wasting resources when resolvers
      weren't started up properly (or crashed).
      Related knot/resolver-benchmarking#17
  8. 08 Feb, 2018 1 commit
  9. 29 Jan, 2018 4 commits
  10. 25 Jan, 2018 2 commits
  11. 17 Jan, 2018 1 commit
  12. 19 Dec, 2017 1 commit
    • Petr Špaček's avatar
      orchestrator: support TCP transport · 37b9cf21
      Petr Špaček authored
      Potential problems I'm aware of:
      1. Errors while connecting/sending are not handled. I thing this is a
         good thing to catch problems early on but I might be wrong.
      2. If connection to any resolver server fails, all connections in given
         worker are closed and reinitialized.
      3. Logging and postprocessing is missing. I.e. there is not way to
         distinguish connection reset from timeout for given query.
  13. 18 Dec, 2017 1 commit
    • Petr Špaček's avatar
      orchestrator: optimize storage of answers · d422292d
      Petr Špaček authored
      Previously each orchestrator worker wrote its dataset in own LMDB
      transaction. For some reason this led to huge database growth.
      Now workers submit their data for write back to the main process
      and this reduces storage usage by factor of 25.
      Related: knot/resolver-benchmarking#18
  14. 25 Sep, 2017 1 commit
  15. 05 Sep, 2017 1 commit
  16. 21 Jun, 2017 2 commits
  17. 15 Jun, 2017 6 commits
    • Petr Špaček's avatar
    • Petr Špaček's avatar
      orchestrator: optimize write performance at cost of crash-safety · dde46712
      Petr Špaček authored
      These tests are usually quite easy to repeat so we do not care that much
      about crash-proofness.
    • Petr Špaček's avatar
    • Petr Špaček's avatar
      orchestrator: experiment with threads · 4398e04d
      Petr Špaček authored
      There is a question whether overhead of 64 processes is not unnecesairly
      big for simple task as sending and receiving blobs from network.
      This commit adds ability to run orchestrator with threads instead
      of worker processes. It will be subject of further tunning.
    • Petr Špaček's avatar
    • Petr Špaček's avatar
      Respdiff second generation: reachitecture, support for parallel processing · 527d6f91
      Petr Špaček authored
      The original monolitic Respdif (one f in the name) by Jan Holusa
      was reachitected and split into separate tools which (when chained
      together) do very similar job but much faster and flexibly.
      The second generation is conceptually chain of independent tools:
      1. generate queries in wire format
      2. send pre-generated wire format to resolvers and gather answers
      3. analyze answers
      This split allows us to repeat steps using the same data as necessary,
      e.g. run analysis with different parameters without re-querying the
      This first version is using filesystem to store queries and answers.
      Tool "makedirs.py" reads list of queries in text format <name> <RR type>
      and creates directory structure with subdirectory for each query. File
      "q.dns" in each subdirectory contains query in DNS wire format.
      Tool "orchestrator.py" then reads this stored wire format, sends it to
      resolvers and stores answer from each resolver into separate file.
      Directory structure for one query is:
      00001/            - subdirectory name == query ID
      00001/q.dns       - query in wire format
      00001/bind.dns    - answer from BIND in wire format
      00001/kresd.dns   -             kresd
      00001/unbound.dns -             Unbound
      Resulting files can be analyzed using tool "msgdiff.py".
      The tool refers to one resolver as "target" and to remaining resolvers
      as "others". Msgdiff compares specified fields in the answers and
      compute statistics based on comparion results.
      Answers where "others" do not agree with each other are simply counted but
      not processed further. Answers where "others" agree but the "target"
      returned a different answer than all "others" are counted separately
      with higher granularity, producing stats for each field in DNS message
      (rcode, flags, answer section ...).
      This very first version lacks proper user interface and values are
      hardcoded into Python scripts, see orchestrator.py.