On Friday 13 June 2003 12:14, Cees Hek: I'm far from new to mod_perl, so yes, I've checked all the obvious stuff.
> - Are you only checking the first time you load the page? mod_perl still > needs to load all the perl modules on the first request to a page, unless > you have specifically pre-loaded them in the apache configuration. > Subsequent page loads should be faster. Benchmarking was done using an internal before and after check using Time::HiRes (as well as various stages during processing) as well as using "ab" to do multiple hits in succession. It is definitely cached code. Successive hits are using the persistent cached data as they should. > - are you using mod_perl2? I don't know enough about mod_perl2 to help > here, but possibly you are having thread issues with the threaded MPM. Nope. Definitely normal old mod_perl for Apache 1.3.x. > mod_perl should be just as fast as FastCGI as they achieve similar goals by > eliminating the perl startup and compile stages. If this doesn't help you, > then please provide more info on your setup. Hmmm. Problem is the config is complex, and the module itself is also very complex, so I didn't want to spam the list with tons of config info. I'll include some more info below... On Friday 13 June 2003 12:26, Perrin Harkins wrote: > > You're not giving us much to go on here. What kind of changes did you > make? Can you verify that you are running the correct versions of the > modules under mod_perl? Are you seeing generally about the same > performance on both platforms? What does you httpd.conf look like? Ok, EDO (the name of the app) parses HTML for additional custom markups, and then executes functionality based on those markups (putting it very simply). The general procedure for a request involves: - Creating an EDO::Parser object - Parsing HTML source into an internal structure (this can be cached to avoid caching on every request) - Executing instructions based on the parsed code The app does a lot of talking to databases - predominantly MySQL for testing. Minor optimisations were achieved by replacing some internal hash structures with arrays, using constants to index them. One major optimisation was replacing the conditional parsing module. I was using SQL::Statement, and fudging it to eval just the WHERE condition, to be able to do SQL-style conditionals. I replaced it with my own module, which again parses/compiles expressions into an external structure once, rather than doing it every time. As mentioned, these (and a few other misc changes) optimisations gave about a 25% speed boost for complex pages (such as long lists of data). Predominantly, it does lots of references and manipulations of arrays and hashes, it talks quite a bit to databases via DBI, and reads the occasional file from disk. It stores a persistent cache of "compiled" code, and it builds page output entirely in memory before output. All benchmarks I carried out on the same hardware platform, using the same HTML source files. The only thing I changed was whether it was parsed with the Apache Module version, or the FastCGI version. My Apache conf. is long and complex, since the systems I develop & tested this on do lots of other things. Config items that are related to mod_perl include: PerlFreshRestart On PerlModule Apache::Filter; PerlModule Apache::SSI; PerlModule CGI; PerlModule Apache::Resource; PerlSetEnv PERL_RLIMIT_AS 48:64 PerlChildInitHandler Apache::Resource I also use PerlRequire to pre-load several other modules used by the server. Although the mod_perl version of EDO can be used as an Apache::Filter, I turned it off for the benchmarks. > By the way, I don't understand your comment about how you developed with > FastCGI because it's easy to restart. Is there something about mod_perl > that makes it hard to restart for you? I always restart after every > code change since it takes me less than a second to do. On a server where there are other developers working on it, if I restart the server, it can interrupt others working. In addition, if I stuff something up badly (such as a minor syntax error), it doesn't kill the whole server. As a FastCGI, all I have to do to restart it is touch the main CGI file. I also have tighter control on the number of FastCGI processes, which is more useful for development. I also work on FastCGI as a low-ish denominator. There's less server impact to throw a FastCGI on, than to install mod_perl, if it's not already there. It's also closer to the normal CGi version of EDO, and the command-line version. If you want to know more about EDO itself, I've had it on Sourceforge for a while now: http://sourceforge.net/projects/edo/ Still, documentation is a little sketchy there, and it's still under development, even though it's used in production-level sites where I work. -- . Trevor Phillips - http://jurai.murdoch.edu.au/ . : Web Technical Administrator - [EMAIL PROTECTED] : | IT Services - Murdoch University | >--------------------------------------------------------------------< | On nights such as this, evil deeds are done. And good deeds, of / | course. But mostly evil, on the whole. / \ -- (Terry Pratchett, Wyrd Sisters) /
