Bass <[EMAIL PROTECTED]> writes:
> At 06:36 PM 8/8/2001 +0200, you wrote:
> >"David N. Welton" wrote:
> ...
> >I wanted to check and see how opinions run regarding this? Concerns?
> >>Things you'd like to see?
> >My only wish (and concern, too) is that mod_dtcl won't trade off
> >speed for new features. Remember that most potential mod_dtcl users
> >are people with a large base of Tcl scripts and applications that
> >run as CGI and, as a first approach, they will try a 'quick port'
> >with a minimal rewrite of their code.
This is what I have mod_dtcl squarely aimed at, and I don't intend to
deviate too much from it. I want it to be fast, light and simple. I
also want it to be modular, though, so that people can add all kinds
of stuff and make it do what they need.
> Hey, it sounds like you're talking about me! I did a 'quick port'
> of numerous Tcl CGIs over to mod_dtcl. My main objective was to
> conserve system resources by sharing interpreters, as some of the
> CGIs were pretty hefty search engines.
Once the runtime of the CGI starts to get long, the savings from
avoiding a fork is less, although you should still get some benefits
from the cacheing.
> I have since attempted to optimize the code a little bit. One of
> the major things I did was to load the database from a file and
> store it in an array in my own namespace. eg: ::myspace. With this
> method, I only have to load the large database once from file. For
> subsequent queries, I can access it directly from the array if it
> exists.
Yeah, that's the right way to do it:-)
> This is all fine and good, except that each httpd child appears to
> running its own interpreter. So each child has to load a copy of
> each of the databases. This in and of itself isn't that big of a
> deal. Yes, it uses resources unnecessarily a little, but I can live
> with it.
Certain things just can't be shared amongst seperate processes.
> What bothers me is when someone clicks on 'stop' or 'back' in the
> middle of a database search. If they then start a new search, it
> often ends up on a different httpd child. Because of this, one
> abusive user could very easily tie up many system resources. I'd
> like to be able to use a one-search-at-a-time method, disallowing
> additional searches from that user until the results from that
> user's first search were returned. But to do this, each httpd child
> must know what every other child is doing.
Heh - how to make http a stateful protocol/how to do interprocess
comunication...;-)
There are a number of ways of doing it. Cookies, shared mem, and so
on. Use the database instead of a flat file somewhere...
> Admittedly, this could be done by maintaining a current-activity log
> file. But I'd prefer to keep the file read-writes down to a
> minimum. It would be easier if I could keep track of current
> activity in an array in memory that every child could access.
You could have a look at the shared mem extensions for Tcl. I wrote a
simplistic one myself, available on the debian page, below.
> Is it possible to access the environment of the other httpd
> children? If so, it has eluded me so far, and I haven't seen a
> solution in the documentation, either.
No, not easily and not in a standard way. It's just not really
possible in unix by default, unless the children export data they want
kept in common...
> As a side discussion, I would appreciate hearing others' opinions on
> the benefits of using compiled Tcl (outside of mod_dtcl) to speed up
> a search engine and lower system overhead.
Compiled Tcl? You mean that compiler that A. Otto is always going off
about on the newsgroup?
> I was considering both, and I ended up going with mod_dtcl. A
> typical search query takes 5-15 seconds on the very low-end machine.
> To be honest, I haven't seen too much of a speed increase on
> searches by using mod_dtcl. I *think* the system load is a little
> bit better, though.
Your best bet is rewriting stuff in C, IMO. Find the bottlenecks and
optimize them...
--
David N. Welton
Free Software: http://people.debian.org/~davidw/
Apache Tcl: http://tcl.apache.org/
Personal: http://www.efn.org/~davidw/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
