On Thu, Nov 13, 2014 at 5:38 PM, Xinhuan Zheng
wrote:
> We have load balancer cache that can cache images and JavaScripts. This
> functions seems a bit duplicate.
It's not about caching. Here's a quote from that link I sent earlier:
"Another drawback of this approach is that when serving outpu
On Thu, Nov 13, 2014 at 5:29 PM, Vincent Veyron wrote:
> I stash a reference to a DBI handle in pnotes during the HeaderParser
> phase of my requests; I then refer to this handle for every request in my
> PerlResponseHandlers.
>
> This seems to have been working fine for several months. Am I doin
Hi Parrin,
> While it is possible to do some caching in a proxy like this, the more
> important thing it does is buffering the content, and possibly serving static
> requests for JavaScript and images. That frees up the mod_perl processes to
> move on to another request.
I am questioning the v
On Thu, 13 Nov 2014 16:35:59 -0500
Perrin Harkins wrote:
>
> Keep in mind, neither of these work unless you call
> DBI->connect()/connect_cached() at the beginning of every request. You
> can't just keep a DBI handle stashed somewhere and expect that to work.
>
h... you're having me worrie
On Thu, Nov 13, 2014 at 2:41 PM, Xinhuan Zheng
wrote:
> From the description of the document, the “proxy” server acts much like a
> memcache but it appears the difference is the “proxy” understands the HTTP
> protocol while memcache does not.
Not exactly. While it is possible to do some caching
On Thu, Nov 13, 2014 at 2:48 PM, Vincent Veyron wrote:
> But then, what is the point of using connect_cached?
You can use it outside of mod_perl. You can also use instead of Apache::DBI
if you don't want the connection to be more explicit (instead of magically
overriding the connect() call).
K
On Thu, 13 Nov 2014 12:45:09 -0500
Perrin Harkins wrote:
> Well, Apache::DBI should already be doing a ping and a successful
> re-connect if needed.
Haha, thanks for your answer. I have so much to learn...
But then, what is the point of using connect_cached?
--
Hi Perrin,
Thanks for pointing out the document. We are using mod_perl enabled apache
server for dynamic content. From the description of the document, the “proxy”
server acts much like a memcache but it appears the difference is the “proxy”
understands the HTTP protocol while memcache does not
Yes, it has nothing to do with the version of mod_perl. It's a general
technique for any HTTP application server.
- Perrin
On Thu, Nov 13, 2014 at 2:33 PM, John Dunlap wrote:
> That link is from the mod_perl 1.x documentation. Is this information
> still valid in mod_perl 2.x?
>
> On Thu, Nov 1
That link is from the mod_perl 1.x documentation. Is this information still
valid in mod_perl 2.x?
On Thu, Nov 13, 2014 at 2:23 PM, Perrin Harkins wrote:
> Yes, it's an HTTP proxy. It handles sending out the bytes to remote
> clients, so that your mod_perl server doesn't have to. A popular
> hig
Yes, it's an HTTP proxy. It handles sending out the bytes to remote
clients, so that your mod_perl server doesn't have to. A popular
high-performance choice these days is nginx.
There's some discussion of why to use a front-end proxy here:
http://perl.apache.org/docs/1.0/guide/strategy.html
- Per
Hi Perrin,
I don’t quite understand what you mean by setting up a front-end proxy. What
would you expect this “proxy” do? Does it take HTTP request?
Thanks,
- xinhuan
From: Perrin Harkins mailto:phark...@gmail.com>>
Date: Thursday, November 13, 2014 at 12:50 PM
To: Xinhuan Zheng mailto:xzh...@c
On Thu, Nov 13, 2014 at 12:19 PM, Xinhuan Zheng
wrote:
> Having another tier (like DBD::Gofer) looks like really messy in
> infrastructure plus it’s not certain who is going to maintain that module’s
> quality.
I'd only recommend trying it after you set up a front-end proxy, tune your
mod_perl
On Thu, Nov 13, 2014 at 12:21 PM, Vincent Veyron
wrote:
> Nobody suggested using connect_cached, where the documentations says :
>
> The cached database handle is replaced with a new
>connection if it has been disconnected or if the "ping" method fails
>
> Would that not solve OP's proble
On Thu, 13 Nov 2014 10:43:35 -0500
Perrin Harkins wrote:
> Apache::DBI should also re-connect with no problems if a request comes in
> after a connection has timed out. If that isn't happening, make sure you
> are using Apache::DBI properly.
>
Hi Perrin,
Nobody suggested using connect_cached,
I guess we do need connection caching and have persistent connections. It is
good in our situation. But I would feel oracle 11g connection pooling might be
more appropriate option to handle idle connection time out issue. Having
another tier (like DBD::Gofer) looks like really messy in infrastru
On Thu, Nov 13, 2014 at 11:29 AM, Dr James Smith wrote:
> From experience - and having chatted with our DBAs at work, with modern
> Oracle and with MySQL keeping persistent connections around is no real gain
> and usually lots of risks
It's certainly good to know how long it takes to get a fres
On 13/11/2014 15:43, Perrin Harkins wrote:
On Thu, Nov 13, 2014 at 10:29 AM, Xinhuan Zheng
mailto:xzh...@christianbook.com>> wrote:
We don’t have any front end proxy.
I think I see the problem... ;)
If you use a front-end proxy so that your mod_perl servers are only
handling mod_perl re
On Thu, Nov 13, 2014 at 10:29 AM, Xinhuan Zheng
wrote:
> We don’t have any front end proxy.
I think I see the problem... ;)
If you use a front-end proxy so that your mod_perl servers are only
handling mod_perl requests, and tune your configuration so that idle
mod_perl servers don't sit around
We don’t have any front end proxy. We don’t use DBD::Gofer nor PGBouncer.
However, we do use Apache::DBI. The mod_perl application on our servers connect
to database when they need to. The database connection can be idle for a long
time if there is no more requests then we’ll get TCP/IP timeout
We use PGBouncer on the web server(which handles keep-alive to the
database) and then we use Apache::DBI across localhost to talk to PGBouncer.
On Thu, Nov 13, 2014 at 9:56 AM, Perrin Harkins wrote:
> Hi,
>
> Can you explain what problem you're trying to solve? Apache processes
> don't have the
Hi,
Can you explain what problem you're trying to solve? Apache processes don't
have the option of doing things when there is no request to serve, so you
can't easily have them disconnect. It may be possible with alarms or cron
jobs or something, but it's probably not a good idea.
If you tune you
Your understanding is correct. It’s what I am looking for. However, due to the
apache forking child nature, I don’t feel comfortable using SIGALARM.
We use Apache::DBI. I would prefer having enhancement in this module. Currently
the module is implementing apache process wide global cache for db
I recently upgraded to 10.10 Yosemite.
After that it wiped out a lot of work I had done for apache and mod_perl.
I also install perlbrew to install everything in my home.
I’m trying to reinstall mod perl but cannot get the configure to work.
I’m reinstalling because some of the modules in perl have
24 matches
Mail list logo
