You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Stas Bekman <st...@stason.org> on 2000/12/05 14:54:48 UTC

RFC: mod_perl Guide 2.0

Since we have already started working on mod_perl-2.0, I wanted to get in
early and provide the base for the one and only source of mod_perl
documentation. These are the things that I see important:

1. *All* pods located under one roof. API, Installation, Configuration,
Tips, Trick and more. 

2. Automatic retrieval of pods sections from .pm files and integration in
the documentation tree.

3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are
already working in the guide, other formats to come).

4. Distribution within mod_perl or outside of it? (The main point of
having documentation separated as it may be updated more often than
software releases.) so this is arguable.

5. Commit rights. Should be available for all mod_perl committers, one or
more persons will be responsible for keeping the healthy layout of the
documentation, review documentation commits. Pretty much making it a
real community project and not Stas Bekman's project.

6. Mailing list (or reuse of cvs list) for corrections/contributions

7. The relevant parts from the current guide is to be merged into the new
guide and eventually freezed as mod_perl-2.0 will become the main product,
and mod_perl-1.x will be not supported anymore (I suppose a few years from
now).

Comments are welcome.

Once Doug gets back, given his approval we will start to layout the
documentation infrastructure in the cvs tree.

_____________________________________________________________________
Stas Bekman              JAm_pH     --   Just Another mod_perl Hacker
http://stason.org/       mod_perl Guide  http://perl.apache.org/guide 
mailto:stas@stason.org   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  




Performance with Apache::Resource

Posted by ma...@redestb.es.
Hi,

We have installed Apache::Resource working of course with BSD::Resource and 
this combination is running fine.

Now, we want to improve the performance of our server and would like to know 
the best values for Apache::Resource module, enabling of disabling some 
commands at our httpd.conf too.

Our server is running at a shared-dedicated server with a Pentium III 700 
Mhz and a quote of CPU of 8%. (This is a new server formula today. We have 
all features of a dedicated server but shared with 14 websites and with a 
specific CPU and Ram quote)

We have 64 Mb of Ram memory and a maximum swap file capacity of 192 Mb
running at Seagate Cheetah 10.000 rpm Ultra166 Scsi.

Software installed: Linux Red Hat 6.2, with Apache 1.3.9 (Unix), Mod_perl 1.24,
and Perl 5.005_03, suEXEC and Make 3.79 

Our values are:

At Apache::Resource

sub DEFAULT_RLIMIT_DATA  () { 64 } #data (memory) size in MB
sub DEFAULT_RLIMIT_AS    () { 64 } #address space (memory) size in MB
sub DEFAULT_RLIMIT_CPU   () { 60*6 } #cpu time in seconds
sub DEFAULT_RLIMIT_CORE  () { 0  } #core file size (MB)
sub DEFAULT_RLIMIT_RSS   () { 16 } #resident set size (MB)
sub DEFAULT_RLIMIT_FSIZE () { 10 } #file size  (MB)
sub DEFAULT_RLIMIT_STACK () { 20 } #stack size (MB)

PerlModule Apache::Resource

PerlSetEnv PERL_RLIMIT_DATA 32
PerlSetEnv PERL_RLIMIT_AS 32
PerlSetEnv PERL_RLIMIT_CPU 20

PerlChildInitHandler Apache::Resource

And a brief of our httpd.conf file:

- Timeout 300
- KeepAlive On
- MaxKeepAliveRequests 100
- KeepAliveTimeout 7
- MinSpareServers 5
- MaxSpareServers 10
- StartServers 10
- MaxClients 90
- MaxRequestsPerChild 5
- LoadModule perl_module        modules/libperl.so
- AddModule mod_perl.c

<IfModule mod_perl.c>
  Alias /perl/ /home/httpd/perl/
  <Location /perl>
    SetHandler perl-script
    PerlHandler Apache::Registry
    PerlSendHeader On
    Options +ExecCGI    
  </Location>
</IfModule>

- #PerlSetEnv PERL_RLIMIT_DEFAULTS On
(NOTE: We had to comment that out because it was causing a memory shortage in httpd.)
- PerlModule Apache::Resource
- PerlChildInitHandler Apache::Resource

Statistics:

We have disabled the access_log file to improve the performance because we 
have another tools to see our traffic. Anyway, maybe if we improve the values
at Apache::Resource and httpd.conf we can enable it again.

We have a traffic of 3,100 users daily with 10 minutes of staying (in average).

Number of CGIs used every day: 11,209. Transferred: 182 Mb (only CGIs)
Bandwidth: 1 GB daily.

We would like to received some advices to configure the maximum performance
with this class of server, because Apache::Resource has saved the life of our
site, and now, we would like to improve a little more its features.

Thank you very much in advance and thank you very much to Apache project,
a brilliance of freedom at Internet.

Miguel Angel Perez Garcia
3Dup.com - The Computer Graphics Portal


Re: RFC: mod_perl Guide 2.0

Posted by Jorge Godoy <go...@conectiva.com>.
On 05 Dec 2000, godoy@conectiva.com wrote:
> 
> I'll look after something to make pod or html into info and will
> send what I find to the list.

OK, I've done homework.


Module id = Pod::Texinfo
    DESCRIPTION  converter to texinfo
    CPAN_USERID  KJALB (Kenneth Albanowski <kj...@kjahds.com>)
    CPAN_VERSION undef
    CPAN_FILE    Contact Author Kenneth Albanowski <kj...@kjahds.com>
    DSLI_STATUS  cdpr (pre-alpha,developer,perl,references+ties)
    INST_FILE    (not installed)


We can also use Pod::DocBook to get DocBook SGML / XML and then
convert it to Texinfo files:

Module id = Pod::DocBook
    CPAN_USERID  ADESC (Alligator Descartes <de...@symbolstone.org>)
    CPAN_VERSION 0.05
    CPAN_FILE    A/AD/ADESC/Pod-DocBook-0.05.tar.gz
    INST_FILE    (not installed)



See you,
-- 
Godoy. <go...@conectiva.com>

Departamento de Publicações       Conectiva S.A.
Publishing Department             Conectiva Inc.

Re: RFC: mod_perl Guide 2.0

Posted by Jorge Godoy <go...@conectiva.com>.
On Tue, 5 Dec 2000, stas@stason.org wrote:
> On 5 Dec 2000, Jorge Godoy wrote:
> 
>> On Tue, 5 Dec 2000, matt@sergeant.org wrote:
>> 
>> >> 3. Automatic generating of html/ps/pdf/other
>> >> formats. (html/ps/pdf are already working in the guide, other
>> >> formats to come).
>> > 
>> > What other formats do you think people want/need?
>> 
>> info files would be cool. :-) 
> 
> is there pod or html 2info converter?

I don't know.

But I've tried looking after something and I found 'rman'. It can make
*roff code into: ASCII, roff, HTML, SGML (DocBook DTD -- it tries to),
LaTeX & LaTeX2e, RTF, Sections (just section titles), PostScript and
FrameMaker.

Re: RFC: mod_perl Guide 2.0

Posted by Stas Bekman <st...@stason.org>.
On 5 Dec 2000, Jorge Godoy wrote:

> On Tue, 5 Dec 2000, matt@sergeant.org wrote:
> 
> >> 3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf
> >> are already working in the guide, other formats to come).
> > 
> > What other formats do you think people want/need?
> 
> info files would be cool. :-) 

is there pod or html 2info converter?


_____________________________________________________________________
Stas Bekman              JAm_pH     --   Just Another mod_perl Hacker
http://stason.org/       mod_perl Guide  http://perl.apache.org/guide 
mailto:stas@stason.org   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  



Re: RFC: mod_perl Guide 2.0

Posted by Jorge Godoy <go...@conectiva.com>.
On Tue, 5 Dec 2000, matt@sergeant.org wrote:

>> 3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf
>> are already working in the guide, other formats to come).
> 
> What other formats do you think people want/need?

info files would be cool. :-) 



See you,
-- 
Godoy. <go...@conectiva.com>

Departamento de Publicações       Conectiva S.A.
Publishing Department             Conectiva Inc.

Re: RFC: mod_perl Guide 2.0

Posted by Stas Bekman <st...@stason.org>.
On Tue, 5 Dec 2000, Matt Sergeant wrote:

> On Tue, 5 Dec 2000, Stas Bekman wrote:
> 
> > Since we have already started working on mod_perl-2.0, I wanted to get in
> > early and provide the base for the one and only source of mod_perl
> > documentation. These are the things that I see important:
> >
> > 1. *All* pods located under one roof. API, Installation, Configuration,
> > Tips, Trick and more.
> 
> Is the guide the best place for tips and tricks? Its certainly the best
> place for hard-core installation configuration and other stuff, but often
> tips and tricks focus on one particular technology. Are we missing out on
> having a place to store smaller tips and tricks (you know where I'm
> thinking of keeping them...) ?

You can always reproduce them at will, I'm advocating the one and only
source. There is too much confusion with the way things are
now. Especially for newbies.

> > 2. Automatic retrieval of pods sections from .pm files and integration in
> > the documentation tree.
> 
> Is that really necessary? I assume you mean having the Apache.pm docs as
> part of the guide, and the mod_perl*.pod files also?

Absolutely, the current guide has lots of things duplicated with Apache.pm
docs and the mod_perl*.pod, because it tries to be complete (well the only
thing it doesn't attempt to cover is API). All we need is a well-thought
layout that will make the use and maintenance easy.

> > 3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are
> > already working in the guide, other formats to come).
> 
> What other formats do you think people want/need?

I don't know. Just trying to keep things open. As suggested in another
reply WAP formats (or the new ones replacing WAP)

> > 5. Commit rights. Should be available for all mod_perl committers, one or
> > more persons will be responsible for keeping the healthy layout of the
> > documentation, review documentation commits. Pretty much making it a
> > real community project and not Stas Bekman's project.
> 
> /me spies the ulterior motive behind that :-)

No motives, it's too good to be Stas Bekman :) Others should be able to
join, and contribute more, without having my shade over their head.

> > 6. Mailing list (or reuse of cvs list) for corrections/contributions
> 
> Is there anything wrong with using this list for that?

Yes, you don't see all the corrections that I receive in my personal
email. There are quite many of them at times. It'll create unneccesary
traffic for those who aren't interested in these corrections. Believe me I
know what I'm saying here :)

Another item that I've forgotten about, is someone who watches the list
(it was me until now and it's still me) and pickes new problems and their
solutions, new technological tips and tricks and other important stuff
that need to end up in the documentation and not only in the list
archives. Geoff is doing a great job providing the summaries, but someone
is to write down the real details.

> > 7. The relevant parts from the current guide is to be merged into the new
> > guide and eventually freezed as mod_perl-2.0 will become the main product,
> > and mod_perl-1.x will be not supported anymore (I suppose a few years from
> > now).
> 
> We probably need to keep two separate projects, going on what is known
> about mod_perl 2.0 so far.

Sure, as I said the 1.x will not die in the next few years. So once
mod_perl 2.0 goes live, /guide will point to the new guide and /guide-1.x
will have the old guide available.

_____________________________________________________________________
Stas Bekman              JAm_pH     --   Just Another mod_perl Hacker
http://stason.org/       mod_perl Guide  http://perl.apache.org/guide 
mailto:stas@stason.org   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  



Re: RFC: mod_perl Guide 2.0

Posted by Matt Sergeant <ma...@sergeant.org>.
On Tue, 5 Dec 2000, Stas Bekman wrote:

> Since we have already started working on mod_perl-2.0, I wanted to get in
> early and provide the base for the one and only source of mod_perl
> documentation. These are the things that I see important:
>
> 1. *All* pods located under one roof. API, Installation, Configuration,
> Tips, Trick and more.

Is the guide the best place for tips and tricks? Its certainly the best
place for hard-core installation configuration and other stuff, but often
tips and tricks focus on one particular technology. Are we missing out on
having a place to store smaller tips and tricks (you know where I'm
thinking of keeping them...) ?

> 2. Automatic retrieval of pods sections from .pm files and integration in
> the documentation tree.

Is that really necessary? I assume you mean having the Apache.pm docs as
part of the guide, and the mod_perl*.pod files also?

> 3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are
> already working in the guide, other formats to come).

What other formats do you think people want/need?

> 4. Distribution within mod_perl or outside of it? (The main point of
> having documentation separated as it may be updated more often than
> software releases.) so this is arguable.

Yes, keep it out of mod_perl. We all love doug but he's slower than a very
slow thing on a Sunday :-)

> 5. Commit rights. Should be available for all mod_perl committers, one or
> more persons will be responsible for keeping the healthy layout of the
> documentation, review documentation commits. Pretty much making it a
> real community project and not Stas Bekman's project.

/me spies the ulterior motive behind that :-)

> 6. Mailing list (or reuse of cvs list) for corrections/contributions

Is there anything wrong with using this list for that?

> 7. The relevant parts from the current guide is to be merged into the new
> guide and eventually freezed as mod_perl-2.0 will become the main product,
> and mod_perl-1.x will be not supported anymore (I suppose a few years from
> now).

We probably need to keep two separate projects, going on what is known
about mod_perl 2.0 so far.

-- 
<Matt/>

    /||    ** Director and CTO **
   //||    **  AxKit.com Ltd   **  ** XML Application Serving **
  // ||    ** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // **     Personal Web Site: http://sergeant.org/     **
     \\//
     //\\
    //  \\


Re: RFC: mod_perl Guide 2.0

Posted by Salve J Nilsen <sj...@pvv.org>.
Suddenly, Matt Sergeant uttered:
> On Tue, 5 Dec 2000, Salve J Nilsen wrote:
>
> > > 3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are
> > > already working in the guide, other formats to come).
> >
> > I'd _very_much_ like a PDA-version of the guide! It might have to be
> > set up differently (e.g. code snippets presented with fixed a width
> > font should go into seperate files, and deep nesting of lists should
> > be avoided (max. 2 levels?)). Lots of UI improvements could probably
> > be made... :)
> >
> > The guide as it is, isn't much readable on my iPaq, at least. :(
>
> What's the format the iPaq can read? Isn't it an XML format?

HTML. There are two ways (AFAIK) to get web pages onto the iPaq: the
first is to use the "Mobile Favourites" feature in IE (Windows
PocketPC comes with a tiny version of IE), and the other way is by
using AvantGo, which might be looked upon as an IE application for
syncronizing web pages.

So actually, the format is HTML (dunno which versions Pocket IE can
handle, though. Maybe XHTML1.0 works? :)

I'd love to find out what might work, but it'll have to wait until
this weekend :)


- Salve

-- 
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.#     <sj...@foo.no>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)


Re: RFC: mod_perl Guide 2.0

Posted by Matt Sergeant <ma...@sergeant.org>.
On Tue, 5 Dec 2000, Salve J Nilsen wrote:

> > 3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are
> > already working in the guide, other formats to come).
>
> I'd _very_much_ like a PDA-version of the guide! It might have to be
> set up differently (e.g. code snippets presented with fixed a width
> font should go into seperate files, and deep nesting of lists should
> be avoided (max. 2 levels?)). Lots of UI improvements could probably
> be made... :)
>
> The guide as it is, isn't much readable on my iPaq, at least. :(

What's the format the iPaq can read? Isn't it an XML format?

-- 
<Matt/>

    /||    ** Director and CTO **
   //||    **  AxKit.com Ltd   **  ** XML Application Serving **
  // ||    ** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // **     Personal Web Site: http://sergeant.org/     **
     \\//
     //\\
    //  \\


Re: RFC: mod_perl Guide 2.0

Posted by Salve J Nilsen <sj...@pvv.org>.
Suddenly, Stas Bekman uttered:
>
> Since we have already started working on mod_perl-2.0, I wanted to get in
> early and provide the base for the one and only source of mod_perl
> documentation. These are the things that I see important:

> 2. Automatic retrieval of pods sections from .pm files and integration in
> the documentation tree.

That would be nice! :)

> 3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are
> already working in the guide, other formats to come).

I'd _very_much_ like a PDA-version of the guide! It might have to be
set up differently (e.g. code snippets presented with fixed a width
font should go into seperate files, and deep nesting of lists should
be avoided (max. 2 levels?)). Lots of UI improvements could probably
be made... :)

The guide as it is, isn't much readable on my iPaq, at least. :(

> 4. Distribution within mod_perl or outside of it? (The main point of
> having documentation separated as it may be updated more often than
> software releases.) so this is arguable.

Outside, and perhaps set mod_perl to require the documentation to be
installed? (which might make installation via CPAN.pm a little easier
:)

> 6. Mailing list (or reuse of cvs list) for corrections/contributions

Don't we have enough mailing lists? :)



- Salve

-- 
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.#     <sj...@foo.no>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)