I have this Google Dart test program:
#import('dart:io');
main() {
var s = new HttpServer();
s.defaultRequestHandler = (HttpRequest req, HttpResponse res) {
res.statusCode = 200;
res.contentLength = 4;
res.outputStream.writeString("sup!!");
res.outputStream.close();
};
s.listen('127.0.0.1', 80);
print('its up!');
}
It works fine on Chrome and Firefox, I get the sup -messages.
However, as soon as I try Apache Bench against it, it hangs (ab hangs):
Z:\www>ab -n 1 -c 1 "http://127.0.0.1/"
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)...apr_poll: The timeout specified has expired (70007)
You can find ab by installing Apache HTTP server and it will be located under the bin folder.
On a side note: is there some other benchmarking tool similar to ab that I could possibly use (and does not hang)?
It could be a problem with the contentLength. You wrote 4, but the actual content length is 5. For instance, if ab saw the contentLength, it might read 4 characters and wait for the connection to close. However, the connection probably won't close because the server is waiting to write the last character. The client and server are each waiting for something, resulting in deadlock.
Related
When attempting to connect to the Binance REST API from a Windows 11 computer, I got the following error:
ccxt.base.errors.ExchangeError: binanceus {"code":-71012,"msg":"IPv6 not supported"}
In this particular example I am using the ccxt Python library, but I assume the problem exists for any HTTP connection / library since the error comes from Binance. Here's sample code that replicates the issue on Windows 11 (works fine on a Linux machine):
import ccxt
exchange = ccxt.binanceus({'apiKey': '<your_key>', 'secret': '<your_secret>'})
print(exchange.fetch_balance())
I speculate that this is happening because by default in Windows 11 IPv6 has a higher priority than IPv4:
> netsh interface ipv6 show prefixpolicies
Querying active state...
Precedence Label Prefix
---------- ----- --------------------------------
50 0 ::1/128
40 1 ::/0
35 4 ::ffff:0:0/96
30 2 2002::/16
5 5 2001::/32
3 13 fc00::/7
1 11 fec0::/10
1 12 3ffe::/16
1 3 ::/96
I suppose one solution is to change this priority so IPv4 is used by default, but I don't want to do this, and I also prefer the code to work everywhere.
Under the hood, the ccxt library uses the Python requests library, and allows the user to construct a custom Session object.
I came up with the following hack/workaround which works for me
Is there a cleaner/better/more robust way to achieve the same thing?
import ccxt
import requests
from requests_toolbelt.adapters import source
import socket
def get_ipv4_session():
local_ipv4 = socket.gethostbyname(socket.gethostname())
src = source.SourceAddressAdapter(local_ipv4)
session = requests.Session()
session.mount("https://", src)
return session
exchange = ccxt.binanceus({
'apiKey': '<your key>',
'secret': '<your secret>',
'session': get_ipv4_session()
})
print(exchange.fetch_balance())
I read the answers here as well but they seem more complicated: Force requests to use IPv4 / IPv6
package main
import (
"io"
"net/http"
)
func hello(w http.ResponseWriter, r *http.Request) {
io.WriteString(w, "Hello world!\n")
}
func main() {
http.HandleFunc("/", hello)
http.ListenAndServe(":8000", nil)
}
I've got a couple of incredibly basic HTTP servers, and all of them are exhibiting this problem.
$ ab -c 1000 -n 10000 http://127.0.0.1:8000/
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
apr_socket_recv: Connection refused (61)
Total of 5112 requests completed
With a smaller concurrency value, things still fall over. For me, the issue seems to show up around the 5k-6k mark usually:
$ ab -c 10 -n 10000 http://127.0.0.1:8000/
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
apr_socket_recv: Operation timed out (60)
Total of 6277 requests completed
And in fact, you can drop concurrency entirely and the problem still (sometimes) happens:
$ ab -c 1 -n 10000 http://127.0.0.1:8000/
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
apr_socket_recv: Operation timed out (60)
Total of 6278 requests completed
I can't help but wonder if I'm hitting some kind of operating system limit somewhere? How would I tell? And how would I mitigate?
In short, you're running out of ports.
The default ephemeral port range on osx is 49152-65535, which is only 16,383 ports. Since each ab request is http/1.0 (without keepalive in your first examples), each new request takes another port.
As each port is used, it get's put into a queue where it waits for the tcp "Maximum Segment Lifetime", which is configured to be 15 seconds on osx. So if you use more than 16,383 ports in 15 seconds, you're effectively going to get throttled by the OS on further connections. Depending on which process runs out of ports first, you will get connection errors from the server, or hangs from ab.
You can mitigate this by using an http/1.1 capable load generator like wrk, or using the keepalive (-k) option for ab, so that connections are reused based on the tool's concurrency settings.
Now, the server code you're benchmarking does so little, that the load generator is being taxed just as much as the sever itself, with the local os and network stack likely making a good contribution. If you want to benchmark an http server, it's better to do some meaningful work from multiple clients not running on the same machine.
I'm working on an http client and I would like to test it on requests that take some time to finish. I could certainly come up with a python script to suit my needs, something about like:
def slow_server(environ, start_response):
with getSomeFile(environ) as file_to_serve:
block = file_to_serve.read(1024);
while block:
yield block
time.sleep(1.0)
block = file_to_serve.read(1024);
but this feels like a problem others have already encountered. Is there an easy way to serve static files with an absurdly low bandwidth cap, short of a full scale server like apache or nginx.
I'm working on linux, and the way I've been testing so far is with python -m SimpleHTTPServer 8000 in a directory full of files to serve. I'm equally interested in another simple command line server or a way to do bandwidth limiting with one or a few iptables commands on tcp port 8000 (or whatever would work).
The solution I'm going with for now uses a "real" webserver, but a much easier to configure one, lighttpd. I've added the following file to my path (its in ~/bin)
#! /usr/sbin/lighttpd -Df
server.document-root = "/dev/null"
server.modules = ("mod_proxy")
server.kbytes-per-second = env.LIGHTTPD_THROTTLE
server.port = env.LIGHTTPD_PORT
proxy.server = ( "" => (( "host" => "127.0.0.1", "port" => env.LIGHTTPD_PROXY )))
Which is a lighttpd config file that acts as a reverse proxy to localhost; source and destination ports, as well as a server total maximum bandwidth are given as environment variables, and so it can be invoked like:
$ cd /path/to/some/files
$ python -m SimpleHTTPServer 8000 &
$ LIGHTTPD_THROTTLE=60 LIGHTTPD_PORT=8001 LIGHTTPD_PROXY=8000 throttle.lighttpd
to proxy the python file server on port 8000 with a low 60KB per second on port 8001. Obviously, lighttpd could be used to serve the files itself, but this little script can be used to make any http server slow
On Windows you can use Fiddler which is a HTTP proxy debugging tool to simulate very slow speeds. Maybe a similar tool exists on what ever OS you are using.
I remember I once had the same question and my search turned up an Apache2 module that goes by the name of mod_bw (mod_bandwith that is). It served me well for my testings.
Okay, for some reason this morning, I am unable to connect to the Wordpress SVN repository and execute basic svn commands (e.g. checkout, update).
Here's an example of what's happening:
$ svn co http://svn.automattic.com/wordpress/tags/3.3/
# Adds a bunch of files...
svn: warning: Error handling externals definition for '3.3/wp-content/plugins/akismet':
svn: warning: PROPFIND of '/!svn/vcc/default': could not connect to server (http://plugins.svn.wordpress.org)
Checked out revision 19597.
$ cd 3.3
$ svn update
svn: OPTIONS of 'http://svn.automattic.com/wordpress/tags/3.3': could not connect to server (http://svn.automattic.com)
Yet, when I perform these same commands on a development server I have (a Linode VPS) it works fine.
I've google around about this quite a bit, and found pages like these:
http://vsingleton.blogspot.com/2008/04/svn-propfind-request-failed-on.html
http://wordpress.org/support/topic/cant-connect-to-the-pluginssvnwordpress-server
A lot of these articles say something to effect of, it's your proxy server. Well, I'm not behind a proxy server:
http://whatismyipaddress.com/proxy-check
Proxy server not detected.
IP 24.21.xxxx.xxx
rDNS FALSE
WIMIA Test FALSE
TOR Test FALSE
Loc Test FALSE
Header Test FALSE
DNSBL Test FALSE
Just a regular old Comcast home internet connection.
Also, I can browse the wordpress SVN repository just fine via my browser.
Anyhow, I'm sort of at a dead end here, and I guess I'm wondering if anyone has any suggestions as to how to either solve the issue or work around it? I tried setting up an forward proxy server on the Apache installation I have running on that dev server and then updating my ~/.subversion/server file, but that didn't work or I configured something wrong.
Well, if anyone has any brilliant ideas or explanations, I'd love to hear them...
Update
I had a co-worker test this out on his home connection -- he uses Comcast as well. He got the same error as I did. So it appears to be some Comcast-related issue specific to the Wordpress svn repository. I was able to checkout other public repositories via http (e.g. from Google Code) just fine.
I ran a series of tests and I could not find any hidden proxies or cache servers between me and the repository.
I did run traceroute per Lazy Badgers suggestion, and here's what I got:
$ traceroute svn.automattic.com
traceroute to svn.automattic.com (72.233.56.196), 64 hops max, 52 byte packets
1 192.168.1.1 (192.168.1.1) 0.659 ms 0.292 ms 0.185 ms
2 * * *
3 te-5-7-ur01.hollywood.or.bverton.comcast.net (68.85.150.225) 8.792 ms 8.309 ms 9.054 ms
4 xe-3-1-0-0-ar03.beaverton.or.bverton.comcast.net (68.87.216.33) 14.354 ms 24.859 ms 8.753 ms
5 pos-3-8-0-0-cr01.sacramento.ca.ibone.comcast.net (68.86.95.117) 21.869 ms
pos-3-1-0-0-cr01.sacramento.ca.ibone.comcast.net (68.86.95.113) 21.791 ms
pos-3-0-0-0-cr01.sacramento.ca.ibone.comcast.net (68.86.95.109) 22.983 ms
6 pos-0-7-0-0-cr01.sanjose.ca.ibone.comcast.net (68.86.85.46) 23.682 ms 25.043 ms 24.675 ms
7 xe-10-3-0.edge1.sanjose1.level3.net (4.71.118.5) 61.048 ms 23.986 ms 24.221 ms
8 vlan80.csw3.sanjose1.level3.net (4.69.152.190) 25.257 ms 25.648 ms
vlan90.csw4.sanjose1.level3.net (4.69.152.254) 24.310 ms
9 ae-82-82.ebr2.sanjose1.level3.net (4.69.153.25) 24.870 ms
ae-92-92.ebr2.sanjose1.level3.net (4.69.153.29) 25.371 ms
ae-91-91.ebr1.sanjose1.level3.net (4.69.153.13) 24.744 ms
10 ae-34-34.ebr4.sanjose1.level3.net (4.69.153.34) 36.011 ms 25.975 ms 36.053 ms
11 ae-5-5.ebr2.sanjose5.level3.net (4.69.148.141) 25.236 ms 25.307 ms 25.305 ms
12 ae-6-6.ebr2.losangeles1.level3.net (4.69.148.201) 31.299 ms 34.076 ms 33.401 ms
13 ae-3-3.ebr3.dallas1.level3.net (4.69.132.78) 59.012 ms 58.604 ms 60.576 ms
14 ae-83-83.csw3.dallas1.level3.net (4.69.151.157) 59.708 ms 65.724 ms
ae-73-73.csw2.dallas1.level3.net (4.69.151.145) 60.383 ms
15 ae-42-90.car2.dallas1.level3.net (4.69.145.196) 60.636 ms
ae-22-70.car2.dallas1.level3.net (4.69.145.68) 59.572 ms 59.758 ms
16 databank-ho.car2.dallas1.level3.net (4.71.170.2) 58.711 ms 59.994 ms 60.561 ms
I don't know if that's unusual or anything. I tried the same on my dev sever and the result looked mostly similar, save for line 2 with the * * *.
I successfully configured a forward proxy on my dev server so I've hacked together a solution for now, but I still don't quite understand what is afoot...
Update 2
In response to a question, here's how I configured things to use my dev server as a proxy for the time being.
First, I configured apache on my dev server to run as a proxy. Make sure these directives are somewhere in your Apache configuration file chain (httpd.conf, vhosts.d directory, etc.):
Listen 8080
<VirtualHost _default_:8080>
ProxyRequests On
ProxyVia On
ProxyPreserveHost On
<Proxy *>
Order deny,allow
Deny from all
Allow from xxx.xxx.xxx.xxx
</Proxy>
</VirtualHost>
This assumes you have a working Apache set up on a development server somewhere (I would definitely not use this on a production server) with mod_proxy installed. Port 8080 is arbitrary. Basically for an unmatched virtual host (i.e. any request that doesn't match your other hosts you have set up) it will turn proxy on and proxy the request through. Change "xxx.xxx.xxx.xxx" to your own IP address.
Now you have to change the server setting in your subversion config file.
In this file:
~/.subversion/servers
Find this section:
[global]
# http-proxy-exceptions = *.exception.com, www.internal-site.org
# http-proxy-host = proxy1.some-domain-name.com
# http-proxy-port = 80
# http-proxy-username = defaultusername
# http-proxy-password = defaultpassword
# http-compression = no
# http-auth-types = basic;digest;negotiate
# No http-timeout, so just use the builtin default.
# No neon-debug-mask, so neon debugging is disabled.
# ssl-authority-files = /path/to/CAcert.pem;/path/to/CAcert2.pem
Uncomment out http-proxy-host and http-proxy-port. For host use a spare domain name you have mapped to your development server or presumably you could just use your server IP. Then set the port to 8080 or whatever you used.
This should route all subversion http requests via your proxy you just set up. It doesn't affect svn or svn+ssh requests.
This was my quick hack, your mileage may vary, this might be totally insecure or broken, etc.
I have Comcast business both at my home office & the corporate office.
BOTH FAIL TO CONNECT TO THE REPO ON COMCAST.
However, I never have a problem if I go over the Windstream T1 or connect via our live server on multiple backbones.
Comcast appears to be "traffic shaping" and/or monitoring business class traffic and breaking the Internet!
Nice job Comcast!
If you don't have an alternate connection they you may need to use a proxy service and then send Comcast a nasty email about their network filtering.
I'm trying to setup a stress/load test using the WCAT toolkit included in the IIS Resources.
Using LogParser, I've processed a UBR file with configuration. It looks something like this:
[Configuration]
NumClientMachines: 1 # number of distinct client machines to use
NumClientThreads: 100 # number of threads per machine
AsynchronousWait: TRUE # asynchronous wait for think and delay
Duration: 5m # length of experiment (m = minutes, s = seconds)
MaxRecvBuffer: 8192K # suggested maximum received buffer
ThinkTime: 0s # maximum think-time before next request
WarmupTime: 5s # time to warm up before taking statistics
CooldownTime: 6s # time to cool down at the end of the experiment
[Performance]
[Script]
SET RequestHeader = "Accept: */*\r\n"
APP RequestHeader = "Accept-Language: en-us\r\n"
APP RequestHeader = "User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.0.3705)\r\n"
APP RequestHeader = "Host: %HOST%\r\n"
NEW TRANSACTION
classId = 1
NEW REQUEST HTTP
ResponseStatusCode = 200
Weight = 45117
verb = "GET"
URL = "http://Url1.com"
NEW TRANSACTION
classId = 3
NEW REQUEST HTTP
ResponseStatusCode = 200
Weight = 13662
verb = "GET"
URL = "http://Url1.com/test.aspx"
Does it look OK?
I execute the controller with this command: wcctl -z StressTest.ubr -a localhost
The Client(s) is executed like this: wcclient localhost
When the client is executed, I get this error: main client thread Connect Attempt 0 Failed. Error = 10061
Has anyone in this world ever used WCAT?
I'd look at updating to WCat 6.3 - available here for x86 and here for x64
They've changed the settings/scenario file strucutures, which is a little painful, but should suit your needs.
I've just started evaluating wcat 6.3 and I'm afraid my experience has been a bit disapointing in terms of online support/community.
There is also a major bug in the wcat.wsf script - see:
http://forums.iis.net/t/1153312.aspx
I'm now struggling with getting performance counter measurement working.
I've had good success with WCAT, though I'm struggling with simulating NTLM connections.
I'm using 6.3, so my config files look very different from yours. Some gotchas I noted along the way:
+ Make sure you've got your firewall turned off, or holes punched through for WMI.
+ Each thing you set in the request header has a tremendous impact on throughput. Apples to apples must have the same request headers.
+ Remote calls with multiple clients work only after correcting the bug identified by sthorogood.
Once I crossed those hurdles, I got great results from WCAT. It tests quickly, repeatably, and aggressively.
Best of luck,
Kevin
I don't have an answer for you, but have you considered using other tools for your testing? The WCAT tools seems pretty limited and complicated to use.
OpenSTA and JMeter are good open source tools for load/stress/performance testing.
OpenSTA and JMeter looks very Apache like. I'm running IIS on Windows Server 2003.
Have you looked at the Microsoft Web Application Stress Tool?
for performance counter you can define -p .prf in the same command run for controller as:
wcctl -c config.txt -d distribution.txt -s script.txt -a localhost - p performance.prf