httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: Use of apr_sleep() in Flood, and apr_psprintf
Date Tue, 18 Feb 2003 00:33:08 GMT

On Monday, February 17, 2003, at 12:15  PM, Norman Tuttle wrote:

> Just a brief introduction. We are using Flood as a backbone to create 
> an
> "engine" for a multi-platform load testing system with a GUI front end 
> and
> in a Websphere / SQL environment. I have been making modifications to
> Flood, mostly running on a Win32 environment but also under Linux, to
> perform our needed functionality. More will be said about the type of
> functionality we are providing and what bug fixes and upgrades we can
> provide to Flood in a future post. For now I focus on a few APR 
> concerns.

Very cool! I'd love to hear more about what you're working on.

> It concerns me that Flood is using apr_sleep() to create delays which 
> are
> used as part of threads. Being familiar with the use of threads from a
> graduate course, and having access to IBM documentation on DCE 
> threads, I
> note that their documentation cautions against the use of the sleep()
> system function when using multithreaded packages. Not that sleep() is 
> not
> thread-compliant but that it will cause the current process to sleep 
> and
> not the thread. This means that all threads in the current process are 
> not
> being executed while the process is going to sleep. I don't think that
> this is the desired behavior in Flood for when APR_HAS_THREADS because 
> it
> would mean that for those periods of time, Flood is not being involved 
> in
> load test (or any useful activity). I believe I have seen times when 
> this
> behavior is observed while running Flood. A website I was browsing
> recently gave an example using POSIX threads, and cautioned not to use
> sleep() because of this issue, recommending instead something like
> oskit_pthread_sleep(), which is actually an extension to POSIX threads.
>    Windows implementation of apr_sleep() is Sleep(); Linux uses a 
> select()
> with the last argument being non-zero. Don't know if the Windows Sleep 
> is
> executed as a hold on the process level but my Unix documentation for
> select seems to indicate that it applies the wait on a process level.
> Perhaps I am wrong and this is not an issue; but I was hoping that 
> someone
> with more of an operating system or multithreading background (or the
> designers of the original code, etc.) would be able to shed light on
> whether this is an issue or not (and if so, why not), and if it is an
> issue, how we can code a bug fix or a valid solution.

This will greatly depend on both your kernel's implementation of the
sleep syscall, and the thread library you are using. If you use a
purely userspace thread library (for example, GNU Pth), and if that
library doesn't implement shims for standard sys calls, you may be
setting your process in an interruptible sleep mode, which will fail
as you have described.

You'll have to experiment with this on your systems to see if the
sleep calls are causing problems. I haven't seen any problems with
Linux using LinuxThreads, but I haven't really had any problem teaching
flood to scale well. Solaris also seems to perform quite well running
flood.

>    apr_psprintf() is another function used in Flood. I had a problem 
> with
> some of the formatting options while using this function, and some 
> other
> concerns, so I looked into the code and found a comment that some
> assumptions were made. It seems that those assumptions involved an 
> order
> of operations which might not hold true in a multithreaded case.
> Therefore, I reconstructed the functionality of apr_psprintf in such a 
> way
> as to not make the assumptions in the comments, by using a feature of a
> function which it already calls, and used this new function locally (I
> called it print_to_pool) without modifying the version of the apr. I
> haven't seen the type of problems I was seeing earlier since I made 
> this
> switch. I can make this code available upon request.

I don't totally understand what the initial problem was, but if you have
a patch to APR, I'd love to see it. Feel free to post it here if it
relates to flood, or on the dev@apr.apache.org list if it's just 
APR-specific.

thanks for the feedback, and we welcome any contributions you might 
have,
-aaron


Mime
View raw message