1) apr_time_now(): We have some concern about the accuracy of the
timings, especially on a Windows platform. Unix is using the
gettimeofday() system call, which is pretty standard, then outputs the
calculated value of microseconds based on the returned structure.
Windows (win32) uses a GetSystemTime() call, and then two other calls to
convert that ultimately to an acceptable form in microseconds (I
understand that the granularity available to Windows is really limited
to milliseconds). I was interested in knowing whether using any of these
intermediate functions limits the accuracy, what is the real timing
granularity available from these operating systems (or the limitations
of trying to read time in this manner), and how the operating systems
manage to maintain the system time while juggling other threads and
processes which request it in real time.
2) When attempting to use a load testing tool we have been developing
with the help of the Apache library, to similate 200 users which are
being generated over a cable modem connection, the apr_socket_connect()
function returns a non-zero value, which from a Windows system
represents its WSAETIMEDOUT error code. Current Apache Flood also
displays the same error, and I get similar socket connection failures
when running my same system using the Linux operating system (Red Hat
7.3) after I recompiled the same software to run from it. I am guessing
that the error is probably a result of not having enough bandwidth
through my cable modem connection to sustain 200 simultaneous
connections (to get responses quickly enough); (a) does this sound
reasonable?
(b) Is there any way to tweak "connect()" so that it allows more time
for the socket to connect, or is trying to simulate 200 users just
asking for too much in that arena (when communicating over cable modem)?
