{"id":13664871,"url":"https://github.com/httperf/httperf","last_synced_at":"2025-10-21T05:01:51.475Z","repository":{"id":28669181,"uuid":"32188829","full_name":"httperf/httperf","owner":"httperf","description":"The httperf HTTP load generator","archived":false,"fork":false,"pushed_at":"2022-04-20T11:35:50.000Z","size":546,"stargazers_count":1014,"open_issues_count":54,"forks_count":152,"subscribers_count":38,"default_branch":"master","last_synced_at":"2025-10-21T05:01:51.229Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/httperf.png","metadata":{"files":{"readme":"README.md","changelog":"ChangeLog","contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2015-03-14T00:41:34.000Z","updated_at":"2025-10-15T07:40:47.000Z","dependencies_parsed_at":"2022-07-27T15:03:17.962Z","dependency_job_id":null,"html_url":"https://github.com/httperf/httperf","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/httperf/httperf","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/httperf%2Fhttperf","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/httperf%2Fhttperf/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/httperf%2Fhttperf/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/httperf%2Fhttperf/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/httperf","download_url":"https://codeload.github.com/httperf/httperf/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/httperf%2Fhttperf/sbom","scorecard":{"id":471270,"data":{"date":"2025-08-11","repo":{"name":"github.com/httperf/httperf","commit":"de8cd6ad8a79779a0cb74a4aa2175afa9e24df57"},"scorecard":{"version":"v5.2.1-40-gf6ed084d","commit":"f6ed084d17c9236477efd66e5b258b9d4cc7b389"},"score":4.2,"checks":[{"name":"Token-Permissions","score":-1,"reason":"No tokens found","details":null,"documentation":{"short":"Determines if the project's workflows follow the principle of least privilege.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#token-permissions"}},{"name":"Code-Review","score":9,"reason":"Found 11/12 approved changesets -- score normalized to 9","details":null,"documentation":{"short":"Determines if the project requires human code review before pull requests (aka merge requests) are merged.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#code-review"}},{"name":"Maintained","score":0,"reason":"0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0","details":null,"documentation":{"short":"Determines if the project is \"actively maintained\".","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#maintained"}},{"name":"Dangerous-Workflow","score":-1,"reason":"no workflows found","details":null,"documentation":{"short":"Determines if the project's GitHub Action workflows avoid dangerous patterns.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#dangerous-workflow"}},{"name":"Packaging","score":-1,"reason":"packaging workflow not detected","details":["Warn: no GitHub/GitLab publishing workflow detected."],"documentation":{"short":"Determines if the project is published as a package that others can easily download, install, easily update, and uninstall.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#packaging"}},{"name":"Binary-Artifacts","score":10,"reason":"no binaries found in the repo","details":null,"documentation":{"short":"Determines if the project has generated executable (binary) artifacts in the source repository.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#binary-artifacts"}},{"name":"Pinned-Dependencies","score":-1,"reason":"no dependencies found","details":null,"documentation":{"short":"Determines if the project has declared and pinned the dependencies of its build process.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#pinned-dependencies"}},{"name":"CII-Best-Practices","score":0,"reason":"no effort to earn an OpenSSF best practices badge detected","details":null,"documentation":{"short":"Determines if the project has an OpenSSF (formerly CII) Best Practices Badge.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#cii-best-practices"}},{"name":"Security-Policy","score":0,"reason":"security policy file not detected","details":["Warn: no security policy file detected","Warn: no security file to analyze","Warn: no security file to analyze","Warn: no security file to analyze"],"documentation":{"short":"Determines if the project has published a security policy.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#security-policy"}},{"name":"Vulnerabilities","score":10,"reason":"0 existing vulnerabilities detected","details":null,"documentation":{"short":"Determines if the project has open, known unfixed vulnerabilities.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#vulnerabilities"}},{"name":"Fuzzing","score":0,"reason":"project is not fuzzed","details":["Warn: no fuzzer integrations found"],"documentation":{"short":"Determines if the project uses fuzzing.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#fuzzing"}},{"name":"License","score":10,"reason":"license file detected","details":["Info: project has a license file: COPYRIGHT:0","Info: FSF or OSI recognized license: GNU General Public License v2.0: COPYRIGHT:0"],"documentation":{"short":"Determines if the project has defined a license.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#license"}},{"name":"Signed-Releases","score":-1,"reason":"no releases found","details":null,"documentation":{"short":"Determines if the project cryptographically signs release artifacts.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#signed-releases"}},{"name":"Branch-Protection","score":0,"reason":"branch protection not enabled on development/release branches","details":["Warn: branch protection not enabled for branch 'master'"],"documentation":{"short":"Determines if the default and release branches are protected with GitHub's branch protection settings.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#branch-protection"}},{"name":"SAST","score":0,"reason":"SAST tool is not run on all commits -- score normalized to 0","details":["Warn: 0 commits out of 29 are checked with a SAST tool"],"documentation":{"short":"Determines if the project uses static code analysis.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#sast"}}]},"last_synced_at":"2025-08-19T13:56:39.973Z","repository_id":28669181,"created_at":"2025-08-19T13:56:39.973Z","updated_at":"2025-08-19T13:56:39.973Z"},"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":280207219,"owners_count":26290616,"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","status":"online","status_checked_at":"2025-10-21T02:00:06.614Z","response_time":58,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"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":[],"created_at":"2024-08-02T05:03:10.601Z","updated_at":"2025-10-21T05:01:51.463Z","avatar_url":"https://github.com/httperf.png","language":"C","readme":"\n# httperf\n\nhttperf is a tool for measuring web server performance. It provides a flexible facility for generating various HTTP workloads and for measuring server performance.\n\nThe focus of httperf is not on implementing one particular benchmark but on providing a robust, high-performance tool that facilitates the construction of both micro- and macro-level benchmarks. The three distinguishing characteristics of httperf are its robustness, which includes the ability to generate and sustain server overload, support for the HTTP/1.1 and SSL protocols, and its extensibility to new workload generators and performance measurements.\n\n## Building httperf\n\nThis release of httperf is using the standard GNU configuration\nmechanism.  The following steps can be used to build it:\n\nIn this example, SRCDIR refers to the httperf source directory.  The\nlast step may have to be executed as \"root\".\n\nFirst, some tools which are required for the build process need to be installed.\n\n\t$ sudo apt install automake libtool\n\nThen, run the following steps in order to build. Note that some of these might have to be executed as \"root\", i.e., with sudo.\n\n\t$ autoconf\n\t$ libtoolize --force\n\t$ autoreconf -i\n\t$ automake\n\t$ ./configure\n\t$ make\n\t$ sudo make install\n\nThis step may need to be run as root:\n\n\tmake install\n\nSince httperf 0.9.1, the the idleconn program is no longer built by\ndefault.  Using the configure option --enable-idleconn will instruct\nthe build system to compile the tool.\n\nTo build httperf with debug support turned on, invoke configure with\noption \"--enable-debug\".\n\nBy default, the httperf binary is installed in /usr/local/bin/httperf\nand the man-page is installed in /usr/local/man/man1/httperf.  You can\nchange these defaults by passing appropriate options to the\n\"configure\" script.  See \"configure --help\" for details.\n\nThis release of httperf has preliminary SSL support.  To enable it,\nyou need to have OpenSSL (http://www.openssl.org/) already installed\non your system.  The configure script assumes that the OpenSSH header\nfiles and libraries can be found in standard locations (e.g.,\n/usr/include and /usr/lib).  If the files are in a different place,\nyou need to tell the configure script where to find them.  This can be\ndone by setting environment variables CPPFLAGS and LDFLAGS before\ninvoking \"configure\".  For example, if the SSL header files are\ninstalled in /usr/local/ssl/include and the SSL libraries are\ninstalled in /usr/local/ssl/lib, then the environment variables should\nbe set like this:\n\n\tCPPFLAGS=\"-I/usr/local/ssl/include\"\n\tLDFLAGS=\"-L/usr/local/ssl/lib\"\n\nWith these settings in place, \"configure\" can be invoked as usual and\nSSL should now be found.  If SSL has been detected, the following\nthree checks should be answered with \"yes\":\n\n\tchecking for main in -lcrypto... yes\n\tchecking for SSL_version in -lssl... yes\n\t\t:\n\tchecking for openssl/ssl.h... yes\n\nNote: you may have to delete \"config.cache\" to ensure that \"configure\"\nre-evaluates those checks after changing the settings of the\nenvironment variables.\n\n  WARNING:\n\thttperf uses a deterministic seed for the random number\n\tgenerator used by SSL.  Thus, the SSL encrypted data is\n\tlikely to be easy to crack.  In other words, do not assume\n\tthat SSL data transferred when using httperf is (well)\n\tencrypted!\n\nThis release of httperf has been tested under the following operating systems:\nHP-UX 11i (64-bit PA-RISC and IA-64)\nRed Hat Enterprise Linux AS (AMD64 and IA-64)\nSUSE Linux 10.1 (i386)\nopenSUSE 10.2 (i386)\nOpenBSD 4.0 (i386)\nFreeBSD 6.0 (AMD64)\nSolaris 8 (UltraSparc 64-bit)\n\nIt should be straight-forward to build httperf on other platforms, please report\nany build problems to the mailing list along with the platform specifications.\n\n## Mailing list\n\nA mailing list has been set up to encourage discussions among the\nhttperf user community.  This list is managed by majordomo.  To\nsubscribe to the list, send a mail containing the body:\n\n\tsubscribe httperf\n\nto majordomo@linux.hpl.hp.com.  To post an article to the list, send\nit directly to httperf@linux.hpl.hp.com.\n\n## Running httperf\n\nIMPORTANT: It is crucial to run just one copy of httperf per client\nmachine.  httperf sucks up all available CPU time on a machine.  It is\ntherefore important not to run any other (CPU-intensive) tasks on a\nclient machine while httperf is running.  httperf is a CPU hog to\nensure that it can generate the desired workload with good accuracy,\nso do not try to change this without fully understanding what the\nissues are.\n\n### Examples\n\nThe simplest way to invoke httperf is with a command line of the form:\n\n\u003e httperf --server wailua --port 6800\n\nThis command results in httperf attempting to make one request for URL\nhttp://wailua:6800/.  After the reply is received, performance\nstatistics will be printed and the client exits (the statistics are\nexplained below).\n\nA list of all available options can be obtained by specifying the\n--help option (all option names can be abbreviated as long as they\nremain unambiguous).\n\nA more realistic test case might be to issue 100 HTTP requests at a\nrate of 10 requests per second.  This can be achieved by additionally\nspecifying the --num-conns and --rate options.  When specifying the\n--rate option, it's generally a good idea to also specify a timeout\nvalue using the --timeout option.  In the example below, a timeout of\none second is specified (the ramification of this option will be\nexplained later):\n\n\u003e httperf --server wailua --port 6800 --num-conns 100 --rate 10 --timeout 1\n\nThe performance statistics printed by httperf at the end of the test\nmight look like this:\n\n    Total: connections 100 requests 100 replies 100 test-duration 9.905 s\n\n    Connection rate: 10.1 conn/s (99.1 ms/conn, \u003c=1 concurrent connections)\n    Connection time [ms]: min 4.6 avg 5.6 max 19.9 median 4.5 stddev 2.0\n    Connection time [ms]: connect 1.4\n    Connection length [replies/conn]: 1.000\n\n    Request rate: 10.1 req/s (99.1 ms/req)\n    Request size [B]: 57.0\n\n    Reply rate [replies/s]: min 10.0 avg 10.0 max 10.0 stddev 0.0 (1 samples)\n    Reply time [ms]: response 4.1 transfer 0.0\n    Reply size [B]: header 219.0 content 204.0 footer 0.0 (total 423.0)\n    Reply status: 1xx=0 2xx=100 3xx=0 4xx=0 5xx=0\n\n    CPU time [s]: user 2.71 system 7.08 (user 27.4% system 71.5% total 98.8%)\n    Net I/O: 4.7 KB/s (0.0*10^6 bps)\n\n    Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0\n    Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0\n\nThere are six groups of statistics: overall results (\"Total\"),\nconnection related results (\"Connection\"), results relating to the\nissuing of HTTP requests (\"Request\"), results relating to the replies\nreceived from the server (\"Reply\"), miscellaneous results relating to\nthe CPU time and network bandwidth used, and, finally, a summary of\nerrors encountered (\"Errors\").  Let's discuss each in turn:\n\n## \"Total\" Results\n\nThe \"Total\" line summarizes how many TCP connections were initiated by\nthe client, how many requests it sent, how many replies it received,\nand what the total test duration was.  The line below shows that 100\nconnections were initiated, 100 requests were performed and 100\nreplies were received.  It also shows that total test-duration was\n9.905 seconds meaning that the average request rate was almost exactly\n10 request per second.\n\n    Total: connections 100 requests 100 replies 100 test-duration 9.905 s\n\n## \"Connection\" Results\n\nThese results convey information related to the TCP connections that\nare used to communicate with the web server.\n\nSpecifically, the line below show that new connections were initiated\nat a rate of 10.1 connections per second.  This rate corresponds to a\nperiod of 99.1 milliseconds per connection.  Finally, the last number\nshows that at most one connection was open to the server at any given\ntime.\n\n    Connection rate: 10.1 conn/s (99.1 ms/conn, \u003c=1 concurrent connections)\n\nThe next line in the output gives lifetime statistics for successful\nconnections.  The lifetime of a connection is the time between a TCP\nconnection was initiated and the time the connection was closed.  A\nconnection is considered successful if it had at least one request\nthat resulted in a reply from the server.  The line shown below\nindicates that the minimum (\"min\") connection lifetime was 4.6\nmilliseconds, the average (\"avg\") lifetime was 5.6 milliseconds, the\nmaximum (\"max\") was 19.9 milliseconds, the median (\"median\") lifetime\nwas 4.5 milliseconds, and that the standard deviation of the lifetimes\nwas 2.0 milliseconds.\n\n    Connection time [ms]: min 4.6 avg 5.6 max 19.9 median 4.5 stddev 2.0\n\nTo compute the median time, httperf collects a histogram of connection\nlifetimes.  The granularity of this histogram is currently 1\nmilliseconds and the maximum connection lifetime that can be\naccommodated with the histogram is 100 seconds (these numbers can be\nchanged by editing macros BIN_WIDTH and MAX_LIFETIME in stat/basic.c).\nThis implies that the granularity of the median time is 1 millisecond\nand that at least 50% of the lifetime samples must have a lifetime of\nless than 100 seconds.\n\nThe next statistic in this section is the average time it took to\nestablish a TCP connection to the server (all successful TCP\nconnections establishments are counted, even connections that may have\nfailed eventually).  The line below shows that, on average, it took\n1.4 milliseconds to establish a connection.\n\n    Connection time [ms]: connect 1.4\n\nThe final line in this section gives the average number of replies\nthat were received per connection.  With regular HTTP/1.0, this value\nis at most 1.0 (when there are no failures), but with HTTP Keep-Alives\nor HTTP/1.1 persistent connections, this value can be arbitrarily\nhigh, indicating that the same connection was used to receive multiple\nresponses.\n\n    Connection length [replies/conn]: 1.000\n\n## \"Request\" Results\n\nThe first line in the \"Request\"-related results give the rate at which\nHTTP requests were issued and the period-length that the rate\ncorresponds to.  In the example below, the request rate was 10.1\nrequests per second, which corresponds to 99.1 milliseconds per\nrequest.\n\n    Request rate: 10.1 req/s (99.1 ms/req)\n\nAs long as no persistent connections are employed, the \"Request\"\nresults are typically very similar or identical to the \"Connection\"\nresults.  However, when persistent connections are used, several\nrequests can be issued on a single connection in which case the\nresults would be different.\n\nThe next line gives the average size of the HTTP request in bytes.  In\nthe line show below, the average request size was 57 bytes.\n\n    Request size [B]: 57.0\n\n\n## \"Reply\" Results\n\nFor simple measurements, the section with the \"Reply\" results is\nprobably the most interesting one.  The first line gives statistics on\nthe reply rate:\n\n    Reply rate [replies/s]: min 10.0 avg 10.0 max 10.0 stddev 0.0 (1 samples)\n\nThe line above indicates that the minimum (\"min\"), average (\"avg\"),\nand maximum (\"max\") reply rate was ten replies per second.  Given\nthese numbers, the standard deviation is, of course, zero.  The last\nnumber shows that only one reply rate sample was acquired.  The\npresent version of httperf collects one rate sample about once every\nfive seconds.  To obtain a meaningful standard deviation, it is\nrecommended to run each test long enough so at least thirty samples\nare obtained---this would correspond to a test duration of at least\n150 seconds, or two and a half minutes.\n\nThe next line gives information on how long it took for the server to\nrespond and how long it took to receive the reply.  The line below\nshows that it took 4.1 milliseconds between sending the first byte of\nthe request and receiving the first byte of the reply.  The time to\n\"transfer\", or read, the reply was too short to be measured, so it\nshows up as zero (as we'll see below, the entire reply fit into a\nsingle TCP segment and that's why the transfer time was measured as\nzero).\n\n    Reply time [ms]: response 4.1 transfer 0.0\n\nNext follow some statistics on the size of the reply---all numbers are\nreported in bytes.  Specifically, the average length of reply headers,\nthe average length of the content, and the average length of reply\nfooters are given (HTTP/1.1 uses footers to realize the \"chunked\"\ntransfer encoding).  For convenience, the average total number of\nbytes in the replies is also given.  In the example below, the average\nheader length (\"header\") was 219 bytes, the average content length\n(\"content\") was 204 bytes, and there were no footers (\"footer\"),\nyielding a total reply length of 423 bytes on average.\n\n    Reply size [B]: header 219.0 content 204.0 footer 0.0 (total 423.0)\n\nThe final piece in this section is a histogram on the status codes\nreceived in the replies.  The example below shows that all 100 replies\nwere \"successful\" replies as they contained a status code of 200\n(presumably):\n\n    Reply status: 1xx=0 2xx=100 3xx=0 4xx=0 5xx=0\n\n\n## Miscellaneous Results\n\nThis section starts with a summary of the CPU time the client\nconsumed.  The line below shows that 2.71 seconds were spent executing\nin user mode (\"user\"), 7.08 seconds were spent executing in system\nmode (\"system\") and that this corresponds to 27.4% user mode execution\nand 71.5% system execution.  The total utilization was almost exactly\n100%, which is expected given that httperf is a CPU hog:\n\n    CPU time [s]: user 2.71 system 7.08 (user 27.4% system 71.5% total 98.8%)\n\nNote that any time the total CPU utilization is significantly less\nthan 100%, some other processes must have been running on the client\nmachine while httperf was executing.  This makes it likely that the\nresults are \"polluted\" and the test should be rerun.\n\nThe next line gives the average network throughput in kilobytes per\nsecond (where a kilobyte is 1024 bytes) and in megabits per second\n(where a megabit is 10^6 bit).  The line below shows an average\nnetwork bandwidth of about 4.7 kilobyte per second.  The megabit per\nsecond number is zero due to rounding errors.\n\n    Net I/O: 4.7 KB/s (0.0*10^6 bps)\n\nThe network bandwidth is computed from the number of bytes sent and\nreceived on TCP connections.  This means that it accounts for the\nnetwork payload only (i.e., it doesn't account for protocol headers)\nand does not take into account retransmissions that may occur at the\nTCP level.\n\n## \"Errors\"\n\nThe final section contains statistics on the errors that occurred\nduring the test.  The \"total\" figure shows the total number of errors\nthat occurred.  The two lines below show that in our example run there\nwere no errors:\n\n    Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0\n    Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0\n\nThe meaning of each error is described below:\n\n total:\n\tThe sum of all following error counts.\n\n client-timo:\n\tEach time a request is made to the server, a watchdog timer\n\tis started.  If no (partial) response is received by the time\n\tthe watchdog timer expires, httperf times out that request\n\ta increments this error counter.  This is the most common error\n\twhen driving a server into overload.\n\n socket-timo\n\tThe number of times a TCP connection failed with a\n\tsocket-level time out (ETIMEDOUT).\n\n connrefused\n\tThe number of times a TCP connection attempt failed with\n\ta \"connection refused by server\" error (ECONNREFUSED).\n\n connreset\n\tThe number of times a TCP connection failed due to a reset\n\t(close) by the server.\n\n fd-unavail\n\tThe number of times the httperf client was out of file\n\tdescriptors.  Whenever this count is bigger than\n\tzero, the test results are meaning less because the client\n\twas overloaded (see discussion on setting --timeout below).\n\n addrunavail\n\tThe number of times the client was out of TCP port numbers\n\t(EADDRNOTAVAIL).  This error should never occur.  If it\n\tdoes, the results should be discarded.\n\n ftab-full\n\tThe number of times the system's file descriptor table\n\twas full.  Again, this error should never occur.  If it\n\tdoes, the results should be discarded.\n\n other\n\tThe number of times other errors occurred.  Whenever this\n\toccurs, it is necessary to track down the actual error\n\treason.  This can be done by compiling httperf with\n\tdebug support and specifying option --debug 1.\n\n\n## Selecting appropriate timeout values\n\nSince the client machine has only a limited set of resource available,\nit cannot sustain arbitrarily high HTTP request rates.  One limit is\nthat there are only roughly 60,000 TCP port numbers that can be in use\nat any given time.  Since, on HP-UX, it takes one minute for a TCP\nconnection to be fully closed (leave the TIME_WAIT state), the maximum\nrate a client can sustain is about 1,000 requests per second.\n\nThe actual sustainable rate is typically lower than this because\nbefore running out of TCP ports, a client is likely to run out of file\ndescriptors (one file descriptor is required per open TCP connection).\nBy default, HP-UX 10.20 allows 1024 file descriptors per process.\nWithout a watchdog timer, httperf could potentially quickly use up all\navailable file descriptors, at which point it could not induce any new\nload on the server (this would primarily happen when the server is\noverloaded).  To avoid this problem, httperf requires that the web\nserver must respond within the time specified by option --timeout.  If\nit does not respond within that time, the client considers the\nconnection to be \"dead\" and closes it (and increases the \"client-timo\"\nerror count).  The only exception to this rule is that after sending a\nrequest, httperf allows the server to take some additional time before\nit starts responding (to accommodate HTTP requests that take a long\ntime to complete on the server).  This additional time is called the\n\"server think time\" and can be specified by option --think-timeout.\nBy default, this additional think time is zero, so by default the\nserver has to be able to respond within the time allowed by the\n--timeout option.\n\nIn practice, we found that with a --timeout value of 1 second, an HP\n9000/735 machine running HP-UX 10.20 can sustain a rate of about 700\nconnections per second before it starts to run out of file descriptor\n(the exact rate depends, of course, on a number of factors).  To\nachieve web server loads bigger than that, it is necessary to employ\nseveral independent machines, each running one copy of httperf.  A\ntimeout of one second effectively means that \"slow\" connections will\ntypically timeout before TCP even gets a chance to retransmit (the\ninitial retransmission timeout is on the order of 3 seconds).  This is\nusually OK, except that one should keep in mind that it has the effect\nof truncating the connection life time distribution.\n","funding_links":[],"categories":["C","Web server Benchmarks","Load Testing Tools"],"sub_categories":["Meetups","C"],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fhttperf%2Fhttperf","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fhttperf%2Fhttperf","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fhttperf%2Fhttperf/lists"}