Thread: [htmltmpl] speeding up an h-t website on a windoze box
Brought to you by:
samtregar
From: Puneet K. <pk...@ei...> - 2004-04-17 19:10:17
|
I want to experience the dizzying effect of speed on Windoze. Mod_perl is out because the server might be running IIS (and even if it isn't, I am sure my script will have to be re-hacked). I was hoping for IPC-SharedCache, but that doesn't seem possible on Win. I tried CGI-Simple for some modest speed increase, but that croaked because I am also using CGI-Session and I couldn't figure out how to make CGI-Session work with CGI-Simple. Other than simply increasing the hardware capability, are there any insights on what I can do? My app is a single cgi script and uses DBI, Storable, CGI, CGI-Session, and, of course, H-T. Thanks. |
From: Cees H. <ce...@si...> - 2004-04-17 19:44:09
|
Puneet Kishor wrote: > I want to experience the dizzying effect of speed on Windoze. > > Mod_perl is out because the server might be running IIS (and even if it > isn't, I am sure my script will have to be re-hacked). > > I was hoping for IPC-SharedCache, but that doesn't seem possible on Win. > > I tried CGI-Simple for some modest speed increase, but that croaked > because I am also using CGI-Session and I couldn't figure out how to > make CGI-Session work with CGI-Simple. > > Other than simply increasing the hardware capability, are there any > insights on what I can do? > > My app is a single cgi script and uses DBI, Storable, CGI, CGI-Session, > and, of course, H-T. Have a look at FastCGI which should be supported in IIS. Also checkout SpeedyCGI (also known as Persistent Perl), although I don't know if it works on Windows, as I don't use windows myself. Those two options will keep the perl interpreter in memory, so that you save the startup times on your CGI script. Also, if coded right, you can keep a persistent database connection using this as well. If that doesn't help, then you need to profile your code to see where the bottlenecks are. Chances are your database access will be the biggest bottleneck, but that is a generalization and depends completely on your code. See Devel::DProf for info on how to profile your code. Cheers, Cees |
From: Sam T. <sa...@tr...> - 2004-04-17 19:55:04
|
On Sat, 17 Apr 2004, Puneet Kishor wrote: > Mod_perl is out because the server might be running IIS (and even if it > isn't, I am sure my script will have to be re-hacked). > > I was hoping for IPC-SharedCache, but that doesn't seem possible on Win. Have you tried the file_cache option? All it needs is Storable, so it should work on Windows. On Linux it's as fast as the shared_cache, although I don't know much about how fast the Windows file-system is. > Other than simply increasing the hardware capability, are there any > insights on what I can do? Figure out what's actually taking the most time. You can do that by using a profiler like Devel::DProf. Since you're using DBI you can also use DBI's built-in profiler to examine the performance of your database queries. Most likely HTML::Template isn't take a significant amount of time in your application. Usually network delays and database calls take much longer than HTML::Template. -sam |
From: Puneet K. <pk...@ei...> - 2004-04-17 20:04:46
|
On Apr 17, 2004, at 2:53 PM, Sam Tregar wrote: > On Sat, 17 Apr 2004, Puneet Kishor wrote: > >> Mod_perl is out because the server might be running IIS (and even if >> it >> isn't, I am sure my script will have to be re-hacked). >> >> I was hoping for IPC-SharedCache, but that doesn't seem possible on >> Win. > > Have you tried the file_cache option? All it needs is Storable, so it > should work on Windows. On Linux it's as fast as the shared_cache, > although I don't know much about how fast the Windows file-system is. Thanks for the advice. I will try it. > >> Other than simply increasing the hardware capability, are there any >> insights on what I can do? > > Figure out what's actually taking the most time. You can do that by > using a profiler like Devel::DProf. Since you're using DBI you can > also use DBI's built-in profiler to examine the performance of your > database queries. > > Most likely HTML::Template isn't take a significant amount of time in > your application. Usually network delays and database calls take much > longer than HTML::Template. > > Oh, I don't think H-T is necessarily the one taking time (wasn't my intent to seem to blame H-T). I think it is just the way it is with all the other modules, and the script being cgi and all. I figured that with all the modules I am loading, and my own script, that is probably well over 10k, maybe even 20k lines of code being chewed through every user click. Which is why I tried CGI-Simple, because CGI is really, really heavy. Since I can't use mod_perl (though, as Cees suggested, FastCGI might, might be an option -- SpeedyCGI is not; it doesn't run on Windows), seems like the only thing I could possibly cache was H-T. Hence the question about IPC-SharedCache. I'll try shared_cache and try to measure the difference. Thanks. |
From: David H. <da...@ho...> - 2004-04-17 20:12:56
|
On 17 Apr 2004, at 21:04, Puneet Kishor wrote: > Oh, I don't think H-T is necessarily the one taking time (wasn't my > intent to seem to blame H-T). I think it is just the way it is with > all the other modules, and the script being cgi and all. > > I figured that with all the modules I am loading, and my own script, > that is probably well over 10k, maybe even 20k lines of code being > chewed through every user click. Which is why I tried CGI-Simple, > because CGI is really, really heavy. > > Since I can't use mod_perl (though, as Cees suggested, FastCGI might, > might be an option -- SpeedyCGI is not; it doesn't run on Windows), > seems like the only thing I could possibly cache was H-T. Hence the > question about IPC-SharedCache. The compilation of the code is what's killing you. There *is* some kind of perl persistence module for IIS, or of course you *could* run apache/mod_perl on win32. -- Dave Hodgkinson CTO, Rockit Factory Ltd. http://www.rockitfactory.com/ Web sites for rock bands |
From: Sam T. <sa...@tr...> - 2004-04-17 20:58:43
|
On Sat, 17 Apr 2004, David Hodgkinson wrote: > The compilation of the code is what's killing you. Don't be so sure. All it takes is one missed index in a critical table and all the Perl caching in the world won't save you! -sam |
From: David H. <da...@ho...> - 2004-04-17 21:43:35
|
On 17 Apr 2004, at 21:56, Sam Tregar wrote: > On Sat, 17 Apr 2004, David Hodgkinson wrote: > >> The compilation of the code is what's killing you. > > Don't be so sure. All it takes is one missed index in a critical > table and all the Perl caching in the world won't save you! Heh, OK, I was presuming the ability to run some kind of process monitor and making the first cut ;-) Let's insert the caveats "assuming a sensible database..." and also a "...then given a non-compute intensive perl layer..." My best speedup on a gig was 1000x. 10x from adding an index, 10x from mod_perling and 10x from making one machine into 5 dual process boxes. PS: I'm usually a Template Toolkit user, but my current work was originally H::T and CGI::Application oriented. I've thrown HTML::FillInForm and it's rather sweet. H::T does just enough in just the right way. -- Dave Hodgkinson CTO, Rockit Factory Ltd. http://www.rockitfactory.com/ Web sites for rock bands |