Zope Alta Performace

Zope Alta Performance
Jorge Ventura<[email protected]>,
Krishna Pennacchioni<[email protected]>
2005-09-15
Resumo
Este documento apresenta uma alternativa de topologia para obtenção
performace de servidores Zope 2.7 em ambientes multi-processados. Tratase de nossa experiência prática com um servidor de páginas que resultou
em um modelo escalável de ótimo desempenho. Apresentaremos as vantagens e as desvantagens decorrente do modelo uma vez que para a melhoria
de desempenho algumas características tiveram que ser alteradas na forma
original de utilização do produto.
Creative Commons versão brasileira
http://lists.ibiblio.org/pipermail/cc-br/2003-August/000018.html
1
Sumário
1 Sobre este HOWTO
1.1
1.2
1.3
1.4
1.5
1.6
1.7
Introdução . . . . . . . . . . . . .
1.1.1 O que é Python . . . . . .
1.1.2 Zope . . . . . . . . . . . .
Problemática . . . . . . . . . . .
Integração Python & Zope . . . .
Cache . . . . . . . . . . . . . . .
Experimentação . . . . . . . . . .
Forma padrão . . . . . . . . . . .
Modelo de várias instâncias . . .
1.7.1 Balanceamento de Carga
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Conclusão
3 Anexos
3.1
3.2
3.3
3.4
conf:
conf:
conf:
conf:
Apache VirtualHost
Zope . . . . . . . . .
ZEO Client . . . . .
ZEO . . . . . . . . .
3
3
3
3
3
4
5
5
5
7
7
8
.
.
.
.
.
.
.
.
.
.
.
.
4 Bibliograa
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
10
23
24
25
2
1 Sobre este HOWTO
1.1 Introdução
Para compreendermos melhor este artigo e a proposta, iniciamos com a explicação do que é python e zope. Assim agregamos informações de base para o
conhecimento coletivo sobre esse assunto.
1.1.1 O que é Python
Python é uma linguagem fácil e agradável de ser utilizada. Foi elaborada por
Guido Van Rossum em 1991 para o ensino de programação. Ela é orientada a
objetos sem lhe forçar a programar desta maneira. É intuitiva e quem aprende
uma vez, nunca se esquece pois é muito próxima de um pseudo-código. Ela não
ca no seu caminho na hora de programar, formada por grandes comunidades1
e é amplamente utilizada nos meios acadêmico, software livre, pesquisa (Google,
NASA), jogos (Disney) dentre outros.
Contém uma vasta biblioteca de funcionalidades incluídas que consiste de
implementações diversas, chegando até ao manuseio de conexões HTTP seguras,
processamento de XML e HTML, bancos de dados e muito mais. Com módulos
extras para coisas mais especícas como engines de jogos e processamento de
imagens. Possui módulos para chamadas entre-processos com RPC, RPC-XML
e outros, incluindo até o RMI2 .
1.1.2 Zope
Criado em 1996 pelo americano Jim Fulton na Digital Creations (DC), USA.
Jim Fulton, o CTO da Digital Creations e Python guru, foi ensinar uma
turma de programadores CGI, que não sabiam muito sobre Python e orientação
a objeto. Comentou a turma o que ele considerava sobre os tradicionais ambiente
de programação CGI: eles são fracos, falta orientação à objetos, e expõe detalhes
dos servidores Web. A partir dessa reexão inicial, o coração do Zope foi escrito
com base no plano de aulas daquela turma.
O DevGuide do Zope, dene o Zope como um framework Open Source para
aplicações Web:
• Um ambiente para o desenvolvimento e gerenciamento de aplicações Web.
• Interpretador de códigos ZPT, DTML, Python.
• Todas as páginas em um servidor Zope são geradas dinamicamente.
1.2 Problemática
É reconhecido pela comunidade de usuários do Zope www.zope.org que este
produto embora apresentando vantagens em suas funcionalidades, não apresenta
1 http://www.python.org, http://www.pythonbrasil.com.br
2 Exclusivo para implementações com Jython, pois é necessário uma máquina virtual Java
3
na conguração padrão bom desempenho para sites que exigem desempenho com
elevadas taxas de consulta.
Para desenvolver os ajustes de performace e otimização, primeiro é necessário
entender a arquitetura de composição e funcionamento do Zope.
1.3 Integração Python & Zope
O que poucas pessoas explicam, como ocorre a integração do Zope como(s)
sistema(s) operacional(ais) e outros programas? Como sabemos, o Zope foi
desenvolvido em Python www.python.org, cujo interpretador de python é nativo/compilado para diversas plataformas (Linux, Windows,MacOs, etc). É por
este motivo que o Zope herda e se benifícia desta portabilidade. A visibilidade
do Zope sobre o sistema operacional é restrita as APIs do python e ao próprio
python, assim tornando o servidor de aplicação mais seguro.
Figura 1: Arquitetura Python & Zope
A problemática começa aqui, ou seja, não basta fazermos ajustes no servidor
Zope, é importante tornar o seu interpretador mais poderoso.
Os recursos mais comuns quando precisamos de mais poder de processamento
são: multi-thread http://www.python.org/doc/2.4/api/threads.html e multicpu. O python nasceu com multi-thread, porém não com multi-cpu. Isto tem
um preço quando a performace é requisito. Na prática quando executamos
o Zope, zope.conf padrão, vericamos que é criado 4 threads sob o controle
de um único processo python, controlado pelo Global interpreter lock ou GIL
http://www.python.org/moin/PythonGlossary. Em um ambiente multi-cpu
4
o GIL restringe a cada thread utilizar a mesma área de memória Zope/python,
não tirando proveito do multi-processamento.
Figura 2: Intel - Hyper-Threading Technology
O lock usado pelo Python assegurar que somente uma thread pode ser executada em um dado momento. Isto simplica o gerenciamento de theads do
Python, assegurando que nenhum dos dois processos possam acessar o mesmo
endereço de memória ao mesmo tempo. O que justica restringir o intérpretador
para tornar o ambiente multi-threads, contudo não deixa de utilizar o paralelismo de máquinas com multi-processadores. Na história do python tentou-se
desenvolver um "free-thread", porém a performace em ambiente uni-processo
foi muito baixa.
1.4 Cache
Outro ponto importante é a velocidade com que o usuário navega no site, ou
seja, qual a taxa de download da página? Em um site estático isso pode ser
resolvido fazendo simples caches das imagens e dos textos pelo próprio servidor
Web (ex.: Apache www.apache.org) ou por um proxy reverso (ex.: SquidSquid
http://www.squid-cache.org/).
Quando lidamos com conteúdo dinâmico, ou seja, constantemente atualizado, o cache é renovado em períodos mais curtos. O objetivo é consumir a
menor carga de processamento com a melhor velocidade possível. Para isso funcionar temos que evitar ao máximo os acessos direto ao servidor de aplicação
(Zope) e tornar distribuição do conteúdo via cache o mais eciênte possível, com
o menor consumo de processamento.
1.5 Experimentação
A arquitetura modular do Zope permite inúmeras congurações para obter a
melhor performace.
1.6 Forma padrão
A aplicação deste estudo foi realizada em um ambiente multi-processador, com a
estimativa de 20 milhões de acessos mês de visitantes. O equipamento utilizado é
um IBM xServer 4 Xeon HT, 4G ram, 2x36G HD SCSI e o sistema operacional
Debian www.debian.org Woody GNU/Linux Kernel SMP version 2.4.26. A
sigla HT signica que neste caso o sistema operacional SMP irá identicar 2x
5
Figura 3: Arquitetura do Zope
o número de processadores HT, ou seja, 2x4=8 processadores Xeon. Este é um
ambiente multi-processador com 8 processadores.
Inicialmente conguramos o zope (2.7.0) na sua forma padrão, 4 threads,
sistema de armazenamento com o ZODB e depois alteramos para:
• armazenamento em Berkley DB http://www.sleepycat.com/
• alteração do zope.conf para 8 threads
Realizamos varios experimentos utilizando o programa AB (Apache HTTP server benchmarking tool) para avaliação de tempos de respostas e consumo de
processamento. Neste momento percebemos claramente que o uso geral dos
processadores foi resumido a um só processador.
Quando nos deparamos com o problema pela primeira vez, percebemos então
que o Zope nunca rodava em mais do que um processador, cou claro que o efeito
do GIL (Global Interpreter Lock) compromete a utilização dos processadores em
um ambiente multiprocessado. Este efeito passou a ser o calcanhar de Aquiles
para a escalabilidade do servidor.
Como usar os outros processadores? Esta foi a questão que fez acreditarmos
que o modelo de arquitetura com a implementação do ZEO (Zope Enterprise
Objects) fosse a resposta.
6
1.7 Modelo de várias instâncias
Montamos um novo cenário com um ZEO, 8 Zopes Clients e um Servidor Web
Apache para rotacionar os acessos entre os Zope clients. Porquê 8 Zopes? Simples um para cada processador. A nova conguração foi alterada para
Figura 4: Arquitetura do Zope
• 4 threads
• 8 instâncias Zope
• 1 instância ZEO com Berkley DB
• Apache2 com mod_rewrite, mod_proxy, mod_deate e mod_cache
A implementação do Apache2 com mod_cache foi fundamental para aumentar
o número de acessos diretos ao site.
1.7.1 Balanceamento de Carga
O Balanceamento de Carga - Load Balance promove o aumento de performance
através da distribuição da carga de forma balanceada. Distribui o tráfego das
chamadas fazendo com que as diferentes máquinas Zope Client que compõe o
cluster funcionem como uma única. Mantém o tempo de resposta das requisições
e oferece escalabilidade de serviços e recursos, ou seja, à medida em que houver
aumento de demanda (novas aplicações, maior número de usuários conectados),
mais máquinas3 podem ser incorporadas ao modelo, multiplicando assim o seu
poder de resposta.
3 Neste caso pode ser máquina física ou virtual
7
RewriteEngine On
# lb - variável dinâmica
# rnd - organiza o acesso randomico e retorna um só valor
# lista.txt - contém uma lista com "dynamic 1|2|3|4|5|6|7|8|9"
RewriteMap lb rnd:/etc/apache2/lista.txt
RewriteCond
%{REQUEST_URI}
^/.*
RewriteRule ^/(.+)$ http://127.0.0.1:1000${lb:dynamic|1}/\
VirtualHostBase/http/www.localhost.net:80/$1 [P,L]
No entanto, chama-se atenção para o fato de que o este modelo está implementando um load sharing e não um load balance, ou seja, congurando o Apache
com o recurso de RewriteMap juntamente com o parametro rnd 4 , irá compartilhar os acessos entre os diferentes Zope Clients sem levar em conta nenhum
critério de balanceamento de carga ou performance dos servidores em si.
2 Conclusão
Para uma aplicação, site com muitos acessos onde há necessidade de processamento é natural em grandes empresas investir em equipamentos que proporcione
os resultados desejados.
O custo de equipamentos com a tecnologia Hyper-Threading da Intel é relativamente mais baixo que equipamentos com N processadores. No estilo For
Dumms o HT sicamente corresponde a um só processador, contudo quando observamos a visão de um sistema operacional SMP (Symmetric multi-processing
support) percebemos a apreseça de dois processadores lógicos.
Com a preocupação de saber quantos processadores estão sendo utlizados
durante os teste, descobrimos um programa chamado slmon, A realização dos
teste foram feitos Durante os experimentos
4 RND é responsável pela leitura sequencial da lista numerada do endereço de rede do Zope
Client
8
3 Anexos
3.1 conf: Apache VirtualHost
<VirtualHost 192.168.0.1:80>
ServerAdmin [email protected]
ServerName www.localhost.net
DocumentRoot /var/www/
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
#
#
#
#
#
#
#
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
ErrorLog /var/log/apache2/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/access.log combined
ServerSignature Off
Alias /icons/ "/usr/share/apache2/icons/"
<Directory "/usr/share/apache2/icons">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
#
#
#
#
#
#
#
#
#
Alias /doc/ "/usr/share/doc/"
RedirectMatch ^/doc/apache2-doc/manual(.*)$ /manual$1
<Directory "/usr/share/doc/">
Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
Allow from 127.0.0.0/255.0.0.0 ::1/128
</Directory>
#########################
# Compressao de HTTP
#########################
<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
DeflateFilterNote ratio
LogFormat '"%r" = (%{ratio}n) ' deflate
CustomLog /var/log/apache2/deflate.log deflate
AddOutputFilterByType DEFLATE text/html text/plain
9
</IfModule>
#########################
# Proxy e ReWrite
#########################
ProxyRequests Off
ProxyReceiveBufferSize 16384
RewriteEngine On
RewriteMap lb rnd:/etc/apache2/lista.txt
RewriteCond
%{REQUEST_URI}
^/.*
RewriteRule ^/(.+)$ http://127.0.0.1:1000${lb:dynamic|1}/\
VirtualHostBase/http/www.localhost.net:80/$1 [P,L]
</VirtualHost>
3.2 conf: Zope
###############################################################################
# Welcome to Zope 2.
###############################################################################
#
# This is the Zope configuration file. The Zope configuration file
# shows what the default configuration directives are, and show
# examples for each directive. To declare a directive, make sure that
# you add it to a line that does not begin with '#'. Note that comments
# are only allowed at the beginning of a line: you may not add comments
# after directive text on the same line.
# ZConfig "defines" used for later textual substitution
%define INSTANCE /var/lib/zope/instance/default
%define ZOPE /usr/lib/zope
%define ZOPECLIENT default
#
#
#
#
#
#
#
#
#
#
#
Directive: instancehome
Description:
The path to the data files, local product files, import directory,
and Extensions directory used by Zope.
Required (no default)
Example:
instancehome /home/chrism/projects/sessions
instancehome $INSTANCE
#
#
#
#
#
#
#
#
#
#
#
Directive: clienthome
Description:
The directory in which a running Zope's process identifier files are
placed.
Default: $INSTANCE/var
Example:
clienthome /home/chrism/projects/sessions/var
10
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
Directive: path
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
Directive: products
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
Directive: environment
Description:
Name of a directory which should be inserted into the
the beginning of Python's module search path. This directive
may be specified as many times as needed to insert additional
directories. The set of directories specified is inserted into the
beginning of the module search path in the order which they are specified
here. Note that the processing of this directive may happen too late
under some circumstances; it is recommended that you use the PYTHONPATH
environment variable if using this directive doesn't work for you.
Default: $INSTANCE/lib/python
Example:
path $INSTANCE/mypymodules
Description:
Name of a directory that contains additional Product packages. This
directive may be used as many times as needed to add additional
collections of products. Each directory identified will be
added to the __path__ of the Products package. All Products are
initialized in ascending alphabetical order by product name. If
two products with the same name exist in two Products directories,
the order in which the packages appear here defines the load
order. The master Products directory exists in Zope's software home,
and cannot be removed from the products path (and should not be added
to it here).
Default: $INSTANCE/Products
Example:
products /home/chrism/projects/myproducts
Description:
A section which can be used to define arbitrary key-value pairs
for use as environment variables during Zope's run cycle. It
is not recommended to set system-related environment variables such as
PYTHONPATH within this section.
Default: unset
Example:
<environment>
MY_PRODUCT_ENVVAR foobar
</environment>
# Directive: debug-mode
#
# Description:
#
A switch which controls several aspects of Zope operation useful for
#
developing under Zope. When debug mode is on:
#
#
- The process will not detach from the controlling terminal
#
#
- Errors in product initialization will cause startup to fail
#
(instead of writing error messages to the event log file).
#
11
#
- Filesystem-based scripts such as skins, PageTemplateFiles, and
#
DTMLFiles can be edited while the server is running and the server
#
will detect these changes in real time. When this switch is
#
off, you must restart the server to see the changes.
#
#
Setting this to 'off' when Zope is in a
#
production environment is encouraged, as it speeds execution (sometimes
#
dramatically).
#
# Default: on
#
# Example:
#
#
debug-mode on
#
#
#
#
#
#
#
#
#
#
#
#
Directive: effective-user
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
Directive: enable-product-installation
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
Directive: locale
Description:
If you intend to run Zope as the "root" user, you must supply this
directive with an effective username or userid number to which Zope
will 'suid' after the server ports are bound. This directive only
has effect under UNIX and if Zope is started as the root user.
Default: unset
Example:
effective-user zope
Description:
If this directive is turned on, Zope performs 'product installation'
(the registration of Python modules in various Products directories)
at startup. Turning this off can speed Zope/ZEO startup time,
but it can also cause your Control_Panel Product list to become
desynchronized with the contents of your Products
directories.
NOTE: Zope *must* be started at least once with
this directive set to "on" or you will receive an error. If using ZEO,
at least one ZEO client must be run with this directive set to "on"
once, the others can have it turned off.
NOTE: If your main storage is mounted read-only,
you must set this directive to "off".
Default: on
Example:
enable-product-installation off
Description:
Enable locale (internationalization) support by supplying a locale
name to be used. See your operating system documentation for locale
information specific to your system. If your Python module does not
support the locale module, or if the requested locale is not
supported by your system, an error will be raised and Zope will not
start.
Default: unset
Example:
locale fr_FR
12
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
Directives: port-base
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
Directive: datetime-format
#
#
#
#
#
#
#
#
#
#
#
Directive: zserver-threads
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
Directive: python-check-interval
Description:
Offset applied to the port numbers used for ZServer
configurations. For example, if the http-server port is 8080 and
the port-base is 1000, the HTTP server will listen on port 9080.
This makes it easy to change the complete set of ports used by a
Zope server process
Default:
0
Example:
port-base 9673
Description:
Set this variable either to "us" or "international" to force the
DateTime module to parse date strings either with
month-before-days-before-year ("us") or
days-before-month-before-year ("international"). The default
behaviour of DateTime (when this setting is left unset) is to
parse dates as US dates.
Default: us
Example:
datetime-format international
Description:
Specify the number of threads that Zope's ZServer web server will use
to service requests. The default is 4.
Default: 4
Example:
zserver-threads 10
Description:
Specify an integer representing the Python interpreter "check
interval" This interval determines how often the interpreter checks
for periodic things such as thread switches and signal handlers. The
Zope default is 500, but you may want to experiment with other values
in order to attempt to increae performance in your particular
environment.
Default: 500
Example:
python-check-interval 1000
# Directive: zserver-read-only-mode
#
# Description:
13
#
If this directive is set to 'on', it will cause Zope to inhibit the
#
creation of log files and pid files. Access and event log files will
#
be presented on standard output. Setting this directive 'on' causes
#
pcgi, fastcgi, and daemon-related directives to have no effect.
#
# Default: off
#
# Example:
#
#
zserver-read-only-mode on
#
#
#
#
#
#
#
#
#
#
#
Directive: pid-filename
#
#
#
#
#
#
#
#
#
#
#
#
Directive: lock-filename
Description:
The path to the file in which the Zope process id(s) will be written.
This defaults to client-home/Z2.pid.
Default: CLIENT_HOME/Z2.pid
Example:
pid-filename /home/chrism/projects/sessions/var/Z2.pid
Description:
The path to a "lock file" which will be locked by Zope while it's
running. This file is used by zopectl.py to determine if Zope is
currently running. This defaults to CLIENT_HOME/Z2.lock.
Default: CLIENT_HOME/Z2.lock
Example:
lock-filename /home/chrism/projects/sessions/var/Z2.lock
# Directive: mime-types
#
# Description:
#
Tells Zope about additional mime.types files that should be
#
loaded. The files have the same format as the mime.types file
#
distributed with Apache. The "mime-types" setting may be given
#
more than once in the configuration file.
#
# Example:
#
#
mime-types $INSTANCE/etc/mime.types
#
#
#
#
#
#
#
#
#
#
#
#
Directive: structured-text-header-level
Description:
Set the default starting HTML header level for structured text
documents. The default is 3, which implies that top-level headers
will be created with an <H3> tag.
Default: 3
Example:
structured-text-header-level 1
# Directive: rest-input-encoding
#
# Description:
14
#
Specifies the input encoding of re-StructuredText documents
#
(e.g. 'utf-8', 'iso-8859-15' or any other valid encoding recognized
#
by Python). The default is your Python's default encoding.
#
# Default: unset (uses system default)
#
# Example:
#
#
rest-input-encoding iso-8859-15
#
#
#
#
#
#
#
#
#
#
#
#
Directive: rest-output-encoding
#
#
#
#
#
#
#
#
#
#
#
#
Directive: rest-header-level
#
#
#
#
#
#
#
#
#
#
#
#
Directive: rest-language-code
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
Directive: cgi-environment
Description:
Specifies the output encoding of re-StructuredText documents
(e.g. 'utf-8', 'iso-8859-15' or any other valid encoding recognized
by Python). The default is your Python's default encoding.
Default: unset (uses system default)
Example:
rest-output-encoding iso-8859-15
Description:
Set the default starting HTML header level for restructured text
documents. The default is 3, which implies that top-level headers
will be created with an <H3> tag.
Default: 3
Example:
rest-header-level 2
Description:
Language code used for some internal translations inside of the docutils
package and for DTD bibliographic elements mapping. See
lib/python/docutils/languages/ for a list of supported language codes.
Default: en
Example:
rest-language-code de
Description:
A section which allows a user to define arbitrary key-value pairs for
use as the initial CGI environment variables. This is useful
when you want to proxy requests from another web server to Zserver,
and would like Zserver's CGI environment to reflect the CGI
environment of the other web server.
Default: unset
Example:
<cgi-environment>
HTTPS_SERVER Foobar Server 1.0
HTTPS_PORT 443
</cgi-environment>
15
#
#
#
#
#
#
#
#
#
#
#
#
Directive: dns-server
#
#
#
#
#
#
#
#
#
#
#
#
#
Directive: ip-address
#
#
#
#
#
#
#
#
#
#
#
Directive: http-realm
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
Directive: automatically-quote-dtml-request-data
Description:
Specify the IP address of your DNS server in order to cause resolved
hostnames to be written to Zope's access log. By default, Zope will
not resolve hostnames unless this is set.
Default: unset
Example:
dns-server 127.0.0.1
Description:
The default IP address on which Zope's various server protocol
implementations will listen for requests. If this is unset, Zope
will listen on all IP addresses supported by the machine. This
directive can be overridden on a per-server basis in the servers
section.
Default: unset
Example:
ip-address 127.0.0.1
Description:
The HTTP "Realm" header value sent by this Zope instance. This value
often shows up in basic authentication dialogs.
Default: Zope
Example:
http-realm Slipknot
Description:
Set this directive to 'off' in order to disable the autoquoting of
implicitly retrieved REQUEST data by DTML code which contains a '<'
when used in <dtml-var> construction. When this directive is 'on',
all data implicitly retrieved from the REQUEST in DTML (as opposed to
addressing REQUEST.somevarname directly) that contains a '<' will be
HTML-quoted when interpolated via a <dtml-var> or &dtml- construct. This
mitigates the possibility that DTML programmers will leave their
sites open to a "client-side trojan" attack.
Default: on
Example:
automatically-quote-dtml-request-data on
# Directive: trusted-proxy
#
# Description:
#
Define one or more 'trusted-proxies' directives, each of which is a
#
hostname or an IP address. The set of definitions comprises a list
#
of front-end proxies that are trusted to supply an accurate
16
#
X-Forwarded-For header to Zope. If a connection comes from
#
a trusted proxy, Zope will trust any X-Forwarded header to contain
#
the user's real IP address for the purposes of address-based
#
authentication restriction.
#
# Default: unset
#
# Example:
#
#
trusted-proxy www.example.com
#
trusted-proxy 192.168.1.1
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
Directive: publisher-profile-file
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
Directive: security-policy-implementation
#
#
#
#
#
#
#
#
#
#
#
#
Directive: skip-authentication-checking
Description:
Names a file on the filesystem which causes Zope's Python
profiling capabilities to be enabled. For more information, see
the Debug Information - > Profiling tab of Zope's Control_Panel
via the Zope Management Interface. IMPORTANT: setting this
filename will cause Zope code to be executed much more slowly
than normal. This should not be enabled in production.
Default: unset
Example:
publisher-profile-file $INSTANCE/var/profile.dat
Description:
The default Zope security machinery is implemented in C.
Change this to "python" to use the Python version of the
Zope security machinery. This impacts performance but
is useful for debugging purposes and required by Products such as
VerboseSecurity, which need to "monkey-patch" the security
machinery.
Default: C
Example:
security-policy-implementation python
Description:
Set this directive to 'on' to cause Zope to skip checks related
to authentication, for servers which serve only anonymous content.
Only works if security-policy-implementation is 'C'.
Default: off
Example:
skip-authentication-checking on
# Directive: skip-ownership-checking
#
# Description:
#
Set this directive to 'on' to cause Zope to ignore ownership checking
#
when attempting to execute "through the web" code. By default, this
#
directive is on in order to prevent 'trojan horse' security problems
#
whereby a user with less privilege can cause a user with more
#
privilege to execute dangerous code.
#
17
# Default: off
#
# Example:
#
#
skip-ownership-checking on
#
#
#
#
#
#
#
#
#
#
#
Directive: maximum-number-of-session-objects
#
#
#
#
#
#
#
#
#
#
#
#
Directive: session-add-notify-script-path
#
#
#
#
#
#
#
#
#
#
#
#
Directive: session-delete-notify-script-path
#
#
#
#
#
#
#
#
#
#
#
#
Directive: session-timeout-minutes
Description:
An integer value representing the number of items to use as a
"maximum number of subobjects" value of the
'/temp_folder/session_data' transient object container.
Default: 1000
Example:
maximum-number-of-session-objects 10000
Description:
An optional fill Zope path name of a callable object to be set as the
"script to call on object addition" of the sessioN_data transient
object container created in the /temp_folder folder at startup.
Default: unset
Example:
session-add-notify-script-path /scripts/add_notifier
Description:
An optional fill Zope path name of a callable object to be set as the
"script to call on object deletion" of the sessioN_data transient
object container created in the /temp_folder folder at startup.
Default: unset
Example:
session-delete-notify-script-path /scripts/del_notifier
Description:
An integer value representing the number of minutes to be used as the
"data object timeout" of the '/temp_folder/session_data' transient
object container.
Default: 20
Example:
session-timeout-minutes 30
# Directive: session-resolution-seconds
#
# Description:
#
An integer value representing the number of seconds to be used as the
#
"timeout resolution" of the '/temp_folder/session_data' transient
18
#
object container.
#
# Default: 20
#
# Example:
#
#
session-resolution-seconds 60
#
#
#
#
#
#
#
#
#
#
#
#
Directive: suppress-all-access-rules
#
#
#
#
#
#
#
#
#
#
#
#
Directive: suppress-all-site-roots
#
#
#
#
#
#
#
#
#
#
#
#
#
Directive: database-quota-size
#
#
#
#
#
#
#
#
#
#
#
Directive: read-only-database
Description:
If this directive is set to on, no access rules in your Zope site
will be executed. This is useful if you "lock yourself out" of a
particular part of your site by setting an improper access rule.
Default: off
Example:
suppress-all-access-rules on
Description:
If this directive is set to on, no site roots in your Zope site will
be effective. This is useful if you "lock yourself out" of a
particular part of your site by setting an improper site root.
Default: off
Example:
suppress-all-site-roots on
Description:
Set this directive to an integer in bytes in order to place a hard
limit on the size which the default FileStorage-backed Zope database
can grow. Additions to the database will not be permitted once this
filesize is exceeded.
Default: unset
Example:
database-quota-size 1000000
Description:
This causes the main Zope FileStorage-backed ZODB to be opened in
read-only mode.
Default: off
Example:
read-only-database on
# Directive: zeo-client-name
#
# Description:
19
#
If you want a persistent ZEO client cache which retains cache
#
contents across ClientStorage restarts, you need to define a
#
zeo-client-name. If you use ZEO and you don't set a
#
zeo-client-name, the client cache is stored in temporary files
#
which are removed when the ClientStorage shuts down. The value
#
of zeo-client-name is used to uniquely identify the local cache
#
files created if this Zope is a ZEO client.
#
# Default: unset
#
# Example:
#
#
zeo-client-name zeo1
# Directives: logger
#
# Description:
#
This area should define one or more "logger" sections of the
#
names "access", "event", and "trace". The "access" logger logs
#
Zope server access. The "event" logger logs Zope event
#
information. The "trace" logger logs detailed server request
#
information (for debugging purposes only). Each logger section
#
may contain a "level" name/value pair which indicates the level
#
of logging detail to capture for this logger. The default level
#
is INFO. Level may be any of "CRITICAL", 'ERROR", WARN", "INFO",
#
"DEBUG", and "ALL". Each logger section may additionally contain
#
one or more "handler" sections which indicates a types of log
#
"handlers" (file, syslog, NT event log, etc) to be used for the
#
logger being defined. There are 5 types of handlers: logfile,
#
syslog, win32-eventlog, http-handler, email-notifier. Each
#
handler type has its own set of allowable subkeys which define
#
aspects of the handler. All handler sections also allow for the
#
specification of a "format" (the log message format string), a
#
"dateformat" (the log message format for date strings), and a
#
"level", which has the same semantics of the overall logger
#
level but overrides the logger's level for the handler it's
#
defined upon. XXXX much more detail necessary here
#
# Default:
#
#
The access log will log to the file <instancehome>/log/Z2.log at
#
level INFO, the event log will log to the file
#
<instancehome>/log/event.log at level INFO, and the trace log
#
will not be written anywhere.
<eventlog>
level all
<logfile>
path $INSTANCE/log/event.log
level info
</logfile>
</eventlog>
<logger access>
level WARN
<logfile>
path $INSTANCE/log/Z2.log
format %(message)s
</logfile>
</logger>
# <logger trace>
# level WARN
# <syslog-handler>
#
host localhost
#
port 514
# </syslog-handler>
20
# <nteventlog-handler>
#
appname Zope
# </nteventlog-handler>
# </logger>
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
Directive: warnfilter
#
#
#
#
#
#
#
#
#
#
#
Directive: max-listen-sockets
Description:
A section that allows you to define a warning filter.
The following keys are valid within a warnfilter section:
action:
one of the following strings:
"error"
"ignore"
"always"
"default"
turn matching warnings into exceptions
never print matching warnings
always print matching warnings
print the first occurrence of matching warnings
for each location where the warning is issued
"module" print the first occurrence of matching warnings
for each module where the warning is issued
"once"
print only the first occurrence of matching
warnings, regardless of location
message:
a string containing a regular expression that the
warning message must match (the match is compiled to
always be case-insensitive)
category: a Python dotted-path classname (must be a subclass of
Warning) of which the warning category must be a subclass in
order to match
module:
a string containing a regular expression that the
module name must match (the match is compiled to be
case-sensitive)
lineno:
an integer that the line number where the warning
occurred must match, or 0 to match all line numbers
All keys within a warnfilter section are optional. More than
one warnfilter section may be specified.
Default: unset
Example:
<warnfilter>
action ignore
category exceptions.DeprecationWarning
</warnfilter>
Description:
The maximum number of sockets that ZServer will attempt to open
in order to service incoming connections.
Default: 1000
Example:
max-listen-sockets 500
# Directives: servers
#
# Description:
21
#
A set of sections which allow the specification of Zope's various
#
ZServer servers. 7 different server types may be defined:
#
http-server, ftp-server, webdav-source-server, persistent-cgi,
#
fast-cgi, monitor-server, and icp-server. If no servers are
#
defined, the default servers are used.
#
#
Ports may be specified either in simple form (80) or in
#
complex form including hostname 127.0.0.1:80. If the hostname
#
is "left off", the default-ip-address is used as the hostname.
#
#
Port numbers are offset by the setting of port-base, which
#
defaults to 8000.
#
# Default:
#
#
An HTTP server starts on port 8080, an FTP server starts on port
#
8021.
<http-server>
# valid keys are "address" and "force-connection-close"
address 10001
# force-connection-close on
</http-server>
#<ftp-server>
# valid key is "address"
# address 8021
#</ftp-server>
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
Examples:
<webdav-source-server>
# valid keys are "address" and "force-connection-close"
address 1980
force-connection-close off
</webdav-source-server>
<persistent-cgi>
# valid key is "path"
path somefile
</persistent-cgi>
<fast-cgi>
# valid key is "address"; the address may be hostname:port, port,
# or a path for a Unix-domain socket
address somefile
</fast-cgi>
<monitor-server>
# valid keys are "address"
address 99
</monitor-server>
<icp-server>
# valid key is "address"
address 888
</icp-server>
# Database (zodb_db) section
#
# Description:
#
A database section allows the definition of custom database and
#
storage types. More than one zodb_db section can be defined.
#
# Default: unset.
#
IMPORTANT: At least one database with a mount-point of "/"
#
must be specified for Zope to start properly.
22
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
<zodb_db main>
# Main FileStorage database
<filestorage>
path $INSTANCE/var/Data.fs
</filestorage>
mount-point /
</zodb_db>
#
#
#
#
#
#
#
#
#
#
#
#
#
Other storage examples
<zodb_db temporary>
# Temporary storage database (for sessions)
<temporarystorage>
name temporary storage for sessioning
</temporarystorage>
mount-point /temp_folder
container-class Products.TemporaryFolder.TemporaryContainer
</zodb_db>
ZEO client storage:
<zodb_db main>
mount-point /
<zeoclient>
server localhost:8100
storage 1
name zeostorage
var $INSTANCE/var
</zeoclient>
</zodb_db>
%include zopeinstance.conf
3.3 conf: ZEO Client
# Database (zodb_db) section
<zodb_db main>
mount-point /
<zeoclient>
server 127.0.0.1:9677
storage 1
name zeostorage
client mmain
var $INSTANCE/var
cache-size 300000000
</zeoclient>
</zodb_db>
# Temporary storage database (for sessions)
<zodb_db temporary>
<zeoclient>
server 127.0.0.1:9677
storage temp
name zeostorage
client $ZOPECLIENT
var $INSTANCE/var
cache-size 200000000
</zeoclient>
mount-point /temp_folder
container-class Products.TemporaryFolder.TemporaryContainer
</zodb_db>
23
3.4 conf: ZEO
# ZEO configuration file
%define INSTANCE /var/lib/zope/instance/zeostorage
<zeo>
address 9677
read-only false
invalidation-queue-size 100
</zeo>
<fullstorage 1>
envdir $INSTANCE/var
frequency 1h
gcpack 12
cachesize 300MB
</fullstorage>
# Temporary storage database (for sessions)
%import tempstorage
<temporarystorage temp>
name temporary storage for sessioning
</temporarystorage>
<eventlog>
level info
<logfile>
path $INSTANCE/log/zeo.log
</logfile>
</eventlog>
<runner>
program $INSTANCE/bin/runzeo
socket-name $INSTANCE/etc/zeo.zdsock
daemon true
forever false
backoff-limit 10
exit-codes 0, 2
directory $INSTANCE
default-to-interactive true
user zope
python /usr/bin/python2.3
zdrun /usr/lib/zope/lib/python/zdaemon/zdrun.py
# This logfile should match the one in the zeo.conf file.
# It is used by zdctl's logtail command, zdrun/zdctl doesn't write it.
logfile $INSTANCE/log/zeo.log
</runner>
24
4 Bibliograa
Referências
[1] http://intel.com/business/bss/products/hyperthreading/
overview.htm [11/05/2005]
[2] http://intel.com/business/bss/products/hyperthreading/
server/demo/index.htm [11/05/2005]
[3] http://www.tldp.org/HOWTO/SMP-HOWTO.html [11/05/2005]
[4] http://www.tldp.org/HOWTO/SMP-HOWTO-3.html\#ss3.3
[11/05/2005]
[5] http://www.ietf.org/rfc/rfc2616.txt [11/05/2005]
[6] http://slmon.sourceforge.net/ [11/05/2005]
[7] http://zope.org/ [11/05/2005]
[8] http://plone.org/ [11/05/2005]
[9] http://python.org/ [11/05/2005]
[10] http://www.pythonbrasil.com.br [11/05/2005]
25