Iran Miranda Rodrigues - imr@di.ufpe.br

Massilon Júnior – mgsj@di.ufpe.br.

Luis Humberto – lrhp@di.ufpe.br

Este trabalho apresenta uma discussão sobre os efeitos na performance de servidores Web em situações de sobrecarga. Por situações de sobrecarga, entendemos aquelas caracterizadas por um número grande de acessos simultâneos com ou sem a transferência de uma grande quantidade de informação.

Num primeiro momento, apresentamos uma breve discussão sobre os sintomas que podem caracterizar sobrecarga no servidor, e algumas considerações sobre possíveis causas.

Em seguida, apresentamos uma classificação simplificada de tipos de servidores e os pontos críticos de performance e segurança associado a cada um deles. Esta classificação poderá ser usada para a escolha do servidor associado a uma situação de demanda real e dos pontos mais relevantes com relação à performance. Além disso, discutiremos brevemente alguns parâmetros para a escolha de um servidor bem como alguns métodos de acompanhamento de performance.

Uma vez caracterizadas situações de sobrecarga e métodos para identificá-las, apresentamos algumas alternativas para resolver o problema, desde a distribuição dos dados entre vários servidores, até a replicação dos dados e o uso de balanceadores de carga, software ou hardware que fazem a distribuição dos pedidos entre vários servidores. Por fim, apresentamos uma outra solução através de um estudo de caso de web site muito acessado.

O que significa um Web server "muito acessado" ? consideramos o número de conexões simultâneas e a quantidade média de informação transferida por cada conexão como medidas para a carga de um servidor web.

Entre os sintomas de sobrecarga do Web server, podemos indicar:

Entre os fatores que influenciam na sobrecarga do servidor, podemos indicar:

O design do web site é importante porque para cada página recuperada, podem ser feitas várias conexões, dependendo do número de objetos existentes na página. Por exemplo, uma página web contendo um gráfico, quatro botões e um bloco de texto necessita de seis conexões para ser transferida completamente para o cliente. Deste modo, o núemro de conexões pode ser bastante reduzido se houver a preocupação do reaproveitamento de objetos, como botões, padrões das páginas, etc. A performance do servidor claramente pode ser comprometida se não houver uma atenção neste sentido.

Ttimesharing

Um processo servidor por conexão

fork() - Operação muito cara, em comparação com o tempo de vida do processo.

Podemos dividir os servidores em quatro grandes grupos:

• Milhares de conexões por dia
• Não implementam segurança de transação

Exemplos:

• Netscape Communications Server
• Navisoft’s Naviserver
• Oracle WebServer 1.0

• Aplicações críticas ( performance)
• Tráfego seguro de informações
• Alta integração a banco de dados

Exemplo:

• Netscape commerce server

• Ip privados
• Controle rígido de acesso

Exemplos:

• O’Reilly Website
• Quarterdeck’s Webserver

• Netpublish (American Library Services)

Indexa de acordo com Z39.50

• Plataformas específicas

Parâmetros importantes para a escolha do web server são os seguintes:

• Controle de acesso
• Endereços IP
• Nomes
• Diretórios
• Usuários
• Integração com o banco de dados

Uma das soluções usados para aumentar a performance de servidores web com um grande número de acessos é usar o balanceamento de carga. A idéia desta solução apresentada ao problema é dividir as requisições de serviço entre múltiplos servidores web. Os servidores que atenderão às requisições serão escolhidos principalmente com base no seu poder de processamento e sua carga de trabalho. Esta escolha é feita através de uma monitoração em tempo real com o objetivo de determinar quais servidores são capazes de atender aos pedidos e, com isso, evitar a criação de congestionamentos.

O serviço de balanceamento de carga pode ser feito por meio de hardware ou software. Outros fatores que podem influenciar na decisão são a quantidade necessária de conexões TCP abertas, o throughput desejado, como será feito o gerenciamento e o custo de cada implementação.

Os servidores de balanceamento de cargo são colocados entre o roteador e o switch da rede local onde estão localizados os servidores web. O trabalho deste servidor consiste em receber as requisições e encaminha-las para algum dos servidores web da rede. Essa decisão é feita através do algoritmo do servidor de balanceamento. Para realizar esta tarefa, é preciso que este servidor esteja monitorando sempre o número de servidores web disponíveis, os recursos que eles dispõem (memória livre, velocidade de processamento) e a quantidade de conexões TCP sendo tratadas por eles. Outra questão de grande importância é a eficiência dos servidores web, ou seja, o quão rápido eles conseguem tratar as requisições. Isso é medido usando um timestamp e calculando o tempo gasto para o retorno da resposta. Desta forma é possível atribuir mais trabalho a servidores mais rápidos.

Os servidores de balanceamento guardam informações sobre as requisições tratadas em tabelas como a dos roteadores. Eles armazenam o IP da fonte e do destino bem como a porta TCP também da fonte e do destino. Esses dados são necessários para o envio correto da resposta. Isso porque o servidor de balanceamento se comunica com os servidores web usando IP’s virtuais internamente. Esses endereços não podem ser devolvidos ao browser pois senão na próxima requisição seria feita uma tentativa de se comunicar diretamente com esse endereço e o mesmo não seria achado nas tabelas de roteamento. Desta forma, o fato de estar sendo usado um servidor de balanceamento se torna transparente ao usuário.

A solução implementada em software se diferencia do hardware no tratamento dos IP’s virtuais. No caso do hardware, o servidor de balanceamento recebe a requisição e a direciona a um servidor web da rede. Ele deve também receber o pacote que está sendo enviado de resposta do servidor web para o browser a fim de alterar o valor do IP virtual para o IP real. Isso não acontece na solução em software pois o programa de balanceamento de carga apenas se preocupa em direcionar as requisições para os servidores web. No pacote do servidor de balanceamento, junto com o servidor vem um agente que precisa ser instalado em todos os servidores web. Esse agente fica então responsável por tratar da substituição do IP virtual para o IP real no pacote que será enviado como resposta. O problema que é ocasionado pelos agentes é que eles são mais um programa que precisa ser configurado em cada servidor web.

Os servidores de balanceamento precisam ser capazes de tratar um alto número de conexões simultâneas. Em uma máquina configurada com 32 MBytes de memória RAM, teoricamente é possível ter 1.000.000 de conexões simultâneas, visto que para se abrir uma conexão TCP são necessários 32 bytes. Mas existe uma diferença crucial entre abrir uma conexão e utiliza-la. Segundo dados estatísticos, cada conexão TCP aberta, transmite cerca de 10 Kbytes, para que um servidor de balanceamento pudesse manter 1.000.000 de conexões TCP ativas concorrentemente ele deveria ser capaz de suportar um throughput de 10 Gbytes/s. Nenhum dos produtos, seja em hardware ou software, chega perto dessa capacidade. Mas é preciso antes de se levar em consideração esses números, fazer uma análise de quantas conexões TCP abertas o servidor realmente precisará. Serviços de busca altamente utilizados como o Excite atingem 30.000 conexões simultâneas nos horários de pico.

Os servidores de balanceamento precisam ser monitorados constantemente como qualquer outro serviço de rede. Esse monitoramento e gerenciamento são feitos em sua maioria usando SNMP. Algumas das companhias fornecedoras desse serviço utilizam formato proprietário e anunciam breve suporte para SNMP enquanto outras procuram desenvolver cada vez mais seus formatos proprietários.

O travelocity é um serviço de reserva de passagens e agência turística, baseado na web, com mais de 300.000 web pages que podem ser acessadas em 5 segundos. Este número ajuda a explicar o por que do Travelocity ter mais de 30.000.000 de hits por mês.

O grande problema do Travelocity é, que por ter um grande número de informações, se faz necessário o uso de um banco de dados, (neste caso é o oracle7) e como sabemos não existe maneira para que seu Web server, (neste caso é o Netscape Enterprise Server) fale diretamente com o banco de dados do Travelocity. Isto significa que os visitantes do site nunca estarão acessando dados correntes. A atualização é garantida através de batch files que atualizam as informações semanalmente.

As informações são enviadas diariamente ao banco de dados da Travelocity, as atualizações são feitas usando-se CGI semanalmente. O CGI é responsável pela conversão dos dados relacionais em HTML. Scripts CGI são muito difíceis de codificar e quase impossível de se reusar. Segundo a empresa, o problema com scripts CGI é que você tem que escrever um script para cada página e CGI não é a melhor maneira de se acessar dados.

Para solucionar estes problemas, a empresa optou por uma arquitetura que ela chamou de Three-Tiered, que adiciona um servidor de aplicativos(neste caso é o Kiva Enterprise Server) que permite o banco de dados Oracle falar diretamente com o web server. Com esta arquitetura somado a um aplicativo para comércio eletrônico (neste caso é o Netscape Commerce e o Merchante Servers) o sistema atingiu a performance de 4.000 a 5.000 consultas por segundo feitas ao banco de dados Oracle7.

Cada vez mais os servidores web têm ganho importância. Deste modo vários fabricantes de sistemas Operacionais têm desenvolvido servidores mais intimamente ligados ao sistema Operacional, com o objetivo de ganhar performance. Exemplos são a Microsoft, com o Microsoft IIS e o Windows Nt, a Novel com o Novell web server e o IntranetWare e por fim a Sun Microsistems, que desenvolveu o Sun Web server bastante associado com o SO Solaris 2.5. Segundo a própria Sun, nenhum servidor web têm melhor desenpenho rodando em Solaris do que o Sun Web Server.

Web Servers Get Ready for Some Real Work

Johna Till Johnson, Data Communications

Heavy-Duty Web Servers

BYTE Lab Produt Report

A Scalable HTTP Server: The NCSA Prototype

Eric Dean Katz

Robert McGrath

Next-Generation Servers

BYTE Lab Produt Report

Crunch Time for Overloaded Internet Servers

Brantley Coile

Measuring the performance of HTTP Deamons

Robert E McGrath

Performance of Several Web Servers Platforms

Robert E McGrath