[Openinteract-dev] Re: Random thoughts or: my time with Time::HiRes

[Chris W. <ch...@cw...>]

On Fri, 2001-12-28 at 16:09, And...@Be... wrote:
> Hi Chris,
> 
> still one of my favorite tasks with OI is finding out, how to tune it. Since
> I had no luck with Devel::DProf, I used Time::HiRes now and dug down into
> the code. Here some observations:

I'm curious -- can you run Devel::DProf if you start up the OI
environment outside of Apache? (LMK if you need an example of this.) I'm
more curious about performance aspects of SPOPS (tied hashes and all)
than about some other things. 
 
> - OpenInteract::Request::lookup_action gets called twice: once in
> OpenInteract::find_action_handler and once from
> OpenInteract::run_content_handler - how about caching this in $R ?

Good idea.

> - how about caching the results of lookup_action ?

Do you mean keep a table of URL -> action results? I don't think this is
necessary - lookup_action should be a fairly minor task since it's just
consulting an in-memory hash. And I'm planning to rewrite this action
dispatch stuff anyway.

> - when a user comes in with an existing session, I found, that all calls are
> done like when he first comes in. Why not cache things like groups, theme,
> etc inside the session ?

This isn't a bad idea at all. I'm a little concerned about stale session
info -- an administrator assigns a user to a group but the user doesn't
see the change take effect until a logout/login or a session refresh.
But we can deal with that.

> - I question the file based template caching stuff: I tried a simple process
> global hash based lookup inside OpenInteract::Template::Provider::fetch and
> it speeded this part up about factor 100 ! 

There are actually two pieces to template caching. First is the
file-based, which is really only good for persisting the templates
across server restarts. I wouldn't have done this if it took any effort,
but we get it for free with TT so why not.

TT should also be doing in-process template caching unless something is
fubared. So I'm curious why you got such a speedup...

Can you send me (offlist) your copy of OI::Template::Provider so I can
compare?

> - if I got the startup code right, at least
> OpenInteract::Startup->read_base_config is called twice: once at server
> startup, once at child init. This has nothing process specific in it, right?

Right. This is also a fairly minor task but we should get rid of the
duplication anyway.

> I think the static/global and dynamic/process parts need to be separated
> more obvious. The latest with apache 2.0 we will have threads to deal with
> in adition.. For now, the more work can be done at server startup, the
> better, I think, since this will just be copied over on fork(). This also
> holds for modules. Why don`t we pull in many more modules here?

First of all, you're right that the server/childinit stuff needs to be
separated better. Also, it would definitely be a good idea to pull in
more modules at server startup -- we actually used to do this a version
or two back. 

However, since I introduced SPOPS initialization code that uses
datasource handles (the 'field_discover' stuff, among other things) the
issue gets fairly complicated. I ran into a number of problems using
these features so I moved all the initialization to a child init
handler.

I think I can fix it if I modify how database handles are opened up and
stored, but I'm going to put that off for a bit.

> - totally different topic maybe: looking at the new base_page stuff - why
> not make actions just entries here? Wouldn`t it be nice to have this in one
> place? As I told you earlier, we think about tweaking some sort of dynamic
> handler into this already, but: actually I think this is totally unnecessary

Not sure I understand what you mean. A directory handler is just another
action that is aware it's a directory handler.

That said, this feature is very new so please continue playing :-)

> so far so good for now - hope this makes any sense ;-)

Lots -- thanks for the work!

C

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.