I have used LWP (LWP::UserAgent, HTTP::Response, HTTP::Cookies, etc.) to write a test harness for web apps. Since I was working with an ancient Perl version, I went low tech for load testing. Write a test case that hammers a server with 1 or a few requests (possibly rotating through different data values). It is easy to run 40 or 50 of these in the background. Wa la - a saturated server.
I have found, however, that the Crypto::SSLeay module needed for SSL apps does not re-use the SSL session. Thus, the SSL handshaking becomes the CPU bottleneck. For development environments, this has not been a big enough issue for us to update Crypto::SSLeay to do the SSL session reuse. Shouldn't be too difficult, tho. Any load test _is_ a DOS attack to anyone else trying to use the system. Don't do this on Internet facing systems or even systems in a remote LAN unless you are ready to pay the packet charges. I have found it all but impossible to saturate a local ethernet subnet, however. Just make sure no one else is using the system before you crash it! At 11:42 AM 5/25/2005 -0400, Bogart Salzberg wrote: >On May 25, 2005, at 8:20 AM, Joel Gwynn wrote: > > > how many > > users/day the current setup can support > >You could use LWP::UserAgent from a remote machine to automate >requests in rabbit mode (fork and sleep). The UA could get or post >forms to simulate registration, login, queries, etc., with >HTML::LinkExtor scraping more links to follow, (if applicable) and >Time::HiRes benchmarking response times for varying numbers of >concurrent 'users'. Is WWW::Mechanize more appropriate for this sort of thing? > >Then again, this approach could qualify as a DoS attack, if you share hosting. > >Bogart > >_______________________________________________ >Boston-pm mailing list >[email protected] >http://mail.pm.org/mailman/listinfo/boston-pm _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
