Greetings... You can renice the program, but that is not going to solve your problem. I am not following you on the "speediest perl program runs slow" part. CPU usage is based on demand and the kernel balancing the system load. If the program is doing I/O (reading large file or something) then there is little CPU work involved for the program. That becomes an I/O wait issue. The idea is to isolate the specific bottleneck in your code. I have had perl programs use 100% CPU before, but not many. Almost everything I write has either wait states or file I/O to slow it down. Whatever the CPU usage is on an idle system is the fastest it will ever run regardless of how much you nice it. Queuing the jobs would be handy if you think that would solve the problem. If you are mostly I/O bound and especially if you are reading from the same file, then this sounds like a good direction. Read the file once by a single program instead of by 20 or so. I wrote a web based reporting tool that created reports from a very large Oracle database. To prevent multiple users from launching a ton of reports and killing the system, I created a queuing daemon. Process just runs in the background as a daemon and receives job requests on an socket. Not sure if that is a solution for you, but it allows you to manage jobs. I do not see how anyone could create a perl utility to do this. Seems way too specialized a task. But I have been wrong before, so... HTH :) Jeremy Elston Sr. Staff Unix System Administrator Electronic Brokerage Technology Charles Schwab & Co., Inc. (602.977.4413 [EMAIL PROTECTED]) "Are you still here? What are you doing? There is nothing left to read. The e-mail is over. Move on... Go on - get out of here. SHOO!" WARNING: All email sent to this address will be received by the Charles Schwab Corporate email system and is subject to archival and review by someone other than the recipient -----Original Message----- From: jna [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 06, 2001 8:49 PM To: Edward Moon Cc: Erick Nelson; [EMAIL PROTECTED] Subject: Re: [Perl-unix-users] Multiple Invocation Casusing Slow downs > You don't provide much detail on what the script does and how your > environment is configured. So, I've had to make some assumptions for the > following suggestions: > > 1) Cache data: If the script runs without requiring data from the end > user, can you cache the results in a file? You then read from the file if > it is no more than (for example) 5 minutes old. Otherwise, you recreate > the data and rewrite the cache file. For one of the script this is basically what it does, for instance it will show who is logged into the system at this time, it will opne a file containing the name and email address of the users logged in to the system. The file it reads from is generated by another program. The program executes and runs fine and fast as long as alot of people are not request a run of the file. But i beleive even the speedyest perl program runs slow at only say 8% available cpu time? > 2) Change your architecture: If you're using Apache and regular CGI, you > can experience a significant speed up by moving to mod_perl. There are > issues involved with migrating to mod_perl (including whether or not you > will be allowed to install a mod_perl enable Apache on your server). > Checkout <http://perl.apache.org/> for more details on mod_perl. Yes, i actually tried a migration using mod_perl on my apache and ended up scrapping it. Due to the nature of my system using these scripts and the shared data between them, it was totally uncompatible and would require a total rewrite of over 40 perl programs to use it, same with fast cgi? Is there any perl utilitie that would allow a script to maintain a certain cpu level? I belive the system responce would greatly speed up if each script had an ample amount of cpu time while the other scripts where qued, as the delay would be so much smaller than 20 scripts sharing a very small cpu resource? Any thoughts? John > On Tue, 6 Nov 2001, jna wrote: > > > > > Hello, > > > > I was wondering if anyone knew how to attack this? If say this script when i > > run it via the web as the only one running it - it then executes and > > displays the required information in 10 seconds. Now if 20 people or even > > say 10 invoke this perl program via the web at the same time or within a few > > seconds of each other then it splits the cpu usage between the 10 or 20 > > invokations of the perl program. Now where the problem hits is even though > > the script works in a timely fashion at near 90+ percent cpu availability > > when mulitple instances of it are invoked and it is only gettin 8 or 10 or > > 15 or even 20 % per invokation the execution time is enormous as much as 3 > > minutes to complete and display. Whats even worse is most people become > > impatiant and hit reload cause even more cpu splitting between the scripts > > slowing it down even more? > > > > Now how do you attack something like this? > > > > Example: > > > > 6:40pm up 8 days, 19:22, 1 user, load average: 2.52, 1.90, 1.76 > > 79 processes: 72 sleeping, 7 running, 0 zombie, 0 stopped > > CPU states: 96.0% user, 3.9% system, 0.0% nice, 0.0% idle > > Mem: 257408K av, 165968K used, 91440K free, 55132K shrd, 49504K > > buff > > Swap: 265528K av, 1996K used, 263532K free 69040K > > cached > > > > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM CTIME COMMAND > > 16787 nobody 20 0 2584 2584 1188 R 20.0 1.0 0:01 > > prog1.pl > > 16786 nobody 20 0 2920 2920 1220 R 18.2 1.1 0:01 > > prog2.pl > > 16785 nobody 20 0 2560 2560 1220 R 18.0 0.9 0:01 > > prog3.pl > > 16791 nobody 20 0 2584 2584 1188 R 16.4 1.0 0:00 > > prog4.pl > > 16781 nobody 16 0 2464 2464 1220 R 15.8 0.9 0:05 > > prog5.pl > > > > Thanks, > > John > > [EMAIL PROTECTED] > > > > > > > > _______________________________________________ > > Perl-Unix-Users mailing list. To unsubscribe go to http://listserv.ActiveState.com/mailman/subscribe/perl-unix-users > > > > _______________________________________________ > Perl-Unix-Users mailing list. To unsubscribe go to http://listserv.ActiveState.com/mailman/subscribe/perl-unix-users > _______________________________________________ Perl-Unix-Users mailing list. To unsubscribe go to http://listserv.ActiveState.com/mailman/subscribe/perl-unix-users _______________________________________________ Perl-Unix-Users mailing list. To unsubscribe go to http://listserv.ActiveState.com/mailman/subscribe/perl-unix-users
