You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Steve Reppucci <re...@boston.com> on 2000/02/23 14:02:36 UTC

Caching configuration

OK, I'm stumped.

Environment:	Solaris (sparc) 2.6
		apache 1.3.11
		modperl 1.21
		perl 5.00503

I've got a heavy modperl server, dynamically generating date bar
images (http://date.boston.com/).  I'm setting up a high speed, low
drag proxying server in front of this to free the heavy server from
the burden of sending data to clients at the end of slow dialup
connections, as recommended in Stas' guide.

The proxying part works fine, but in trying to get the proxy server to
cache the generated images, I can't seem to get it to work correctly.
Running 'ab' to put a load on the server, I see requests to the proxy,
and its (the proxy's) requests to the backend server for every
request.

(For testing, I currently have the proxying server running on port
8080 -- http://date2.boston.com:8080/, and the modperl server on port
80.)

Here are some pertinent lines from my config:
  ProxyRequests on

  ProxyPass     /  http://date2.boston.com:80/

  CacheRoot "/apache/proxy2/cache"
  CacheSize 100
  CacheGcInterval 4
  CacheMaxExpire 24
  CacheLastModifiedFactor 0.1
  CacheDefaultExpire 1

Yes, the cache directory is owned by the user/group that the web
server is running as.

Yes, my date generation module is supplying an 'Expires' header to the
returned image.

The only thing in the cache directory is a '.time' file, with a
modification time that reflects that of the last server request.

Anyone have any ideas what could be causing the caching not to work?

Thanks.
<Steve>

-=-=-=-=-=-=-=-=-=-  My God!  What have I done?  =-=-=-=-=-=-=-=-=-=
Steve Reppucci                                          617/929-7003
Director of Software Development                 reppucci@boston.com
Boston.com (Times Company Digital)                           Be Open


Re: off topic (no modperl content)

Posted by Vivek Khera <kh...@kciLink.com>.
>>>>> "HR" == Haroon Rafique <ha...@www-noet.nsd.att.com> writes:

HR> Has the list changed it's software and/or configuration in the past
HR> couple of weeks. The reason I ask is because I use procmail and Jari
HR> Aalto's pm-jalist.rc file to filter mailing lists. Lately, the recipe

Yes it has changed.  You should filter on the Mailing-List header's
value.


Re: Caching configuration

Posted by Steve Reppucci <re...@boston.com>.
Thanks Ilya,

The directives *are* in a virtual host section.

I'm certain that the content length directive is being sent, but
possibly not a "Last-Modified" header, I'll check on this.

Thanks for the suggestions!
<Steve>

On Wed, 23 Feb 2000, Ilya Obshadko wrote:

> Hello Steve,
> 
> �����, 23 ������� 2000 �., you wrote:
> 
> 
> SR>   ProxyRequests on
> 
> SR>   ProxyPass     /  http://date2.boston.com:80/
> 
> SR>   CacheRoot "/apache/proxy2/cache"
> SR>   CacheSize 100
> SR>   CacheGcInterval 4
> SR>   CacheMaxExpire 24
> SR>   CacheLastModifiedFactor 0.1
> SR>   CacheDefaultExpire 1
> 
> If this is version of apache prior to 1.3.11, you should declare all
> mod_proxy directives in VitualHost context, otherwise it doesn't work
> at all ;) I heard that this is fixed in 1.3.11, but I'm not certain
> about it.
> 
> SR> Yes, my date generation module is supplying an 'Expires' header to the
> SR> returned image.
> 
> Does it also supply "Content-Length" and "Last-Modified"? It really
> should, otherwise mod_proxy won't cache the data.
> 
> SR> The only thing in the cache directory is a '.time' file, with a
> SR> modification time that reflects that of the last server request.
> 
> SR> Anyone have any ideas what could be causing the caching not to work?
> 
> Seems like this is a first case.
> 
> Best regards,
>  Ilya                            mailto:ilya@zhurnal.ru
> 
> 

-=-=-=-=-=-=-=-=-=-  My God!  What have I done?  =-=-=-=-=-=-=-=-=-=
Steve Reppucci                                          617/929-7003
Director of Software Development                 reppucci@boston.com
Boston.com (Times Company Digital)                           Be Open


Re: Caching configuration

Posted by Steve Reppucci <sg...@boston.com>.
OK, Ilya's suggestion of adding a 'Last-Modified' header was apparently
the key piece I was missing, adding this made the caching stuff work as
expected.

Interesting to note however, that file-based caching actually resulted in
a slower response -- my date module caches generated images in memory, so
having the proxy server simply draw from the cached copy served by the
modperl server seems to offer the best performance.  The proxying piece is
a definite win though -- server load appears down significantly in
somewhat limited tests thus far.

Thanks for the help.
<Steve>


On Wed, 23 Feb 2000, Ilya Obshadko wrote:

> Hello Steve,
> 
> �����, 23 ������� 2000 �., you wrote:
> 
> 
> SR>   ProxyRequests on
> 
> SR>   ProxyPass     /  http://date2.boston.com:80/
> 
> SR>   CacheRoot "/apache/proxy2/cache"
> SR>   CacheSize 100
> SR>   CacheGcInterval 4
> SR>   CacheMaxExpire 24
> SR>   CacheLastModifiedFactor 0.1
> SR>   CacheDefaultExpire 1
> 
> If this is version of apache prior to 1.3.11, you should declare all
> mod_proxy directives in VitualHost context, otherwise it doesn't work
> at all ;) I heard that this is fixed in 1.3.11, but I'm not certain
> about it.
> 
> SR> Yes, my date generation module is supplying an 'Expires' header to the
> SR> returned image.
> 
> Does it also supply "Content-Length" and "Last-Modified"? It really
> should, otherwise mod_proxy won't cache the data.
> 
> SR> The only thing in the cache directory is a '.time' file, with a
> SR> modification time that reflects that of the last server request.
> 
> SR> Anyone have any ideas what could be causing the caching not to work?
> 
> Seems like this is a first case.
> 
> Best regards,
>  Ilya                            mailto:ilya@zhurnal.ru
> 
> 

=-=-=-=-=-=-=-=-=-=-  My God!  What have I done?  -=-=-=-=-=-=-=-=-=-=
Steve Reppucci                                       sgr@logsoft.com |
Logical Choice Software                          http://logsoft.com/ |
508/958-0183                                                 Be Open |


off topic (no modperl content)

Posted by Haroon Rafique <ha...@www-noet.nsd.att.com>.
This is totally off topic, so consider yourselves forewarned and apologies
in advance. The subject is how to filter the modperl mailing list by
using Jari Aalto's pm-jalist.rc procmail recipe.

(Should I be labeling the subject with a code word like NMC
- No Modperl Content)...?

Has the list changed it's software and/or configuration in the past
couple of weeks. The reason I ask is because I use procmail and Jari
Aalto's pm-jalist.rc file to filter mailing lists. Lately, the recipe
fails to filter it as a mailing list and sends it straight to my inbox
(a little annoying to see a lot of traffic in the inbox). You can get
the pm-code.zip file from www.procmail.org.

Anyone else experiencing the same????

Thanks in advance,
--
Haroon Rafique
Web Dude
AT&T                                     haroon@att.com


Re: Caching configuration

Posted by Ilya Obshadko <il...@zhurnal.ru>.
Hello Steve,

среда, 23 февраля 2000 г., you wrote:


SR>   ProxyRequests on

SR>   ProxyPass     /  http://date2.boston.com:80/

SR>   CacheRoot "/apache/proxy2/cache"
SR>   CacheSize 100
SR>   CacheGcInterval 4
SR>   CacheMaxExpire 24
SR>   CacheLastModifiedFactor 0.1
SR>   CacheDefaultExpire 1

If this is version of apache prior to 1.3.11, you should declare all
mod_proxy directives in VitualHost context, otherwise it doesn't work
at all ;) I heard that this is fixed in 1.3.11, but I'm not certain
about it.

SR> Yes, my date generation module is supplying an 'Expires' header to the
SR> returned image.

Does it also supply "Content-Length" and "Last-Modified"? It really
should, otherwise mod_proxy won't cache the data.

SR> The only thing in the cache directory is a '.time' file, with a
SR> modification time that reflects that of the last server request.

SR> Anyone have any ideas what could be causing the caching not to work?

Seems like this is a first case.

Best regards,
 Ilya                            mailto:ilya@zhurnal.ru