Neil Gunton wrote:
Neil Gunton wrote:
Neil Gunton wrote:
It seems like this might have something to do with mod_deflate, which
I am using in combination with mod_disk_cache. This page gives a clue
that there might be a problem with the way files are cached when these
modules are both enabled
Neil Gunton wrote:
Neil Gunton wrote:
It seems like this might have something to do with mod_deflate, which I
am using in combination with mod_disk_cache. This page gives a clue that
there might be a problem with the way files are cached when these
modules are both enabled:
http
Neil Gunton wrote:
Well, the du just finished, it took 214 minutes to complete. I just took
a look at one of the directories in the cache. Now, I have it set for a
depth of 3, so I looked at d/d/d just randomly selected. Then I did a du
there. Here's the output:
server:/var/cache/www/d/d/
Perrin Harkins wrote:
A ton of RAM in the server might help too.
I've already got 4GB in there.
Well, the du just finished, it took 214 minutes to complete. I just took
a look at one of the directories in the cache. Now, I have it set for a
depth of 3, so I looked at d/d/d just randomly select
André Warnier wrote:
Neil Gunton wrote:
[...]
Hi.
I am not really an expert on large websites, caches and so on, but in
our applications we are managing a large number of files.
One of the things we have learned over the years, is that even on modern
operating systems, having large numbers of
Michael Peters wrote:
Michael Peters wrote:
But these benchmarks (http://www.debian-administration.org/articles/388)
say the following:
For quick operations on large file tree, choose Ext3 or XFS.
Benchmarks from other authors have
supported the use of ReiserFS for operations on large nu
Perrin Harkins wrote:
On Mon, Nov 24, 2008 at 2:42 PM, Neil Gunton <[EMAIL PROTECTED]> wrote:
The section on "Maintaining the Disk Cache" says you should use
htcacheclean, which is what I've been doing, and it doesn't seem to be up to
the job.
I can't speak to y
Neil Gunton wrote:
http://httpd.apache.org/docs/2.0/mod/mod_disk_cache.html#cachegcinterval
Oops - sorry, I seem to have been looking at the 2.0 docs, rather than
the 2.2. In 2.2, it appears that CacheGCInterval has disappeared...
Now, looking at the 2.2. caching guide:
http
Perrin Harkins wrote:
One thing you didn't mention is why you're using mod_cache at all for
things not generated by mod_perl. Why don't you serve the static
files directly from your front-end server? That's the most common
setup I've seen, with proxying only for mod_perl requests.
Yes, I am o
Neil Gunton wrote:
The cache and front-end proxy help to serve images without bogging down
the heavy mod_perl processes, while also obviously caching the mod_perl
content. The site gets around 100,000 page requests or more per day. The
cache is set to 1000MB, with htcacheclean running in
Hi all,
I posted this to the Apache httpd users list, but no reply there, so I'm
posting here in the hopes that someone else who uses mod_perl with
mod_cache in a reverse proxy setup might have insight.
I am using Apache 2.2.9 (built from source) on Debian Lenny to run a
fairly large communi
David Christensen wrote:
I'd try asking your question on an EmbPerl community, such as:
http://perl.apache.org/embperl/
I did ask the question there first, this last Wednesday, but I got no response.
:-(
-Neil
Philip M. Gollucci wrote:
The version of Perl is "v5.8.4 built for i386-linux-thread-multi".
It's the one that came with Sarge.
Have you tried upgrading to 5.8.7 ?
No, I was hoping to be able to stay with the "stock" perl, to ease future debian upgrades. But if
that will fix the problem then
Hi all,
I am currently using Embperl 1.3.6, with Apache 1.3.33 and mod_perl 1.29 on a new install of Debian
Sarge. Previously this was running on Debian Woody without issues, but there appears to be a new
threaded version of perl (5.8.4) which is causing messages to the error log every time a c
14 matches
Mail list logo
