{"id":16936506,"url":"https://github.com/jonhoo/volley","last_synced_at":"2025-07-01T02:37:02.180Z","repository":{"id":33346974,"uuid":"36991775","full_name":"jonhoo/volley","owner":"jonhoo","description":"Volley is a benchmarking tool for measuring the performance of server networking stacks.","archived":false,"fork":false,"pushed_at":"2015-06-27T16:09:12.000Z","size":2696,"stargazers_count":125,"open_issues_count":9,"forks_count":11,"subscribers_count":10,"default_branch":"master","last_synced_at":"2025-06-29T10:43:09.864Z","etag":null,"topics":["benchmark","comparison","network"],"latest_commit_sha":null,"homepage":null,"language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/jonhoo.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2015-06-06T19:06:16.000Z","updated_at":"2025-06-22T07:36:19.000Z","dependencies_parsed_at":"2022-08-29T09:10:45.689Z","dependency_job_id":null,"html_url":"https://github.com/jonhoo/volley","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/jonhoo/volley","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jonhoo%2Fvolley","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jonhoo%2Fvolley/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jonhoo%2Fvolley/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jonhoo%2Fvolley/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/jonhoo","download_url":"https://codeload.github.com/jonhoo/volley/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jonhoo%2Fvolley/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":262884220,"owners_count":23379355,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["benchmark","comparison","network"],"created_at":"2024-10-13T20:57:10.652Z","updated_at":"2025-07-01T02:37:02.122Z","avatar_url":"https://github.com/jonhoo.png","language":"C","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Volley\n\nVolley is a benchmarking tool for measuring the performance (latency in\nparticular) of server networking stacks. It can be used to determine the\nperformance of the lower levels of the stack (i.e. the kernel), of the\nserver application's programming language abstractions for sockets, or\nof the libraries and code running within the application.\n\nVolley spawns a configurable number of concurrent clients that all\nconnect to the server, and then performs ping-pong-like single-word\noperations with the server to gather statistics. It will continue doing\nso for as many iterations as it takes to produce statistically relevant\nresults.\n\n## Goals\n\nVolley can be used to benchmark many things, but I believe there are two\nmain categories of servers that are of interest. In particular, I\nenvision that there will be at least two implementations for every\nlanguage represented in Volley: one that is idiomatic, and one that is\noptimized. Comparing the idiomatic solutions' performance is interesting\nin and of itself, and comparing the optimized solutions might yield\ninsights into how well-suited a particular language is for doing\nhigh-performance networking.\n\nI say *at least* two, because there might be other interesting designs\nto explore. For example, does the conventional wisdom that having a\nworker pool improves performance actually still hold? What is the\nperformance difference between a forking and a threaded server? What is\nthe performance difference between asynchronous and synchronous I/O?\n\n## Preliminary results\n\nRunning the volley benchmarks on an 80-core machine running Linux 3.16\nwith 40, 80 and 200 clients distributed across 40 cores yields the\nresults given in the graph below. Error bars denote the 99% confidence\ninterval. The benchmark machine has four NUMA nodes, each with 10 cores.\n\n![performance plot](https://cdn.rawgit.com/jonhoo/volley/76c6ec7015fa01991793ff57db27c368fc54545f/benchmark/perf.png)\n\nTo reproduce, run:\n\n```\nbenchmark/ $ experiment -r $(PWD)/..\nbenchmark/ $ grep us 'out/*/run-1/stdout.log' | sed 's@/run-[^/]*/stdout.log@@' | tr '/:-' '\\t' | awk '{printf $2; for (i=3;i\u003cNF-4;i++){printf \"-\"$i} for (i=NF-4;i\u003c=NF;i++){printf \" \"$i} print \"\"}'\n```\n\nAnd plot using the R script in `benchmark/plot.R`. Experiment can be\nfound [here](https://github.com/jonhoo/experiment).\n\n\n## Contributing servers\n\nPlease submit PRs adding a directory to `servers/`. The name of the\ndirectory should be indicative of what server is being tested. The\ndirectory should contain a Makefile that has (at least) two targets:\n\n  - a target with the same name as the directory. this rule should\n    produce an executable binary with that name in the current\n    directory.\n  - a `clean` rule, which is called whenever the top-level `clean`\n    target is invoked.\n\nThe binary accepts a single, mandatory flag, `-p`, which names a TCP\nport. The server should listen on this port for incoming requests. For\nevery established connection, the server behaviour should be as follows:\n\n  1. read 4 bytes from the connection\n  2. parse the 4 bytes into a 32 bit integer using network byte order\n  3. if the integer is zero, the server should terminate\n  4. add one to the integer, wrapping around if necessary\n  5. write the integer as 4 bytes in network byte order to the connection\n  6. go to step 1.\n\nIf a connection is closed, the server should continue waiting for new\nconnections. If the server receives a SIGTERM, it should terminate at\nits earliest convenience (i.e. it should not block indefinitely waiting\nfor new connctions).\n\nTo verify that your server works correctly, run the follwoing commands:\n\n```\nvolley/ $ make\nvolley/ $ ./benchmark/bench.sh 1 1 1 target/servers/\u003cyour-server\u003e\n```\n\nThis should output something akin to:\n\n```\nnumactl -C +0-0 /home/.../volley/target/servers/\u003cserver\u003e -p 2222\nnumactl -C 3-3 /home/.../volley/target/\u003cserver\u003e -p 2222 -c 1\npriming with 1000000 iterations across 1 clients\niteration complete: mean is 9us, stddev is 1.25us\n9.04us\n```\n\nYou may also see the error:\n\n```\n./benchmark/bench.sh: line 47: kill: (12345) - No such process\n```\n\nThis can safely be ignored, and is an artefact of the fact that the\nserver may terminate when it receives a 0 challenge.\n\n## Server improvements\n\nIf you believe an already implemented server could be improved (either\nsyntactically or semantically), please file an issue detailing the\nproblem, and if possible, submit a PR giving a proposed solution.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjonhoo%2Fvolley","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fjonhoo%2Fvolley","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjonhoo%2Fvolley/lists"}