Zope Alta Performace
Transcrição
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