Help me with threads issue !

C

Charlie

Hi Folks,
I need some help from you about the thread issue I have.
What I want to do is to simulate multi users to access one web server.
I want to simulate as many as 200 users to assess that web server to
check the performance from both the web server and the backend DB.

The ways that I emploment it are: 1). to have the apache(version
1.3.31) installed on the Linux platform. 2) I am using the perl
5.8.4, along with some perl modules, such as Mechanize, threads to
create the test scripts. And I put the test scripts under the dir of
(Apache)/cgi-bin/.
In that way, I can enter the user number from the browser from
anywhere and can do the rest of work by just clicking one button.

Following is part of my main function:
"package LoadTest;
....
use threads;
use threads::shared;

my ($Input_value, %Inputs, $total);
my $CGIobj = new CGI;
%Inputs = $CGIobj->Vars;

my @threads;
for ( 1..$Inputs{UserNumber} ) {
my $thread;
$thread = new threads(\&Case1, \%Inputs);
push(@threads, $thread);
}
$_-> join foreach(@threads);

}

sub Case1 {
....
}
"
As you can see, I am trying to create a certain amount of
threads(users) to invoke the same function,"Case1".

During the runtime, that program runs perfectly fine if there are 20
users, but when I give more users, such as 50, or even 100, something
is going wrong.
For example, once I submit 100 users, on that linux platform, I can
see the amount threads keeps growing untill it reaches that number.
Then before the sub-function calls are finished, all the threads are
exit at once, without any indications, as if they are being killed

Can someone tell me what might be the problem, all maybe you can give
me a better way to work around this. I need to do the simulations of
as many as 200 users.

Thanks a lot for the help !!!


CJ
 
K

Kevin Collins

Hi Folks,
I need some help from you about the thread issue I have.
What I want to do is to simulate multi users to access one web server.
I want to simulate as many as 200 users to assess that web server to
check the performance from both the web server and the backend DB.

The ways that I emploment it are: 1). to have the apache(version
1.3.31) installed on the Linux platform. 2) I am using the perl
5.8.4, along with some perl modules, such as Mechanize, threads to
create the test scripts. And I put the test scripts under the dir of
(Apache)/cgi-bin/.
In that way, I can enter the user number from the browser from
anywhere and can do the rest of work by just clicking one button.

Following is part of my main function:
"package LoadTest;
...
use threads;
use threads::shared;

my ($Input_value, %Inputs, $total);
my $CGIobj = new CGI;
%Inputs = $CGIobj->Vars;

my @threads;
for ( 1..$Inputs{UserNumber} ) {
my $thread;
$thread = new threads(\&Case1, \%Inputs);
push(@threads, $thread);
}
$_-> join foreach(@threads);

}

sub Case1 {
....
}
"
As you can see, I am trying to create a certain amount of
threads(users) to invoke the same function,"Case1".

During the runtime, that program runs perfectly fine if there are 20
users, but when I give more users, such as 50, or even 100, something
is going wrong.
For example, once I submit 100 users, on that linux platform, I can
see the amount threads keeps growing untill it reaches that number.
Then before the sub-function calls are finished, all the threads are
exit at once, without any indications, as if they are being killed

Can someone tell me what might be the problem, all maybe you can give
me a better way to work around this. I need to do the simulations of
as many as 200 users.

Thanks a lot for the help !!!

Just a guess, but you may be hitting a system kernel parameter limiting the max
threads per process.

Kevin
 
B

Ben Morrow

Quoth (e-mail address removed) (Charlie):
I need some help from you about the thread issue I have.
What I want to do is to simulate multi users to access one web server.
I want to simulate as many as 200 users to assess that web server to
check the performance from both the web server and the backend DB.

The ways that I emploment it are: 1). to have the apache(version
1.3.31) installed on the Linux platform. 2) I am using the perl
5.8.4, along with some perl modules, such as Mechanize, threads to
create the test scripts. And I put the test scripts under the dir of
(Apache)/cgi-bin/.

Under linux (or any other platform which implements fork decently) there
is no point in using ithreads unless you need the functionality of
threads::shared (and even then, you can use forks.pm from CPAN to
simulate it). Forking will be both faster and safer.

Ben
 
V

Vetle Roeim

Quoth (e-mail address removed) (Charlie):

Under linux (or any other platform which implements fork decently) there
is no point in using ithreads unless you need the functionality of
threads::shared (and even then, you can use forks.pm from CPAN to
simulate it). Forking will be both faster and safer.

Interesting. I tested my example in <[email protected]>
with forks.pm, and at first it seemed to work. However, if I modify
the object inside the thread, the changes do not seem to propagate to
the originating thread as it does _without_ forks.pm.

I've searched on google (including groups.google.com) for information
on threading in Perl, and I'm under the impression that it has improved
alot lately.
 
B

Ben Morrow

Quoth "Vetle Roeim said:
Interesting. I tested my example in <[email protected]>
with forks.pm, and at first it seemed to work. However, if I modify
the object inside the thread, the changes do not seem to propagate to
the originating thread as it does _without_ forks.pm.

I have to say I've never used forks; but did you use forks::shared as
well as forks? I would be inclined *not* to use forks myself, but
implement some other IPC mechanism as needed.
I've searched on google (including groups.google.com) for information
on threading in Perl, and I'm under the impression that it has improved
alot lately.

Perl ithreads now effectively perform a fork in userland, without using
copy-on-write. This has removed the problems with 5005threads, sure, but
it has also removed any point in using threads on an OS which can fork.
The OS will *always* be able to do it faster.

Ben
 
V

Vetle Roeim

[...]
I have to say I've never used forks; but did you use forks::shared as
well as forks? I would be inclined *not* to use forks myself, but
implement some other IPC mechanism as needed.

Doh! I forgot about that one ... It worked perfectly when I included
forks::shared. :)

Btw; if I read the POD for forks correctly, then this shouldn't work
(see the TODO section). Um... ?

Perl ithreads now effectively perform a fork in userland, without using
copy-on-write. This has removed the problems with 5005threads, sure, but
it has also removed any point in using threads on an OS which can fork.
The OS will *always* be able to do it faster.

I'm going to try to create some kind of thread/process pool, so the speed
of creating new threads/processes will hopefully not be much of an issue.

I'll experiment a little bit with/without forks and see how things work
out. :)
 
V

Vetle Roeim

I've searched on google (including groups.google.com) for information

Perl ithreads now effectively perform a fork in userland, without using
copy-on-write. This has removed the problems with 5005threads, sure, but
it has also removed any point in using threads on an OS which can fork.
The OS will *always* be able to do it faster.

I discovered something interesting when testing forks.pm. Parts of my
code totally unrelated to the part where I use a thread pool were
significantly slower /with/ forks, than without!

My code parses some stuff and enters into a database (DBI, MySQL).
I timed the different parts of the code, and here are the results:

forks:
100 trials of parse (96.031ms total), 960us/trial
100 trials of db (7.906s total), 79.061ms/trial

threads:
100 trials of parse (92.693ms total), 926us/trial
100 trials of db (70.068ms total), 700us/trial

Interesting, indeed.
 
B

Ben Morrow

Quoth "Vetle Roeim said:
Doh! I forgot about that one ... It worked perfectly when I included
forks::shared. :)

Btw; if I read the POD for forks correctly, then this shouldn't work
(see the TODO section). Um... ?

Yeah, well... documentation is notoriously out-of-date wrt code,
especially TODO lists ;)
I'm going to try to create some kind of thread/process pool, so the speed
of creating new threads/processes will hopefully not be much of an issue.

I'll experiment a little bit with/without forks and see how things work
out. :)

I will say again:

On an OS with fork, don't use threads and don't use forks. Use fork
directly, or through something like Parallel::ForkManager. Do IPC
yourself via traditional mechanisms: pipes, sockets, SysV shared mem,
mmap.

ithreads are a useful alternative to fork on platforms that don't have
it. forks is a useful implementation of the threads API in terms of
forking and sockets, for programs that need to be portable to both
has-fork and has-ithreads. It doesn't sound to me like you need to be
bound by either of those, so don't be.

Ben
 
V

Vetle Roeim

[...]
I will say again:

On an OS with fork, don't use threads and don't use forks.
Aha.

Use fork
directly, or through something like Parallel::ForkManager. Do IPC
yourself via traditional mechanisms: pipes, sockets, SysV shared mem,
mmap.

Well... ithreads fits very nicely into my solution. It didn't take
me long to create my own working thread pool, where I send data to
the different threads using Thread::Queue.

I apologize if I seem slow, but what is wrong with ithreads? As far
as I know they are slower to start than forking, and they're memory
hungry, but other than that; are there any other problems I should be
aware of?

ithreads are a useful alternative to fork on platforms that don't have
it. forks is a useful implementation of the threads API in terms of
forking and sockets, for programs that need to be portable to both
has-fork and has-ithreads. It doesn't sound to me like you need to be
bound by either of those, so don't be.

On the other hand; my program doesn't need to be portable. ;o)
 
B

Ben Morrow

Quoth "Vetle Roeim said:
Well... ithreads fits very nicely into my solution. It didn't take
me long to create my own working thread pool, where I send data to
the different threads using Thread::Queue.

Fair enough.
I apologize if I seem slow, but what is wrong with ithreads? As far
as I know they are slower to start than forking, and they're memory
hungry, but other than that; are there any other problems I should be
aware of?

Not really. It just seems to me a terrible waste to implement fork in
userspace when the OS already does it perfectly well :).

Ben
 
V

Vetle Roeim

Can you expand on the "completely unrelated" part? Do you mean this code
is run after "use forks" statement, but before any forks are actually
made?

Yes. There make be some use of threads/forks/whatever that I don't know
of, but the explicit use of threads/forks in _my_ code happens after
the code I benchmarked.

I could try moving the "use forks" statement, though. Hmmmmm...


[...]
 
C

ctcgag

Vetle Roeim said:
I discovered something interesting when testing forks.pm. Parts of my
code totally unrelated to the part where I use a thread pool were
significantly slower /with/ forks, than without!

Can you expand on the "completely unrelated" part? Do you mean this code
is run after "use forks" statement, but before any forks are actually
made?

Xho
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,994
Messages
2,570,223
Members
46,812
Latest member
GracielaWa

Latest Threads

Top