cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] rethinking the cache storage system
Date Mon, 23 Feb 2004 18:28:07 GMT

On Feb 23, 2004, at 10:59, Hochsteger Andreas /INFO-MA wrote:

> Wouldn't it then be possible to serve valid content directly from the 
> apache
> webserver by using the cache on the disk?

This is an entire different problem, Andreas.

> You get the best performance boost, if you don't have to bother cocoon 
> at
> all.

You can do it right now. Here is the httpd.conf file that I use for my 
blog (powered by Linotype on Cocoon):

It allows:

  1) transparent webapp proxying (so you don't have to use mod_jk which 
is a pain to configure)
  2) expire-header-based static artifacts caching (for external proxies 
or browser caches)
  3) automatic deflate (text is gzipped on the flight to save bandwitdh)
  4) static artifacts caching at the web server level (in case proxies 
or browsers don't cache)
  5) SSL redirection for the private part Linotype (I'm concerned with 
password sniffing since I edit my blog from kiosks or internet cafes 
when I travel)

NOTE: [OMISSIS] means things that I don't want people to know. No, it's 
not security thru obscurity is just making things harder :-) [and so 
that Pier doesn't kill me]. Ah, don't worry, port 8000 is firewalled 

<VirtualHost *:80>

DocumentRoot [OMISSIS]
ErrorLog [OMISSIS]
CustomLog [OMISSIS] combined

RewriteEngine On
ExpiresActive On

CacheDefaultExpire 86400
   MCacheSize 4096
   MCacheMaxObjectCount 100
   MCacheMinObjectSize 1
   MCacheMaxObjectSize 2048

ErrorDocument 403 /errors/forbidden.html
ErrorDocument 404 /errors/notfound.html
ErrorDocument 502 /errors/unavailable.html

<Location />
  SetOutputFilter deflate
  BrowserMatch ^Mozilla/4         gzip-only-text/html
  BrowserMatch ^Mozilla/4\.0[678] no-gzip
  BrowserMatch \bMSIE             !no-gzip !gzip-only-text/html
  SetEnvIfNoCase Request_URI     .(?:gif|jpe?g|png)$ no-gzip dont-vary
  Header append Vary User-Agent env=!dont-vary

# ------- Stefano's linotype -------------

RewriteRule ^/~stefano/linotype/private/.*$1 [R]

ProxyPass        /~stefano/linotype/ http://localhost:8000/linotype/
ProxyPassReverse /~stefano/linotype/ http://localhost:8000/linotype/

CacheEnable mem /~stefano/linotype/

<Location /~stefano/>
  ExpiresByType text/css "access plus 1 week"
  ExpiresByType text/javascript "access plus 1 week"
  ExpiresByType image/gif "access plus 1 week"
  ExpiresByType image/jpeg "access plus 1 week"
  ExpiresByType image/png "access plus 1 week"


<VirtualHost *:443>

DocumentRoot [OMISSIS - same as the other one]
ErrorLog [OMISSIS]
CustomLog [OMISSIS] combined

SSLEngine on
# need to allow weaker certificates because in some countries crypto 
regulation still applies
SSLCertificateFile [OMISSIS]
SSLCertificateKeyFile [OMISSIS]

SetEnvIf User-Agent ".*MSIE.*" \
          nokeepalive ssl-unclean-shutdown \
          downgrade-1.0 force-response-1.0

ProxyPass        /~stefano/linotype/ http://localhost:8000/linotype/
ProxyPassReverse /~stefano/linotype/ http://localhost:8000/linotype/

RewriteEngine On
# redirect to regular site for the static artifacts since I don't care 
about the security of those
# and SSL crypto is a CPU intensive thing and I want to reduce it as 
much as possible
RewriteRule ^/~stefano/(.*)\.(gif|jpe?g|png|css|js)$$1.$2 [R]

ErrorDocument 403 /errors/forbidden.html
ErrorDocument 404 /errors/notfound.html
ErrorDocument 502 /errors/unavailable.html


> But I think the problem is: How does Apache know, if the content is 
> still
> valid? :-(

Eheh, Pier, Gianugo and I have been having interesting discussions 
about this offline, but this is another topic and doesn't really belong 
to this thread.

> Perhaps it would be only a solution for dynamically generated binary 
> files
> (images, pdfs, ...) where you know beforehand that they are valid for a
> certain time.

What I mean for "cache storage system" is where to put the "internal 
pipeline artifacts" not the *results* of the pipelines.

In my mind, cocoon should *NOT* cache the results of the pipelines AT 
ALL! The frontends should do it! Either Apache (as I'm doing it right 
now), Squid or a ad-hoc web accelerator that can be forced to 
invalidate (Pier is thinking about building one of those)



View raw message