Re: [AOLSERVER] Ns_RegisterAtReady, NsRunAtReadyProcs
Dossy Shiobara schrieb: On 2007.10.13, Tom Jackson [EMAIL PROTECTED] wrote: This all looks great, except for the fact that the NsRunAtReadyProcs proc is never called. But, you're absolutely right: we need to figure this out, one way or another. Thanks for finding this. The question, why the patch helped is indeed a miracle. Maybe it changed the timing or causes a different serialization due to a mutex. However, it did NOT solve the underlying problem. Activated by Tom's question, i spent some more time on the problem and managed to reproduce the problem reliably. The problem actually happend when the number of available connection threads is configured very low, as well as the the number of requests per connection thread (e.g. 5 and 3). When the server accepts a high number of requests, these are queued even without guaranteeing resources to process these. The situation is especially bad with bursty requests. When a connection thread exits e.g. after 3 requests, and there are still many requests queued, there is no mechanism to automatically trigger new connection threads in this situation. When a client connects in this situation to the server, some old (maybe obsolete) requests are taken from the queue, but after this, the server might sit idle even with a high number of requests queued. I have commited a patch to cvs head, that processes these pending requests, even when maxconns is exceeded. Maybe it is better to restart exiting connection threads automatically or to limit the number of queued requests at first hand; or maybe there is a callback solution. However. I have removed the old - useless - patch from the head version in CVS. best regards -gustaf neumann -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Ns_RegisterAtReady, NsRunAtReadyProcs
On Friday 19 October 2007 12:46, Jeff Rogers wrote: Looking at it slightly more deeply, the AtReady callback shouldn't be needed, because TriggerDriver is called from NsFreeConn, which is called every time through the ConnThread loop after the connections have been put back on the free list. This is one thing that I noticed, TriggerDriver is called in more places, but the point seems to be to update any statistics, and also to return conns. And of course, the driver doesn't need triggering when a lot of requests are coming in, only when the server starts to reap stale or used up threads. One thing which seems different is that the driver doesn't hold on to requests, they are queued, so there is no reason for threads to need to do a TriggerDriver in order to get a new conn (assuming one is in the queue). In other words, the TriggerDriver is used to return stuff to the driver thread, not to signal ready. At least one thing is still missing here: if there is a -timeout on the thread wait, all threads will end up exiting, going past minthreads. If -timeout is set to 0, threads will exit and are not replaced when this ends up leaving less than minthreads available. If you get surges of requests, a timeout of zero would help a little to keep from continuously creating new threads. tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
[AOLSERVER] Problem with Apache Bench: 2c-1 requests
When I run apache bench like this: $ ab -n 3 -c 3 http://192.168.1.102:8000/bgwrite/sns-thumb.jpg I expect that it will send exactly three requests using three different connections. In fact, the summary tells me exactly that: -- Server Software:AOLserver/4.5.0 Server Hostname:192.168.1.102 Server Port:8000 Document Path: /bgwrite/sns-thumb.jpg Document Length:28672 bytes Concurrency Level: 3 Time taken for tests: 6.21440 seconds Complete requests: 3 Failed requests:0 Write errors: 0 Total transferred: 86658 bytes HTML transferred: 86016 bytes Requests per second:0.50 [#/sec] (mean) Time per request: 6021.440 [ms] (mean) Time per request: 2007.147 [ms] (mean, across all concurrent requests) Transfer rate: 13.95 [Kbytes/sec] received - But last week I noticed something weird, then forgot about it. If the concurrency was 'c', I would get 'c-1' extra requests. These were logged in the defective prequeue filter in the driver thread before being queued. The access log also recorded extra hits. For instance, the above command to ab will produce exactly 5 access.log entries. I noticed this again today when I did 50 requests with concurrency=50. I got 99 requests logged, but apache bench checked out early and did the report after 50. I only noticed this because I had only one thread configured and there was a 0-5 second delay for each request. Long after the report showed up, AOLserver was chugging away logging what it was doing, and the access log did the same. So I thought either AOLserver is duplicating this stuff or Apache Bench is doing it. I guess if I had considered the fact that AOLserver has no idea what the concurrency is, it would have been obvious. I then used netstat to show if there were actually 5 connections or just three: Prior to running ab: Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp1 0 192.168.1.101:33180 207.228.252.10:80 CLOSE_WAIT tcp0 0 127.0.0.1:9997 127.0.0.1:56705 ESTABLISHED tcp0 0 127.0.0.1:56705 127.0.0.1:9997 ESTABLISHED tcp0 0 192.168.1.101:45825 216.211.130.179:110 TIME_WAIT Just after running ab: Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp1 0 192.168.1.101:33180 207.228.252.10:80 CLOSE_WAIT tcp1 0 192.168.1.102:8000 192.168.1.102:49737 CLOSE_WAIT tcp1 0 192.168.1.102:8000 192.168.1.102:49736 CLOSE_WAIT tcp0 0 192.168.1.102:8000 192.168.1.102:49735 TIME_WAIT tcp0 0 192.168.1.102:8000 192.168.1.102:49734 TIME_WAIT tcp0 0 192.168.1.102:8000 192.168.1.102:49733 TIME_WAIT tcp0 0 192.168.1.102:49737 192.168.1.102:8000 FIN_WAIT2 tcp0 0 192.168.1.102:49736 192.168.1.102:8000 FIN_WAIT2 tcp0 0 192.168.1.102:49738 192.168.1.102:8000 TIME_WAIT ... The extra two are in CLOSE_WAIT, from ports 49736-7 I'm not sure what the exact significance of this is, but we are benchmarking stuff which we are not sure is working. It appears that the tool I am using is somewhat broken itself. I wonder if this analysis is correct, and if so, are there other benchmarking tools we could use? tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Ns_RegisterAtReady, NsRunAtReadyProcs
On Friday 19 October 2007 03:17, Gustaf Neumann wrote: I have commited a patch to cvs head, that processes these pending requests, even when maxconns is exceeded. Maybe it is better to restart exiting connection threads automatically or to limit the number of queued requests at first hand; or maybe there is a callback solution. However. I have removed the old - useless - patch from the head version in CVS. More on the patch and the problem. Your code comment is that: +request is queued without resources to process these. +One has to take care about that one restarts the queue, when +resources become available again. The only way the driver thread could guess if a queue has resources is to look at the number of maxthreads, making sure it is at least 1. But it would only be a guess, it could instantly change to zero if someone decided to zero out the threadpool. How exactly does the patch work? It appears to simply extend the tour-of-duty for a thread, but does the exiting thread ever get to trigger the queue to create new threads? This seemed to be the issue several users noticed: exiting threads never cause the queue to reassess the situation. At the very least, it seems that when a thread exits, the queue checks if the number of threads is less than minthreads, and if so, creates a new thread, but also creates a new thread if minthreads = 0 and there are queued requests. Then the queue should loop over requests creating threads for queued requests until it reaches maxthreads. Okay, maybe restate this: the queue should loop over requests up to the point of reaching maxthreads. If there is a spike in activity, it is best to immediately respond with more threads up to the limit. I think the opposite iw what is happening. Once threads die, it is nearly impossible to get the number of threads back up, and threads is how long requests are handled, otherwise the wait time is additive. tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] WARNING: dns queries will use non-threadsafe calls
Enrique, You don't have the threadsafe versions, or configure didn't find them. tom jackson On Friday 19 October 2007 08:19, Enrique Catalan wrote: checking for gethostbyname_r... no checking for gethostbyaddr_r... no configure: WARNING: dns queries will use non-threadsafe calls which -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Ns_RegisterAtReady, NsRunAtReadyProcs
On Friday 19 October 2007 03:17, Gustaf Neumann wrote: The problem actually happend when the number of available connection threads is configured very low, as well as the the number of requests per connection thread (e.g. 5 and 3). When the server accepts a high number of requests, these are queued even without guaranteeing resources to process these. I know this is true, several months ago I configured a threadpool with zero threads after startup. The driver thread will still send requests to the threadpool queue, where it will sit forever. Also, if you then configure the threadpool with more threads after going to zero, they are never created. I also noticed that you should be able to trigger the driver by calling the Tcl command [ns_driver query ...], so maybe an experiment with a scheduled proc would be interesting: put the server into the unresponsive mode and see if it gets unstuck. The log should show the scheduled thread running, then hopefully the server unsticking. Otherwise it isn't necessarily the driver thread which is stuck, so triggering it would be pointless. I can try running my tests again with 3-5 threads, what other parameters were there? Does this get stuck running OpenACS on any machine, or just on openacs.org? Okay, just read Gustaf's comments on his patch, there might be a problem with the configuration on openacs.org, see below... The situation is especially bad with bursty requests. When a connection thread exits e.g. after 3 requests, and there are still many requests queued, there is no mechanism to automatically trigger new connection threads in this situation. When a client connects in this situation to the server, some old (maybe obsolete) requests are taken from the queue, but after this, the server might sit idle even with a high number of requests queued. As above, I wonder if the driver thread and the exiting connection thread should signal the queue thread? There seems to be something not complete with the queue loop. Also, Gustaf, the maxconnections should be higher...with maxconnections=3 you are exiting a connection thread every three requests, is this how you want it to work? If resources are limited, this isn't going to help. I have commited a patch to cvs head, that processes these pending requests, even when maxconns is exceeded. Maybe it is better to restart exiting connection threads automatically or to limit the number of queued requests at first hand; or maybe there is a callback solution. However. I have removed the old - useless - patch from the head version in CVS. Very interesting, I'll look into this more today. One thing I didn't try was a configuration where maxconnections was lower than the number of simultaneous requests from Apache Bench. tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Ns_RegisterAtReady, NsRunAtReadyProcs
Jeff, I don't have a problem with it being in, but it actually needs to do something we can measure. There are significant overall differences between 4.0.10 and 4.5, although if you look at small parts it seems the same. Just as an example, the patch in driver.c was hundreds of lines off from 4.0.10 to 4.5. Somehow Gustaf has been able to reproduce the fix with just the driver.c change, and the new fix he is trying out also works. I'm not sure we understand why either of them work quite yet, or if they will continue to work...and that is the real problem. Magical fixes are nice, but in the long we might need to know more about it. I have ab run without either fix and never had a problem. Actually the call was in driver.c, but the function body was a noop, it never even registered the TriggerDriver, the AtReadyProcs fuction was completely removed, not even defined. To me this only means that I don't know how to reproduce the bad behavior, but at least it didn't cause any difference for me. tom jackson On Friday 19 October 2007 11:11, Jeff Rogers wrote: I'm thinking the call to NsRunAtReadyProcs should be re-added in. It was apparently removed a long time ago, just after 4.0.10 was released: http://aolserver.cvs.sourceforge.net/aolserver/aolserver/nsd/queue.c?r1=1.2 4r2=1.25 As the api was not being used at all it was fine to remove it, until it became useful for this race condition :) I haven't successfully reproduced the problem in 4.5 yet (or read the code deeply, but the main connection service loop - queue.c:NsConnThread - is not significantly different now) so it may be a different underlying problem than the one I described, but it should be an easy test to see if adding the AtReady callbacks back into the end of the loop helps things. -J But, you're absolutely right: we need to figure this out, one way or another. Thanks for finding this. -- Dossy -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Ns_RegisterAtReady, NsRunAtReadyProcs
Dossy Shiobara wrote: On 2007.10.13, Tom Jackson [EMAIL PROTECTED] wrote: This all looks great, except for the fact that the NsRunAtReadyProcs proc is never called. In 4.5, that appears to be the case. In 4.0, it's called from nsd/queue.c. I'd need to look more closely at the code to see if we should remove those functions entirely in 4.5 or if there's actually a missing call to NsRunAtReadyProcs() somewhere. I'm thinking the call to NsRunAtReadyProcs should be re-added in. It was apparently removed a long time ago, just after 4.0.10 was released: http://aolserver.cvs.sourceforge.net/aolserver/aolserver/nsd/queue.c?r1=1.24r2=1.25 As the api was not being used at all it was fine to remove it, until it became useful for this race condition :) I haven't successfully reproduced the problem in 4.5 yet (or read the code deeply, but the main connection service loop - queue.c:NsConnThread - is not significantly different now) so it may be a different underlying problem than the one I described, but it should be an easy test to see if adding the AtReady callbacks back into the end of the loop helps things. -J But, you're absolutely right: we need to figure this out, one way or another. Thanks for finding this. -- Dossy -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Ns_RegisterAtReady, NsRunAtReadyProcs
Tom Jackson schrieb: I can try running my tests again with 3-5 threads, what other parameters were there? Does this get stuck running OpenACS on any machine, or just on openacs.org? As written before, i set maxthreads to 5 and maxconnections to 3 to trigger the problem. I did not mess with openacs.org, but reproduced the problem under mac os x. Also, Gustaf, the maxconnections should be higher...with maxconnections=3 you are exiting a connection thread every three requests, is this how you want it to work? yes, i wanted to trigger the bug. When the problem occured, openacs.org had different settings (maxthreads 5 maxconnections 10). Very interesting, I'll look into this more today. One thing I didn't try was a configuration where maxconnections was lower than the number of simultaneous requests from Apache Bench. That is not the point. Run ab with more parallel requests than maxthreads, such that requests queue up. As long as maxconnections is high enough, the connection threads will process the queued requests. If the number of queued requests is higher than the number of maxconns, matters degrade. Having one or two queued requests on a thread exit (due to maxconn exceeded) is no real problem, since on the next request, a new thread is started, which will care about the queued request as well. That means, that under good conditions, it is possible that there are e.g. 10 requests queued, but a slow and steady heartbeat of request will cause the queue to empty itself, such that aolserver recovers. The worst case scenario is actually maxconnections 1 (stop every connection thread after every request). In this situation (without my patch) if a queue piles up, it is never shrinking. Actually, if minthreads is set to a value 0 (it was not set), then idle threads should care about queued requests. Maybe the easier fix is to set minthreads per default to 1. I will try this, when i am back home (in a couple of hours). How exactly does the patch work? It appears to simply extend the tour-of-duty for a thread, yes but does the exiting thread ever get to trigger the queue to create new threads? no, i have not modified anything in this regard. When a thread processes all queued requests before exiting, there is no urgent need to create a new connection request. The next incoming request will create a new thread on demand. Once threads die, it is nearly impossible to get the number of threads back up, i have not observed this in my test, the problem appears with reaching maxthreads. This does not exclude, that there might be another problem. -gustaf neumann -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
[AOLSERVER] WARNING: dns queries will use non-threadsafe calls
Hi, I tried to compile Aolserver4.5 for unix and got weird warning message and was wondering if you know how to get rid of that, I hadn't got this before. The messages I got are: % /usr/local/tcl8.4.16/bin/tclsh8.4 nsconfig.tcl -install /usr/local/aolserver4.5/ Executing ./configure TCLSH=/usr/local/tcl8.4.16/bin/tclsh8.4 --prefix=/usr/local/aolserver4.5 --with-tcl=/usr/local/tcl8.4.16/lib checking for Tcl configuration... found /usr/local/tcl8.4.16/lib/tclConfig.sh checking for existence of /usr/local/tcl8.4.16/lib/tclConfig.sh... loading checking for build with symbols... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h .. . yes checking for unistd.h... yes checking for inttypes.h... (cached) yes checking for timegm... no checking for fork1... no checking for drand48... yes checking for random... yes checking for _NSGetEnviron... no checking for poll... yes checking dl.h usability... no checking dl.h presence... no checking for dl.h... no checking need for dup high... no checking for shared libgcc... no checking for getaddrinfo in -lsocket... no checking for getnameinfo in -lsocket... no checking for getaddrinfo... no checking for getnameinfo... no checking for gethostbyname_r... no checking for gethostbyaddr_r... no configure: WARNING: dns queries will use non-threadsafe calls which could result in server instability configure: creating ./config.status config.status: creating include/ns.mak % Thanks! -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Ns_RegisterAtReady, NsRunAtReadyProcs
I just started another thread about using apache bench. I'm not sure if it is
working as advertised, and I wonder if it might be misleading us with the
testing of this potential race condition fix.
Using the most recent version of queue.c, I have been able to create a timeout
on the apache bench test. That is, the client gets stuck and eventually times
out and quits.
The ab command was:
$ ab -t 500 -n 50 -c 1 http://192.168.1.102:8000/bgwrite/sns-thumb.jpg
There is a rotation of 0-5 sec delay built in to this, so even with a 28k
file, it takes a while to chew through 50 requests. (about 101 sec). The -t
500 appears to be a useless option, ab always times out much quicker than
this value.
Now how to get ab stuck and give up? I use a regular browser (mozilla), and I
try to load the same image, I hit reload like 5-7 times or so. The number of
reloads is larger than the number of maxconns per thread. There is only one
thread working.
What may be happening is that the keepalive system is expiring the thread all
by itself (one client with keepalive). Even though there is a queue, maybe
the sock and therefore the conn are being reused, giving no other requests a
chance. The last log entry indicates that the thread has processed too many
conns and is exiting. Then ab freezes. However, if I reload the page one more
time in the browser, ab starts up again.
I still think all the evidence points to a logical error of deleting a thread
and then not maintaining at least one thread (and prefer minthreads) if there
is something in the queue. This isn't a race condition, I don't think,
because it is easy to repeat this: it happens exactly the same way every
time.
This might not be easy to do correctly because killing threads is part of
shutting down, so a thread might want to die because of a shutdown, not
because maxconns was reached, or a timeout.
In driver.c here is the keep-alive section:
/*
* Process Sock's returned for keep-alive or close.
*/
while ((sockPtr = closePtr) != NULL) {
closePtr = sockPtr-nextPtr;
if (!stop sockPtr-state == SOCK_READWAIT) {
sockPtr-connPtr = AllocConn(drvPtr, now, sockPtr);
SockWait(sockPtr, now, drvPtr-keepwait, waitPtr); /* --keep*/
} else if (!drvPtr-closewait || shutdown(sockPtr-sock, 1) != 0) {
/* Graceful close diabled or shutdown() failed. */
SockClose(sockPtr);
} else {
SockWait(sockPtr, now, drvPtr-closewait, waitPtr);
}
}
So it looks like a keep-wait socket is immediately put to the head of the line
looking for more requests from the same client. If you have a web page with
50+ images, you can easily blow out any reasonable maxconns setting, or if
someone reloads a less heavy page.
tom jackson
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] Problem with Apache Bench: 2c-1 requests
apache bench mark will dispatch requests up until it's received -n number of responses. e.g. with concurrency of 3 (c1, c2, c3), and -n 3 requests c1 - send request 1 c2 - send request 2 c3 - send request 3 c1 - response 1 # of responses 3 c1 - send request 4 c2 - response 2 # of responses 3 c2 - send request 5 c3 - response 3 # of responses 3 wait for clients to end and report Hopefully if the above makes sense, you should see that ab will continue to dispatch requests until it gets all the necessary responses back. Since ab 1.3 it's acted like this, same sort of thing with microsoft stress tool, JMeter is probably the only thing I've found accurate enough for precision testing rather than capacity testing. HTH P Tom Jackson wrote: When I run apache bench like this: $ ab -n 3 -c 3 http://192.168.1.102:8000/bgwrite/sns-thumb.jpg I expect that it will send exactly three requests using three different connections. In fact, the summary tells me exactly that: -- Server Software:AOLserver/4.5.0 Server Hostname:192.168.1.102 Server Port:8000 Document Path: /bgwrite/sns-thumb.jpg Document Length:28672 bytes Concurrency Level: 3 Time taken for tests: 6.21440 seconds Complete requests: 3 Failed requests:0 Write errors: 0 Total transferred: 86658 bytes HTML transferred: 86016 bytes Requests per second:0.50 [#/sec] (mean) Time per request: 6021.440 [ms] (mean) Time per request: 2007.147 [ms] (mean, across all concurrent requests) Transfer rate: 13.95 [Kbytes/sec] received - But last week I noticed something weird, then forgot about it. If the concurrency was 'c', I would get 'c-1' extra requests. These were logged in the defective prequeue filter in the driver thread before being queued. The access log also recorded extra hits. For instance, the above command to ab will produce exactly 5 access.log entries. I noticed this again today when I did 50 requests with concurrency=50. I got 99 requests logged, but apache bench checked out early and did the report after 50. I only noticed this because I had only one thread configured and there was a 0-5 second delay for each request. Long after the report showed up, AOLserver was chugging away logging what it was doing, and the access log did the same. So I thought either AOLserver is duplicating this stuff or Apache Bench is doing it. I guess if I had considered the fact that AOLserver has no idea what the concurrency is, it would have been obvious. I then used netstat to show if there were actually 5 connections or just three: Prior to running ab: Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp1 0 192.168.1.101:33180 207.228.252.10:80 CLOSE_WAIT tcp0 0 127.0.0.1:9997 127.0.0.1:56705 ESTABLISHED tcp0 0 127.0.0.1:56705 127.0.0.1:9997 ESTABLISHED tcp0 0 192.168.1.101:45825 216.211.130.179:110 TIME_WAIT Just after running ab: Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp1 0 192.168.1.101:33180 207.228.252.10:80 CLOSE_WAIT tcp1 0 192.168.1.102:8000 192.168.1.102:49737 CLOSE_WAIT tcp1 0 192.168.1.102:8000 192.168.1.102:49736 CLOSE_WAIT tcp0 0 192.168.1.102:8000 192.168.1.102:49735 TIME_WAIT tcp0 0 192.168.1.102:8000 192.168.1.102:49734 TIME_WAIT tcp0 0 192.168.1.102:8000 192.168.1.102:49733 TIME_WAIT tcp0 0 192.168.1.102:49737 192.168.1.102:8000 FIN_WAIT2 tcp0 0 192.168.1.102:49736 192.168.1.102:8000 FIN_WAIT2 tcp0 0 192.168.1.102:49738 192.168.1.102:8000 TIME_WAIT ... The extra two are in CLOSE_WAIT, from ports 49736-7 I'm not sure what the exact significance of this is, but we are benchmarking stuff which we are not sure is working. It appears that the tool I am using is somewhat broken itself. I wonder if this analysis is correct, and if so, are there other benchmarking tools we could use? tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank. -- Patrick O'Leary You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat. - Albert Einstein View Patrick O Leary's profile -- AOLserver - http://www.aolserver.com/ To Remove
