> 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
