You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by "David N. Welton" <da...@dedasys.com> on 2002/02/06 01:29:36 UTC
purge Apache ap_ from rivetCore.c
So, there are a some non-obvious things left before we can get rid of
Apache completely from rivetCore.c:
MakeURL:
Relies on an apache function.
Rivet_Parse:
Relies on a mod_rivet function which needs a 'dsc'. It needs
this so that it can do caching properly. Ugly situation...
Rivet_Headers:
This stuff just needs to be added to the TclWeb API.
Rivet_Upload:
A mess...
Rivet_NoBody:
Not sure how to implement this in a non-apache version. Maybe
it won't cause problems.
Rivet_AbortPageCmd:
Not sure how to make this translate into the CGI version of
the library.
Ideas?
--
David N. Welton
Consulting: http://www.dedasys.com/
Free Software: http://people.debian.org/~davidw/
Apache Tcl: http://tcl.apache.org/
Personal: http://www.efn.org/~davidw/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: purge Apache ap_ from rivetCore.c
Posted by "David N. Welton" <da...@dedasys.com>.
davidw@dedasys.com (David N. Welton) writes:
> > > Rivet_Upload:
> > > A mess...
>
> > This one promises to be very ugly. I don't envy whoever sits down
> > and hammers out the CGI version. Maybe for now I can see about
> > offloading the various bits into TclWeb.
>
> I can't for the life of me figure out an API I'm happy with:-( What
> a bitch...
Finally hammered something out. It isn't a thing of beauty, but we
are now left with only one bit of code in rivetCore.c that is Apache
specific - cookies.
I guess we could handle these from Tcl, using 'headers set'. I'm a
bit nervous about screwing too much with the apreq code though - I
don't want to get so far out of sync that we spend time maintaining
our diff's.
Anyway, we more or less have an API for the TclWeb stuff. Now is the
time for those who want to fill in the TclWebcgi.c part of it to step
forward:-)
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: purge Apache ap_ from rivetCore.c
Posted by "David N. Welton" <da...@dedasys.com>.
Damon Courtney <da...@your.unreality.com> writes:
> Also. Apache 2.0 is rapidly approaching some final ticks. Do
> we need to start looking at developing with mod_tcl? Do we need to
> start developing mod_tcl itself more?
My (admittedly vague) idea is to develop a Rivet module that could be
loaded into mod_tcl to handle parsing. It needs to stay fast, but I
think the flexibility gained would be worthwhile.
In my opinion, though, Apache 2.0 is not worth worrying about for now.
It might be released sooner rather than later, but I doubt we'll see
it on production systems for a while yet.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Memory usage
Posted by "David N. Welton" <da...@dedasys.com>.
Damon Courtney <da...@your.unreality.com> writes:
> Now, with some very early memory cleanup code that I'm now
> working on, the same test produced 'httpd' processes that went from
> 3M each to 7M each after taking 50k hits. This is quite an
> improvement over the earlier tests. However, it's not great. I'm
> still looking into some better code, but it'll take a little time.
You might also try tweaking the tests... see if adding a <? ?> or not
changes things.
I think we can nail this, though. The code is quite clean, and clear.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Memory usage
Posted by Damon Courtney <da...@your.unreality.com>.
> After a few tests, Apache does not leak memory. I hammered it with
> 100k requests, and the processes stay slim at 1.4M of memory usage. So,
> we're not cleaning up something, or we're doing something wrong.
>
> Now, I'm sure most modules have this problem, but I think it's
> something we can strive to correct. It would be nice anyway. 0-]
>
> I ran Apache without loading Rivet, and no memory was leaked.
> I ran it with Rivet, and it leaked a few 100k here and there. Not sure
> if anything can be done about it other than recommend to people that
> they turn on their MaxRequestsPerChild option. 0-]
To answer my own e-mail. 0-]
Ok, so I've done some preliminary testing on memory usage / handling.
In my test, the httpd processes began their life around 3M each. After
hitting the server with 50k requests, the processes had increased to over
13M each. So, in the process of receiving 50k hits, they gained leaked
around 10M of memory each.
This is, of course, with the default Apache setting for
MaxRequestsPerChild set to 0, meaning the child process will continue to
run through the life of the server.
Now, with some very early memory cleanup code that I'm now working on,
the same test produced 'httpd' processes that went from 3M each to 7M each
after taking 50k hits. This is quite an improvement over the earlier
tests. However, it's not great. I'm still looking into some better code,
but it'll take a little time.
In the meantime, I think we're at least headed in a better direction.
0-]
D
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Memory usage
Posted by Damon Courtney <da...@your.unreality.com>.
Ok,
After a few tests, Apache does not leak memory. I hammered it with
100k requests, and the processes stay slim at 1.4M of memory usage. So,
we're not cleaning up something, or we're doing something wrong.
Now, I'm sure most modules have this problem, but I think it's
something we can strive to correct. It would be nice anyway. 0-]
I ran Apache without loading Rivet, and no memory was leaked.
I ran it with Rivet, and it leaked a few 100k here and there. Not sure
if anything can be done about it other than recommend to people that
they turn on their MaxRequestsPerChild option. 0-]
D
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: purge Apache ap_ from rivetCore.c
Posted by Damon Courtney <da...@your.unreality.com>.
Ok,
I'm wondering. Does Apache normally gain a lot of memory in the
child processes over time? 'Cause Rivet does. It's not a ton. I'm
hammering the server with like 10k hits at a time, and it doesn't
bloat the processes rapidly. They do bloat though. Now, on the machine
I'm running this on (dual P3 1G, 1G RAM), this doesn't really seem to
hinder the machine much. It could, however, have a real downside when
dealing with a smaller server.
Also. Apache 2.0 is rapidly approaching some final ticks. Do we
need to start looking at developing with mod_tcl? Do we need to start
developing mod_tcl itself more?
D
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: purge Apache ap_ from rivetCore.c
Posted by "David N. Welton" <da...@dedasys.com>.
davidw@dedasys.com (David N. Welton) writes:
> > Rivet_Parse:
> > Relies on a mod_rivet function which needs a 'dsc'. It needs
> > this so that it can do caching properly. Ugly situation...
> This is probably the most confusing. The other two we can offload
> to the TclWeb API.
I managed to tweak this around and make it work.
> > Rivet_Headers:
> > This stuff just needs to be added to the TclWeb API.
> The thing I wonder about here is how to write more of it in Tcl.
> Just use another command? In an OO language, I would subclass it
> and add more methods.
Maybe we just treat cookie as something to pass to headers set?
> > Rivet_Upload:
> > A mess...
> This one promises to be very ugly. I don't envy whoever sits down
> and hammers out the CGI version. Maybe for now I can see about
> offloading the various bits into TclWeb.
I can't for the life of me figure out an API I'm happy with:-( What a
bitch...
Anyway, some of the stuff like Rivet_UnescapeStringCmd could have its
guts offloaded into TclWebcgi.c, in order to make sure we are using
the Apache code when it's available.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: purge Apache ap_ from rivetCore.c
Posted by "David N. Welton" <da...@dedasys.com>.
davidw@dedasys.com (David N. Welton) writes:
> MakeURL:
> Relies on an apache function.
Offloaded to TclWeb API.
> Rivet_NoBody:
> Not sure how to implement this in a non-apache version. Maybe
> it won't cause problems.
Should be doable using TclWeb API.
> Rivet_AbortPageCmd:
> Not sure how to make this translate into the CGI version of
> the library.
Offloaded to TclWeb API. Maybe we can just make this be an alias for
'exit' in the CGI version.
So, these remain:
> Rivet_Parse:
> Relies on a mod_rivet function which needs a 'dsc'. It needs
> this so that it can do caching properly. Ugly situation...
This is probably the most confusing. The other two we can offload to
the TclWeb API.
> Rivet_Headers:
> This stuff just needs to be added to the TclWeb API.
The thing I wonder about here is how to write more of it in Tcl. Just
use another command? In an OO language, I would subclass it and add
more methods.
> Rivet_Upload:
> A mess...
This one promises to be very ugly. I don't envy whoever sits down and
hammers out the CGI version. Maybe for now I can see about offloading
the various bits into TclWeb.
--
David N. Welton
Consulting: http://www.dedasys.com/
Free Software: http://people.debian.org/~davidw/
Apache Tcl: http://tcl.apache.org/
Personal: http://www.efn.org/~davidw/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org