Logeese a su sitio Zope como usuario con derechos de Manager y navegue a su Sitio Plone a través del ZMI. Click the HTTPCache y luego mire en la pestaña Associate. Notar que ningún ítem esta asociado actualmente con este.

Cuando asociamos ítems con el HTTPCache, usted no esta asociando content ítems, en cambios usted esta asociando las diferentes vistas disponibles. Esto significa que usted puede asegurarse que su template view esta siendo cacheada, pero edit templates no lo esta. Asegúrese que las opciones All para Locate Cacheable Objects, All para Of the type(s) y Search Subfolders están todas seleccionadas, click el botón Locate. Luego de algunos momentos, usted debería obtener una lista de todos los skin ítems en su sitio.

Preste mucha atención sobre los ítems que ha seleccionado de la lista. Usted puede seguramente cachear todas las imágenes, todos los archivos, todos los CSS y todos los Javascripts. Además, usted debería asegurarse que los templates de view para todos los content types disponibles están siendo cacheados. (Por ejemplo, newsitem_view para los News Items.) Este especialmente seguro de chequear que cualquier ítems que usted haya customizado dentro de una carpeta skin diferente haya sido además seleccionado.

Ahora usted debería tener una lista muy larga con ítems a ser cacheados, ahora solo clickee para guardar sus cambios.

IMPORTANTE: Si usted selecciona templates que están localizados en el sistema de archivos, la asociación con un cache manager no persistirá, por lo tanto esta se habrá ido la próxima ves que usted reinicie el servidor. Para crear una cache manager asociación persistente, usted debería utilizar archivos .metadata sobre el sistema de archivos. Por ejemplo, mire en cualquiera de los archivos en plone_images.

Asumiendo que usted ha hecho todo esto de manera correcta, debería poder ver ahora que apache esta comenzando a cachear sus páginas. Podemos comprobar esto usando wget y mostrando la salida de HTTP response:

  wget -sS --delete-after http://yoursite.com/

  --03:28:46-- http://yoursite.com/
  => `index.html'
  Resolving yoursite.com... done.
  Connecting to yoursite.com[WWW.XXX.YYY.ZZZ]:80... connected.
  HTTP request sent, awaiting response...
  1 HTTP/1.1 200 OK
  2 Date: Mon, 19 Jan 2004 03:28:46 GMT
  3 Server: Zope/(unreleased version, python 2.3.2, linux2) ZServer/1.1 Plone/2.0-RC3
  4 Vary: Accept-Encoding
  5 Content-Length: 32125
  6 Expires: Mon, 19 Jan 2004 04:28:43 GMT
  7 Last-Modified: Mon, 19 Jan 2004 03:28:43 GMT
  8 Cache-Control: max-age=3600
  9 Content-Type: text/html;charset=utf-8
  10 Age: 4
  11 X-Cache: HIT from yoursite.com
  12 Connection: close

Notar que ahora la cabecera X-Cache esta mostrando un cache HIT. Esto es exactamente el resultado que nosotros queremos. Ahora que Apache esta cacheando el resultado de sus paginas Plone, usted puede probar para ver que tipo de diferencias ha logrado esto. Una ves mas, usando la utilidad Apache Benchmark, nosotros podemos probar el sitio:

  /usr/sbin/ab -n 100 http://yoursite.com/

  Benchmarking yoursite.com (be patient).....done
  Server Software: Zope/(unreleased
  Server Hostname: yoursite.com
  Server Port: 80

  Document Path: /
  Document Length: 32125 bytes

  Concurrency Level: 1
  Time taken for tests: 0.116 seconds
  Complete requests: 100
  Failed requests: 0
  Broken pipe errors: 0
  Total transferred: 3252200 bytes
  HTML transferred: 3212500 bytes
  Requests per second: 862.07 [#/sec] (mean)
  Time per request: 1.16 [ms] (mean)
  Time per request: 1.16 [ms] (mean, across all concurrent requests)
  Transfer rate: 28036.21 [Kbytes/sec] received

Note en particular el tiempo tomado para esta prueba: 0.116 segundos, o mucho mejor 0.0016 segundos por petición! Esto nos da alguna indicación de que tan rápido sera este sitio capaz de correr.

Usando Apache Benchmark para controlar 100 peticiones consecutivas es apenas un indicativo de la verdadera velocidad en la que su sitio esta corriendo, sin embargo. Para poner esta configuración en una prueba verdadera, trate usando el rasgo de coincidencias, que le permite controlar peticiones simultáneamente. En este ejemplo, ab controla 100000 peticiones con 100 peticiones coincidentes. Esto es el equivalente a un sitio a enterprise-level bajo media a pesada carga:

  /usr/sbin/ab -n 100000 -c 100 http://yoursite.com/

  Benchmarking yoursite.com (be patient)
  Server Software: Zope/(unreleased
  Server Hostname: poked.org
  Server Port: 80

  Document Path: /
  Document Length: 32125 bytes

  Concurrency Level: 100
  Time taken for tests: 115.732 seconds
  Complete requests: 100000
  Failed requests: 0
  Broken pipe errors: 0
  Total transferred: -1041856680 bytes
  HTML transferred: -1081567796 bytes
  Requests per second: 864.07 [#/sec] (mean)
  Time per request: 115.73 [ms] (mean)
  Time per request: 1.16 [ms] (mean, across all concurrent requests)
  Transfer rate: -9002.32 [Kbytes/sec] received

Estos resultados muestran que la combinación de Apache y Zope es capaz de servir 100000 solicitudes poe debajo de los 2 minutos. Vale la pena recordar otra vez que esto está sobre una 1.8GHz Intel Celeron con sólo 128MB de RAM, corriendo un sistema básico de Redhat 7.3, que es muy lento para un servidor de producción. Sobre un servidor típico Intel Dual Xeon 2.4GHz con 1GB de RAM, espere un aumento de velocidad de más del 100%.

Vale la pena indicar que hay limitaciones sobre este intento de cacheado. En el ajuste de la cabecera Last-Modified al tiempo en que la página fue dada y el ajuste de la max-age a 3600 segundos, hace que todo el contenido del sitio tenga un tiempo de vida de 1 hora. Esto quiere decir que en el peor de los casos, una actualización del sitio podría tomar una hora para aparecer. Esto puede ser resuelto forzando una anulación del cacheado para una página en particular, que puede ser hecho simplemente CTRL-refeshing la página en la mayor parte de los navegadores.

Otra limitación es que, si usted usa su nombre de dominio principal para logearse y editar su sitio de Plone, usted puede experimentar algún comportamiento extraño en los navegadores que no respetan correctamente las cabeceras de caching (como Internet Explorer). Un modo fácil de trabajar alrededor de esto es añadir un nuevo subdominio para los usuarios que están editando su sitio, como cms.yoursite.com. Entonces, en su archivo de configuración de Apache, simplemente añada una nueva sección VirtualHost para su CMS de vista, sin cualquiera de las directivas de caching:

  <VirtualHost *>
  ServerName cms.yoursite.com
  ServerAdmin webmaster@yoursite.com
  ProxyPass / http://cms.yoursite.com:8080/VirtualHostBase/http/cms.yoursite.com:80/yourplonesite/VirtualHostRoot/
  ProxyPassReverse / http://cms.yoursite.com:8080/VirtualHostBase/http/cms.yoursite.com:80/yourplonesite/VirtualHostRoot/
  </VirtualHost>

Así, cualquiera que tenga que editar el sitio evitará el caching completamente.