Is there any way to configure Mongrel's logging? Specifically, I'd like to
get it to output to syslog. Our Rails apps already do this (via
SyslogLogger) - is there any way to persuade Mongrel to do the same?
Thanks!
--
paul.butcher-msgCount++
Snetterton, Castle Combe, Cadwell Park...
Who says I
Zed wrote:
* Using the mysql.rb instead of installing the actual mysql compiled
gem. The mysql.rb is just for development, and it sucks horribly.
Please forgive the stupid question, but how does one tell whether one is
using the mysql compiled gem or not? I've installed it, apparently
We have been searching for a Rails deployment architecture which works for
us for some time. We've recently moved from Apache 1.3 + FastCGI to Apache
2.2 + mod_proxy_balancer + mongrel_cluster, and it's a significant
improvement. But it still exhibits serious performance problems.
We have the
Zed Shaw zedshaw at zedshaw.com wrote
But, if your interface is time sensitive then why does it have actions
that take too much time? See the conundrum there?
I was kinda expecting that response, Zed, but I didn't want to rob you of
the pleasure of saying it ;-)
We are in fact using
Have you ever use haproxy http://haproxy.1wt.eu/ ?!
In a word, no :-)
He have the following feature which can help you:
Thanks - sounds interesting. We'll give it a go!
--
paul.butcher-msgCount++
Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?
MSN: [EMAIL
On 16 Oct 2007, at 06:49, Zed A. Shaw wrote:
On Mon, 15 Oct 2007 16:43:34 -0700
Brian Williams [EMAIL PROTECTED] wrote:
We recently ran into exactly this issue. Some rails requests were
making
external requests that were taking 5 minutes (networking issues
out of our
control).
Now
On 15 Oct 2007, at 21:52, Robert Mela wrote:
I've discovered a setting in mod_proxy_balancer that prevents the
Mongrel/Rails request queuing vs. accept/close problem from ever
being reached.
Thanks for that, Robert. We've hit exactly the same issue in the
past, but have been unable to
