two questions about perl

[Charlie]

Hi folks,
I have created some test cases which are written in perl and used to
test some web applications. And I have two issues here about PERL,
1. Let's say in one of my single test case, following events happening
User:lace_an_order()
Manager::approveOrder()
Approver::approveOrder()
Manger::giveConfirmation()
Each event is being called in a seperate function. The question that I
have is how can I calculate the seconds being used for each function
call? I do not want the timing is that acculate, but simple, and easy
to use.

2. I want to simulate multiple transactions running at the same time
to check the time consuming. The way that I am doing now is by using
the Thread. I am just a beginner for the Thread, and the code that I
am using now is :
"
....
thread1 = Thread->new(\&eachSession);
thread2 = Thread->new(\&eachSession);
$_->join foreach($thread1, $thread2);
....
"
My feeling is it is not scalable, if one thread is broken somewhere,
the whole running will be dead. And it does not make sense to me, as
if I need to have 100 transactions, I need to create 100 threads and
have them joined together.
So any comments? Good module I may use ?


thanks a lot


CJ

 

[Walter Roberson]

:1. Let's say in one of my single test case, following events happening
: User:lace_an_order()
: Manager::approveOrder()
: Approver::approveOrder()
: Manger::giveConfirmation()
:Each event is being called in a seperate function. The question that I
:have is how can I calculate the seconds being used for each function
:call? I do not want the timing is that acculate, but simple, and easy
:to use.

my $starttime = time();
Manager::approveOrder()
my $endtime = time();
my $elapsed_time = $endtime - $starttime.

I also suggest you check out the Devel:Prof module from CPAN.


:2. I want to simulate multiple transactions running at the same time
:to check the time consuming. The way that I am doing now is by using
:the Thread. I am just a beginner for the Thread, and the code that I
:am using now is :

:thread1 = Thread->new(\&eachSession);
:thread2 = Thread->new(\&eachSession);
:$_->join foreach($thread1, $thread2);

:My feeling is it is not scalable, if one thread is broken somewhere,
:the whole running will be dead.

Depends what you mean by 'broken' and 'will be dead'. Each thread
will start running as you Thread->new it, and the question becomes whether
you need to get results from the thread back to the spawning routine,
and whether you want notification as the thread finishes. Each thread
*naturually* dies when the invoked procedure (&eachSession() in your case)
finishes through any mechanism short of major internal perl corruption.
As far as perl is concerned, there is no difference between a thread
terminating because it has run out of things to do, and the thread
terminating because (for example) it tried to divide by 0.

The join foreach that you show will have the effect of holding up
the main thread waiting for $thread1 to finish, and not doing anything
else in the main thread until it does (even if it infinite loops...).
When the end of $thread1 is detected, the main thread would then look
for the end of $thread2; if $thread2 had already terminated before
$thread1 did, then the result (return value) of $thread2 will be
immediately available, and if $thread2 had not yet finished, then
the main thread would wait for it.


:And it does not make sense to me, as
:if I need to have 100 transactions, I need to create 100 threads and
:have them joined together.

I think you have misunderstood 'join'. You do not use 'join'
to place a thread into execution. You only use 'join' to get back
the results of a thread when it has finished (waiting until it -has-
finished if necessary.) If you do not -need- the results of the thread,
you can use

$thread1 = Thread->new(\&eachSession);
$thread1->detach();


I note, by the way, that you are using the 'Thread' module, which
implies 5005threads .

Finally, note that there are many known serious problems
with the 5005threads, one of the least of which is that
regular expression match variables like $1 are not
threadsafe, that is, they easily get corrupted by competing
threads. Other problems include more insidious data
corruption and mysterious crashes. You are seriously urged
to use ithreads instead.

If you can use perl5.8, you are much better off using threads->new
(or threads->create) instead of Thread->new : much more stable!


Creating 100 threads does not really emulate a load equivilent to 100
simultaneous accesses. Each time you create a new ithread, the entire
set of variables of the calling thread is duplicated. That can end up
using a *lot* of memory unless you plan very carefully. For example,
if you build a big hash table first, the entire hash table will be
duplicated (unless it is marked as being sharable.)

At an operating system level, threads are intended to be "lightweight",
less expensive to create than processes -- but 100 actual users would
be 100 actual processes (unless you are using mod_perl perhaps.) In
theory, 100 actual processes should be harder on the system; in
practice, ithreads are still very expensive to create, and 100 threads
is probably more expensive than 100 processes (especially if your perl
is compiled to use a shared libperl library instead of as one big
program.)

If you expect 100 users simultaneously, then your code will need
good resource locking to ensure that (for example) one newly placed
order does not overwrite another. The way you impliment that locking
is going to differ noticably between the case of running 100
threads and the case of running 100 different processes. In turn,
the way you lock is going to make a difference to the timing.
First you have to get the code -right- with respect to locking;
only -then- should you be considering fine-tuning the code for
efficiency.