pool of DB connections ?
Hi, I'm using mod_perl, DBI, ApacheDBI and was quite happy with persistent connections httpd-postgres until I used just one database. Currently I have 20 apache servers which handle 20 connections to database. If I want to work with another database I have to create another 20 connections with DB. Postgres is not multithreading DB, so I will have 40 postgres backends. This is too much. Any experience ? Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Re: HTTP 1.0 / 1.1
This has tripped me up in the past as well. While the preponderance of browsers support HTTP/1.1 features, they use the lowest common denominator language, HTTP/1.0, to make requests. Language extensions are permitted but it's all for the best that these user agents don't report themselves as HTTP/1.1 compliant unless they really are. The request format object %r in mod_log_config is a wysiwyg item -- it's the actual request. I don't know of a way to log downgradings off hand; they're instructions handed around the request obect as note, IIRC, so you could write a mod_perl module to log those. Other than that, this isn't a mod_perl topic, so take it to comp.infosystems.www.servers.unix going forward. -Ian Today, Jeffrey Baker [EMAIL PROTECTED] frothed and gesticulated about Re: HTTP...: Pouneh Mortazavi wrote: OK. so this is unrelated to the modperl mailing list. but its an interesting question. If you know anywhere else I could post this, please tell me. I'm trying to find out how many clients support HTTP 1.1 features such as keepalives and domain-name based virtual hosts. Apparently netscape 3+,ie4+ all run HTTP 1.1. Which is good. This is 95% of my user agents. When I look through the logs however, I see a *huge* amount of HTTP 1.0 requests from what are claimed to be http 1.1 compliant browsers. I get 3 times more HTTP1.0 requests than HTTP1.1 requests. I can understand that some of these user agent strings may be rogue spiders/browsers masquarading as netscape/ie ... but not that many! Can anyone explain, why this would be the case? I know that my apache servers can implement HTTP protocol negotiation, but I definately do not do that in my conf files... Has anyone else done any analysis on their webserver logs for http protocols? I'm not terribly familiar with the Apache log format. Are you sure that the log records the protocol level in the request, or the protocol level of the response? The standard Apache config files include a rule to downgrade certain user agents to HTTP 1.0. Is this rule in your config file? Might an intervening proxy downgrade the request to 1.0? Regards, Jeffrey -- Salon Internet http://www.salon.com/ HTTP mechanic, Perl diver, Mebwaster, Some of the above Ian Kallen [EMAIL PROTECTED] / AIM: iankallen / Fax: (415) 354-3326
PerlLogHandler - bytes always zero for proxy requests
Hi, I've checked the archive and not found anything relevant, and I've looked through the mod_perl docs, but it's all aimed at people who want to write their own modules. I'm using: Apache 1.3.9, mod_perl 1.21, Apache::DBILogger-0.93, Apache::DBILogConfig-0.01, MySQL 3.22.27 I wonder if some kind soul could point me in the right direction? Apache access_log correctly shows the 'bytes' sent to the client (the %b in the LogFormat directive), but when using either DBILogger or DBILogConfig (the former one being better than the latter IMHO), the bytes value is zero for all proxy requests, and only set to a valid value for accesses to the server itself, although all the other values seem to be correctly set for both proxy and local requests. Can anyone tell me how to turn on logging of the bytes through the proxy please? Many thanks, Brian S. Craigie Unix Sysadmin
Re: HTTP 1.0 / 1.1
When a browser claims that it supports HTTP/1.1 it doesn't mean that it uses it for each request. I believe that in general case browser always uses HTTP/1.0 which is logged in apache log. I'm not sure how to make the same browser to use HTTP/1.1 as default protocol. I guess you shouldn't because not all webservers support it yet :) Still I think that if Apache returns HTTP/1.1 as protocol then browser will correctly handle it (multi-part transactions etc.) Andrei On Mon, Nov 29, 1999 at 08:20:19AM -0800, Jeffrey Baker wrote: Pouneh Mortazavi wrote: OK. so this is unrelated to the modperl mailing list. but its an interesting question. If you know anywhere else I could post this, please tell me. I'm trying to find out how many clients support HTTP 1.1 features such as keepalives and domain-name based virtual hosts. Apparently netscape 3+,ie4+ all run HTTP 1.1. Which is good. This is 95% of my user agents. When I look through the logs however, I see a *huge* amount of HTTP 1.0 requests from what are claimed to be http 1.1 compliant browsers. I get 3 times more HTTP1.0 requests than HTTP1.1 requests. I can understand that some of these user agent strings may be rogue spiders/browsers masquarading as netscape/ie ... but not that many! Can anyone explain, why this would be the case? I know that my apache servers can implement HTTP protocol negotiation, but I definately do not do that in my conf files... Has anyone else done any analysis on their webserver logs for http protocols? I'm not terribly familiar with the Apache log format. Are you sure that the log records the protocol level in the request, or the protocol level of the response? The standard Apache config files include a rule to downgrade certain user agents to HTTP 1.0. Is this rule in your config file? Might an intervening proxy downgrade the request to 1.0? Regards, Jeffrey -- Jeffrey W. Baker * [EMAIL PROTECTED] Critical Path, Inc. * we handle the world's email * www.cp.net 415.808.8807 --
fragment in $r-uri
im requesting the url http://www.maz.org/foo/index.html#perl it appears that neither $r-uri nor $r-parsed_uri retain any knowledge of the fragment. they both return /foo/index.html is there any way for me to retrieve the fragment info short of parsing $r-the_request?
Re: Apache::Sandwich - how can I put the right page title
"JB" == Jeffrey Baker [EMAIL PROTECTED] writes: JB Vivek Khera wrote: "SM" == Shay Mandel [EMAIL PROTECTED] writes: SM p.s. - the header file I'm getting is the same for all the pages, thus SM it does not resides in the same directory as the page itself. Conveniently, Netscape recognizes the TITLE html tag anywhere in the document, not just in the HEAD section. I didn't test if it worked for other browsers, though. JB That would not amount to valid HTML. According to the HTML 4.0 JB recommendation, "Every HTML document must have a TITLE element in the JB HEAD section." True, which is another reason I don't use this "trick".
Re: fragment in $r-uri
"brian" == brian moseley [EMAIL PROTECTED] writes: brian im requesting the url brian http://www.maz.org/foo/index.html#perl brian it appears that neither $r-uri nor $r-parsed_uri retain brian any knowledge of the fragment. they both return brian /foo/index.html brian is there any way for me to retrieve the fragment info short brian of parsing $r-the_request? The server never sees the "fragment", and rightfully so. That's for the client only, to scroll down to by looking for a name=perl once the page has been downloaded. The server never knows that happened. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: fragment in $r-uri
I've had the same problem. There's a mistake in the Eagle book when it
states that $r-the_request() eq join(' ', $r-method, $r-uri,
$r-protocol).
Proper way to access fragment as well as query_string is to use
my $uri = $r-parsed_uri();
my $fragment = $uri-fragment();
Andrei
On Mon, Nov 29, 1999 at 10:04:24AM -0800, brian moseley wrote:
im requesting the url
http://www.maz.org/foo/index.html#perl
it appears that neither $r-uri nor $r-parsed_uri retain
any knowledge of the fragment. they both return
/foo/index.html
is there any way for me to retrieve the fragment info short
of parsing $r-the_request?
--
Re: fragment in $r-uri
Correct too. Though Apache::URI::fragment() is present and even documented :) Probably because some browsers pass this fragment to the server? Andrei On Mon, Nov 29, 1999 at 10:16:04AM -0800, Randal L. Schwartz wrote: "brian" == brian moseley [EMAIL PROTECTED] writes: brian im requesting the url brian http://www.maz.org/foo/index.html#perl brian it appears that neither $r-uri nor $r-parsed_uri retain brian any knowledge of the fragment. they both return brian /foo/index.html brian is there any way for me to retrieve the fragment info short brian of parsing $r-the_request? The server never sees the "fragment", and rightfully so. That's for the client only, to scroll down to by looking for a name=perl once the page has been downloaded. The server never knows that happened. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! --
Re: fragment in $r-uri
"Andrei" == Andrei A Voropaev [EMAIL PROTECTED] writes: Andrei Correct too. Though Apache::URI::fragment() is present and Andrei even documented :) Probably because some browsers pass this Andrei fragment to the server? No, because a server could pass *back* a URI with a fragment in generated stuff. It just shouldn't ever show up on a *request*. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
EmbPerl 1.20 hash/href problem?
The following testcast fails under 1.20. Basically, if there is a hash
deref inside an HREF tag, without quotes, you get the following error:
[27723]ERR: 13: Line 4: Missing right +]
If you quote the HREF or create a temporary variable to hold the hash deref
everything works fine.
What follows is the testcase cgi script and the associated template file.
#!/usr/local/bin/perl -T
use strict;
use HTML::Embperl ();
use CGI ();
use vars qw( $cgi $EMBPERL_OPTIONS );
$EMBPERL_OPTIONS= HTML::Embperl::optRawInput;
$cgi= new CGI;
print $cgi-header();
HTML::Embperl::Execute(
{
inputfile = "testcase.html",
options = $EMBPERL_OPTIONS,
}
);
exit;
And here is the template file:
[- $topic-{TOPICID} = "hello" -]
htmlbody
[# uncomment the next statement and change the hash deref in the HREF to
"$tmp"
to see things work with the variable version
Note that the testcase still fails even if you do not pre-set
$topic-{TOPICID} and its contents appear irrelevant.
#]
[# $tmp = $topic-{TOPICID} #]
A HREF=[+ $topic-{TOPICID} +]Link/A
/body/html
--
James Sheridan-Peters
Sr. Application Developer
Community of Science
(410) 563-2378 x297
[EMAIL PROTECTED]
Embperl and header output
I've sent this to this list already once before so I apologize for resubmitting
this problem.
This application works fine so long as there are no errors. If there are validation
errors what is suppose to happen is the errors are to be displayed at the top of the
HTML doc followed by the form allowing the user to correct any input errors.
The problem is that the errors are being displayed, then the HTTP header is being
sent,
then the actual HTML doc is being sent. Additionally, the status bar reads
"Reading file..." for approximately 10 seconds before finally indicating "Document:
Done".
An example of the output generated follows:
font color="red"strongfont size="+1"uERROR(S):/u/fontbr
Application submission failed: Student record exists already
/strong/font
HTTP/1.1 200 OK
Date: Mon, 29 Nov 1999 19:58:28 GMT
Server: Apache/1.3.6 (Unix) mod_perl/1.21
Content-Length: 4567
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html
HTML
HEADTITLEUntitled Document/TITLE/HEAD
BODYrest of doc/BODY/HTML
I've also attached a skeleton copy of the code below.
TIA
Erich
[-
use Apache;
use Apache::Constants qw(REDIRECT);
error checking and form validation going on here...
$new_applicant and $errors are set appropriately here...
-]
HTML
HEADTITLEUntitled Document/TITLE
/HEAD
BODY BGCOLOR="white" TEXTCOLOR="black"
[$ if( ( $new_applicant ) || ( $errors ) ) $]
[+ $application-display_errors_as_html() if( ($errors) || ($application-errors()) );
+]
[+ $student-display_errors_as_html() if( $student-errors()); +]
FORM METHOD="post" ACTION="[+ qq!http://$ENV{SERVER_NAME}/Nactel/new-application.epl!
+]" ENCTYPE="application/x-www-form-urlencoded"
/FORM
[$ else $]
[-
use Apache;
use Apache::Constants qw(REDIRECT);
$req_rec-header_out("Location" =
qq!http://$ENV{SERVER_NAME}/Nactel/common/contact-info.epl?application_id=$fdat{'application_id'}form_name=$fdat{'form_name'}!);
$req_rec-status(REDIRECT);
-]
[$ endif $]
/BODY
/HTML
Re: fragment in $r-uri
On Mon, 29 Nov 1999, Robin Berjon wrote: I'm unsure that even parsing the request will get you that. A grep through my logs shows no trace of the fragment ever being present, while a lot of pages containing some appear. It wouldn't surprise me totally if the browser kept the fragment to itself and requested only the document. you're right. i glanced over the output of $r-the_request and saw what i wanted to see, not what was actually there. thanks for all the responses.
Re: pool of DB connections ?
According to Oleg Bartunov: Currently I have 20 apache servers which handle 20 connections to database. If I want to work with another database I have to create another 20 connections with DB, so I will have 40 postgres backends. This is too much. I didn't write all details but of course I already have 2 servers setup. Are you sure you need 20 concurrent backend servers? If you have enabled apache's 'server-status' reporting you can watch the backend during some busy times to see how many are doing anything. It is probably to have too few servers (the front end will wait as long as the requests don't overflow the listen queue) than so many that the machine starts paging virtual memory to disk. Les Mikesell [EMAIL PROTECTED]
Re: pool of DB connections ?
On Mon, 29 Nov 1999, Oleg Bartunov wrote: Hi, I'm using mod_perl, DBI, ApacheDBI and was quite happy with persistent connections httpd-postgres until I used just one database. Currently I have 20 apache servers which handle 20 connections to database. If I want to work with another database I have to create another 20 connections with DB. Postgres is not multithreading DB, so I will have 40 postgres backends. This is too much. Any experience ? Does postgresql not have an equivalent to Sybase's "use database" command? That would in effect be an adequate substitute if it did. Or even can you reference tables explicitly: select * from db.table -- Matt/ Details: FastNet Software Ltd - XML, Perl, Databases. Tagline: High Performance Web Solutions Web Sites: http://come.to/fastnet http://sergeant.org Available for Consultancy, Contracts and Training.
Re: EmbPerl 1.20 hash/href problem?
I know this problem. As you write above, writing
A HREF="[+ $topic-{TOPICID} +]"Link/A
will solve the problem. Because parser tries to find the end of the HREF
arg
and if not quoted the end is after the first space or when he finds a .
Because the quoting doesn't hurt (as far as I see) I haven't changed this
until now, to make the parser not to compilcated and therfor not to slow.
Gerald
Is this, or will this be, documented somewhere? Seeing as it is a kludge,
even if it does help performance somewhat, is this going to be fixed in the
future or is this Working As Designed? Any chance of having the "end of
tag" logic changed to ignore characters inside the EmbPerl braces ( [+ ...
+] ) since this is the most likely place to cause problems?
Thanks.
--
James Sheridan-Peters
Sr. Application Developer
Community of Science
(410) 563-2378 x297
[EMAIL PROTECTED]
RE: Embperl and header output
I've sent this to this list already once before so I apologize for resubmitting this problem. And here is what I have answered you, looks like you didn't get that (at least you didn't replied that it isn't working): Note: The display_errors_as_html method doesn't send out any headers of it's own. But I guess it prints to stdout. You should set optRedirectStdout (in your server config), to let stdout go to the Embperl output stream. Otherwise it's send directly and arrives at the browser, before Embperl sends it's header. That's what you currently see Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
RE: EmbPerl 1.20 hash/href problem?
The following testcast fails under 1.20. Basically, if there is a hash
deref inside an HREF tag, without quotes, you get the following error:
[27723]ERR: 13: Line 4: Missing right +]
If you quote the HREF or create a temporary variable to hold the
hash deref
everything works fine.
[..]
A HREF=[+ $topic-{TOPICID} +]Link/A
I know this problem. As you write above, writing
A HREF="[+ $topic-{TOPICID} +]"Link/A
will solve the problem. Because parser tries to find the end of the HREF arg
and if not quoted the end is after the first space or when he finds a .
Because the quoting doesn't hurt (as far as I see) I haven't changed this
until now, to make the parser not to compilcated and therfor not to slow.
Gerald
-
Gerald Richterecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151
WWW:http://www.ecos.de Fax: +49 6133 925152
-
Re: Limitations of DBI::ProxyServer (was: pool of DB connections?)
On Mon, 29 Nov 1999, Tim Bunce wrote: Ignoring 'thread' (unsafe for production use) and 'debug' modes, the normal 'fork' mode means that each client gets a seperate ProxyServer process. And because of that, clients have no way to share connections with each other. Is that necessarily the case? Perhaps the parent server could handle the connection-pooling and hand off live connection to the forked child. That way you could get the best of both worlds - de-coupled clients and a shared pool of database connections. It seems to me that moving to a single-process architecture has some BIG downsides when you consider the wide variation in database query runtimes. -sam
Re: Limitations of DBI::ProxyServer (was: pool of DB connections?)
On Mon, Nov 29, 1999 at 07:46:50PM -0500, Sam Tregar wrote: On Mon, 29 Nov 1999, Tim Bunce wrote: Ignoring 'thread' (unsafe for production use) and 'debug' modes, the normal 'fork' mode means that each client gets a seperate ProxyServer process. And because of that, clients have no way to share connections with each other. Is that necessarily the case? Perhaps the parent server could handle the connection-pooling and hand off live connection to the forked child. That way you could get the best of both worlds - de-coupled clients and a shared pool of database connections. It seems to me that moving to a single-process architecture has some BIG downsides when you consider the wide variation in database query runtimes. You're quite right, but both cases need to be allowed for as some database (notably Oracle) get upset if a child process tries to use a connection established by the parent process. But mixing a connection pool with fork mode ought work for some of the DBI drivers. Thanks for pointing that out. Does that mean you're volunteering? :-) Tim.
Re: pool of DB connections ?
[watch the followups... this is going to both the modperl and the DBI list...] "Ed" == Ed Park [EMAIL PROTECTED] writes: Ed each creates a network connection to DBI::ProxyServer, which Ed creates a few persistent connections to the db server using the Ed connect_cached method. I hadn't noticed that until now. Except I also noticed this... Note that the behaviour of this method differs in several respects from the behaviour of the presistent connections implemented by Apache::DBI. Which scares me, but then doesn't go on to explain *what* those "several respects" are. While I didn't pay anything for the documentation *or* DBI, so I should be grateful, this is the kind of sentence that any editor looking over *my* stuff would flag with a big "?". :) Never leave the reader with a sense of puzzlement -- either don't say anything, finish the thought, or tell them where to read more. So, Tim, what *are* the differences, and when should we should we choose Apache::DBI vs DBI-connect_cached, and why? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
RE: pool of DB connections ?
So, Tim, what *are* the differences, and when should we should we choose Apache::DBI vs DBI-connect_cached, and why? I think one of the big differences is that Apache::DBI overrides the disconnect method, to prevent accidentally calling disconnect from a mod_perl script. When using connect_cached you have to watch out for this yourself. Also, I had to switch from using Apache::DBI to connect_cached in my Apache::Registry script because of another subtle difference... (from Apache::DBI) # The PerlCleanupHandler is supposed to initiate a rollback after the script has finished if AutoCommit is off. # Note: the PerlCleanupHandler runs after the response has been sent to the client My registry script was using AutoCommit=0 and trying to commit via an END block, but Apache::DBI was rolling back before the END block was executed. Took a while to track this down. Chris - Chris Nokleberg + Internet Sports Network, Inc. [EMAIL PROTECTED] + http://www.SportsRocket.com/
Limitations of DBI::ProxyServer (was: pool of DB connections?)
On Mon, Nov 29, 1999 at 01:19:53PM -0800, Randal L. Schwartz wrote:
[watch the followups... this is going to both the modperl
and the DBI list...]
"Ed" == Ed Park [EMAIL PROTECTED] writes:
Ed each creates a network connection to DBI::ProxyServer, which
Ed creates a few persistent connections to the db server using the
Ed connect_cached method.
I hadn't noticed that until now. Except I also noticed this...
Note that the behaviour of this method differs in
several respects from the behaviour of the presistent
connections implemented by Apache::DBI.
Which scares me, but then doesn't go on to explain *what* those
"several respects" are. While I didn't pay anything for the
documentation *or* DBI, so I should be grateful, this is the kind of
sentence that any editor looking over *my* stuff would flag with a big
"?". :) Never leave the reader with a sense of puzzlement -- either
don't say anything, finish the thought, or tell them where to read
more.
So, Tim, what *are* the differences, and when should we should we
choose Apache::DBI vs DBI-connect_cached, and why?
The docs don't go into detail because, as they say:
The exact behaviour of this method Iis liable to change.
If you intend to use it in any production applications your
should discuss your needs in the dbi-users mailing list.
connect_cached is targeted, in part, for use with DBI::ProxyServer
to implement connection pooling. But, and it's a big but, the
current implementation of DBI::ProxyServer, as far as I know,
doesn't work in a way that would allow connect_cached to be useful.
Ignoring 'thread' (unsafe for production use) and 'debug' modes, the
normal 'fork' mode means that each client gets a seperate ProxyServer
process. And because of that, clients have no way to share connections
with each other.
I'd like to see a mode added to DBI::ProxyServer whereby a single
server process serviced multiple clients in a round-robin manner.
Obviously in this mode there's a risk of slow queries cloging up
(blocking) the proxy, but for many applications it would still be
very useful. Most significantly it would enable connect_cached to
be used to implement a (kind-of) connection pool.
Sadly I don't have the time to work on that. I'm not sure if Jochen
Wiedmann (the author of DBI::ProxyServer, DBD::Proxy and the RPC::*
modules they sit on) either has the time or is interested in doing the
work. On the other hand, given how useful this functionality would be,
I'm sure there must be someone out there willing to have a go at
implementing it. It can't be that hard. [Volunteers welcome but please
coordinate with Jochen and myself.]
Coming back to your original question, connect_cached is currently
a very simple cache:
sub connect_cached {
my $drh = shift;
my ($dsn, $user, $auth, $attr)= @_;
my $cache = $drh-FETCH('CachedKids');
$drh-STORE('CachedKids', $cache = {}) unless $cache;
my $key = join "~", $dsn, $user||'', $auth||'', $attr ? %$attr : ();
my $dbh = $cache-{$key};
return $dbh if $dbh $dbh-FETCH('Active') $dbh-ping;
$dbh = $drh-connect(@_);
$cache-{$key} = $dbh; # replace, even if it failed
return $dbh;
}
Apache::DBI's connect method is slightly more involved. It has some
Apache specifics and also reblessing the handle into a different class
in order to disable the disconnect method.
One final point, I think that connect_cached would need to be modified
slightly before it would be used as a true 'connection pool'. Right now
it'll happily give you the same live database handle that some other
part of the system may still be using. That may be, er, bad. You can
get around that by adding dummy attributes to force whatever level of
uniqueness is desired, but that's the kind of open issue that meant
connect_cached was left with a warning sign and a plea for input.
I hope that helps.
Tim.
Re: Limitations of DBI::ProxyServer (was: pool of DB connections?)
On Tue, 30 Nov 1999, Tim Bunce wrote: You're quite right, but both cases need to be allowed for as some database (notably Oracle) get upset if a child process tries to use a connection established by the parent process. Interesting. So Oracle snoops on the PID of the process calling it? How rude! Or does it have some other mechanism I'm not aware of? But mixing a connection pool with fork mode ought work for some of the DBI drivers. Thanks for pointing that out. Does that mean you're volunteering? :-) I'm willing to take a look at it... I've never played with DBD::Proxy*, although I've meant to. Let me take a look and then I'll tell you if it's something I think I could accomplish. -sam
RE: pool of DB connections ?
Have you looked at "Perl Cookbook"? It has nice discussion on prefork server. you can customize it according to your requirement. e.g. You can control exactly how many DB connection you want(background processes which keep persistance connection to database). You can move this to another server if you want or use as Unix Domain (as it's very fast compare to TCP/IP socket). Niraj -Original Message- From: Leslie Mikesell [mailto:[EMAIL PROTECTED]] Sent: Monday, November 29, 1999 11:00 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: pool of DB connections ? According to Oleg Bartunov: I'm using mod_perl, DBI, ApacheDBI and was quite happy with persistent connections httpd-postgres until I used just one database. Currently I have 20 apache servers which handle 20 connections to database. If I want to work with another database I have to create another 20 connections with DB. Postgres is not multithreading DB, so I will have 40 postgres backends. This is too much. Any experience ? Try the common trick of using a lightweight non-mod_perl apache as a front end, proxying the program requests to a mod_perl backend on another port. If your programs live under directory boundaries you can use ProxyPass directives. If they don't you can use RewriteRules with the [p] flag to selectively proxy (or [L] to not proxy). This will probably allow you to cut the mod_perl httpd's at least in half. If you still have a problem you could run two back end httpds on different ports with the front end proxying the requests that need each database to separate backends. Or you can throw hardware at the problem and move the database to a separate machine with enough memory to handle the connections. Les Mikesell [EMAIL PROTECTED]
Eagle Book - mod_hello.c, hello.pl :)
Greetings list,
Installed fresh downloads of
Apache 1.3.9 and mod_perl 1.21
But using the Perl 5.005003 that was installed with the
SuSE 6.2
mod_hello.c
when 'make', get:
:50:'hello_handlers' undeclared here (not in a function)
:50:initializer element for 'hello_module.handlers is not constant in
http_config.h
When looking at http_config.h at the handler_rec structure, the elements
don't seem to match the way they're used in the example in the book.
Going to the book site, the src's for the examples are NOT available.
*shrug*
--
hello.pl
I've come close to figuring this one out buy following some of the
questions I've seen here. But...
H1Hello $ENV{REMOTE_HOST}/H1
The remote host doesn't show. Printing out the %ENV, it tain't there.
But where does Perl get it. From CGI.pm (which is installed) or where?
Thanks,
Michael Dearman
"I'd give my right arm to be ambidextrous." -- Yogi Berra
Re: Eagle Book - mod_hello.c, hello.pl :)
Michael Dearman [EMAIL PROTECTED] wrote:
I've come close to figuring this one out buy following some of the
questions I've seen here. But...
H1Hello $ENV{REMOTE_HOST}/H1
The remote host doesn't show. Printing out the %ENV, it tain't there.
But where does Perl get it. From CGI.pm (which is installed) or where?
%ENV is the environment. CGI uses the environment to pass values from
the web server to the CGI program. If your script was running under
CGI, the web server would put REMOTE_HOST, and other things, in the
environment, before forking to run your script. But you're not using
CGI, you're using mod_perl. The server isn't setting CGI environment
variables and forking to run your script. Your script is being run by
a code module that is part of the web server. You need to use Apache
specific calls to get the information you need from the web server.
mod_perl makes this easy to do using the "Apache request object":
$request = Apache-request;
$connection = $request-connection;
$remote_ip = $connection-remote_ip;
Read more about the request object in the mod_perl documentation, to
find out how to ask it for the other kinds of information a CGI script
normally gets out of the environment. Remember, mod_perl is not CGI
(although with Apache::Registry it can look quite similar to CGI)
-- Cos (Ofer Inbar) -- [EMAIL PROTECTED] [EMAIL PROTECTED]
-- Exodus Professional Services -- [EMAIL PROTECTED]
"This may seem a bit weird, but that's okay, because it is weird."
-- Larry Wall in perlref(1) man page, Perl 5.001
Re: Eagle Book - mod_hello.c, hello.pl :)
Ofer Inbar wrote:
Michael Dearman [EMAIL PROTECTED] wrote:
I've come close to figuring this one out buy following some of the
questions I've seen here. But...
H1Hello $ENV{REMOTE_HOST}/H1
-schnip-
normally gets out of the environment. Remember, mod_perl is not CGI
(although with Apache::Registry it can look quite similar to CGI)
-- Cos (Ofer Inbar) -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Thanks Ofer,
And along with the guides advice that the use of ENV is clunky anyway,
I'll
proceed with using the objects. It's just disconcerting when you can't
get
and example from a book to work. Just didn't know if it was something I
didn't
have set up right. But now methinks it might be the example was leading
me astray.
Sure wish the book site had those file listings and any corrections.
*hint-hint*
Thanks again,
Michael Dearman
