Re^3: Profiling/Benchmarking web applications.

The other replies have addressed some of the reactions I have regarding TT taking 60% of the response time. I have a few further questions.

60% of what? Is it 10 seconds? 1 minute? 1 second?
Are you using mod_perl? That one single item will often cut 50% of your response time. And, it's a change that's transparent to the CGI scripts.¹
Are you using a ton of nested BLOCK directives?
Are you doing things like
```
[% foo = $bar.baz %]
[% baz = qux.$foo %]
[download]
```
That does a lot of eval work behind the scenes, which can be expensive.
How deep are your nested loops? Nesting loops don't scale linearly, in any templating system. HTML::Template, which is arguably the most efficient commonly used templating system has serious performance problems with loops nested 3+ deep.
Can you compile and/or cache the output from some of your templates?
Are you making calls to the database in your templates using the DBI plugin?

Assuming, of course, you used sane coding standards. Persistence can be a bitch if you're converting the first CGI script you ever wrote to run under MP::Registry.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

Comment on Re^3: Profiling/Benchmarking web applications. Download Code

Replies are listed 'Best First'.
Re^4: Profiling/Benchmarking web applications. by jryan (Vicar) on Aug 25, 2004 at 18:36 UTC
Well... Approx 1.25 seconds; caching the compiled templates took it down to approx 1 second. yes no no, I'm use .item when working with nested hashes Now that's something I didn't know. The main data section has nested loops four-deep. Column order is defined in a config file, so we do something like this: `[% FOREACH set IN [data_header.top_priority, data_header.middle_priority] %] [% FOREACH fieldno IN set %] [% field = data_header.field.slice(fieldno, fieldno).0 %] [% value = order.item(make_key(field.title)) ...` [download] Which probably isn't very nice to the TT processor. I wasn't, but I am now. No, calls to the database are made through callback functions.	[reply] [d/l]
Re^5: Profiling/Benchmarking web applications. by dragonchild (Archbishop) on Aug 25, 2004 at 18:52 UTC
No, calls to the database are made through callback functions. I guess I wasn't being specific enough. In apps using H::T, all database activity has to be completed before H::T can be used. However, TT allows you to make database calls while TT is running, and it sounds like you're using that functionality. One way, obviously, is to use the DBI plugin. Another way is use callback functions, as you're using. I'll bet 1000XP that if you were to benchmark how much of the template time is being spent in those callbacks, it'll be at least 50%. Also, I'm not a TT expert, but `[% field = data_header.field.slice(fieldno,fieldno).0 %]` looks horribly inefficient. Woudn't `[% field = data_header.field.$fieldno %]` suffice? Update: Fixed to jryan's reply. ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply] [d/l] [select]
Re^6: Profiling/Benchmarking web applications. by jryan (Vicar) on Aug 25, 2004 at 19:18 UTC
Wouldn't that have to be `[% field = data_header.field.$fieldno %]`, which uses eval?	[reply] [d/l]
Re^7: Profiling/Benchmarking web applications. by dragonchild (Archbishop) on Aug 25, 2004 at 19:22 UTC
Re^8: Profiling/Benchmarking web applications. by jryan (Vicar) on Aug 25, 2004 at 19:30 UTC