two questions about perl

Discussion in 'Perl Misc' started by Charlie, May 12, 2004.

  1. Charlie

    Charlie Guest

    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::place_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
     
    Charlie, May 12, 2004
    #1
    1. Advertising

  2. In article <>,
    Charlie <> wrote:
    :1. Let's say in one of my single test case, following events happening
    : User::place_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::DProf 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.
    --
    What is "The Ultimate Meme"? Would it, like Monty Python's
    "The World's Funniest Joke", lead to the deaths of everyone who
    encountered it? Ideas *have* lead to the destruction of entire cultures.
    -- A Child's Garden Of Memes
     
    Walter Roberson, May 12, 2004
    #2
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. GenxLogic
    Replies:
    3
    Views:
    1,375
    andrewmcdonagh
    Dec 6, 2006
  2. Weirong Zhu

    Two questions about perl

    Weirong Zhu, Aug 13, 2003, in forum: Perl Misc
    Replies:
    3
    Views:
    88
    Simon Andrews
    Aug 14, 2003
  3. Rong Hu
    Replies:
    3
    Views:
    98
    Rong Hu
    Apr 5, 2006
  4. Flamingo

    two questions about RE from perl novice.

    Flamingo, Feb 9, 2007, in forum: Perl Misc
    Replies:
    0
    Views:
    87
    Flamingo
    Feb 9, 2007
  5. Flamingo

    two questions about RE from perl novice.

    Flamingo, Feb 9, 2007, in forum: Perl Misc
    Replies:
    0
    Views:
    70
    Flamingo
    Feb 9, 2007
Loading...

Share This Page