Introdução

Apache é a implementação open source de um servidor HTTP. Ele é o webserver mais popular na Internet. Uma pesquisa realizada em 2005 pela NetCraft mostra que cerca de 70% dos sites na Internet rodam sobre o Apache.

Opções de Configuração em tempo de Compilação

Carrege apenas os módulos necessários

O servidor Apache é um programa modular onde o administrador pode escolher entre as funcinalidade que deseja incluir no servidor selecionando um pacote de módukis. Os módulos podem ser compilados estaticamente no binário httpd ou dinamicamente como DSOs(Dynamic Shared Objects). Módulos DSO podem ser compilados quando o servidor for compilado ou poem ser compilados utilizando o apxs para adicioná-los mais tarde. O modulo mod_so deve ser compilado estaticamente no Apache para que o suporte a DSO seja ativo.

Execute o apache apenas com os módulos necessários. Isto reduz o consumo de memória aumenta a performance do servidor. Compilar os módulos estaticamente irá reduzir o consumo de RAM que é utilizado para suportar módulos compilados dinamicamente, mas será necessário recompilar o apache toda vez que um módulo for adicionado ou removido. È aqui que o DSO se torna útil. Uma vez que o modulo mod_so seja compilado estaticamente, qualquer outro módulo pode ser inserido ou removido utilizando o comando LoadModule no arquivo httpd.conf – , mas você terá que compilar os módulos utilizando apxs se ele não foi compilado quando o servidor foi feito.

Escolha o MPM apropriado

O apache vem com uma selação de Módulos Multi-Processadores (MPMs) que são responsáveis por abrir as portas de rede na máquina, aceitando requisições, e despachando processos para cuidar das requisições. Apenas um MPM pode ser carregado por vez.

Escolher o MPM depende de vários fatores, por exemplo se o SO suporta threads, quanta memória está disponível, escalabilidade versus estabilidade, modulos externos,etc .. Sistemas Linux podem escolher entr utilizar um MPM com suporte (worker) a threads ou um prefork sem threads:

O MPM Worker utiliza múltiplos processos. Ele é multi-threaded com cada processo e cada thread cuidando de uma única conexão. Esté é mais rápido e mais escalável e a memória consumida e relativamente baixa. Funciona bem com múltiplos processadores. Porém, o worker é menos tolerante a módulos defeituosos, e threads defeituosas podem afetar todas as outras threads de um processo.

O MPM Prefork utiliza múltiplos processos filhos, cada filho cuidad de apenas uma conexão por vez. Prefork é muito bem gerenciada por processadores simples ou múlitplos, a velocidade é comparável ao worker e é mais tolerante a falhas em modulos e processos que terminam inesperadamente. Mas o consumo de memória é alto, mais tráfego leva a mais consumo de memória.

Opções de Configuração em Tempo de Execução

DNS lookup

A diretiva HostnameLookips habilita a consulta de DNS, então os hostnames podem ser logados ao invés de endereços IP. Isto adiciona latência em cada requisição desde que a consulta do DNS tem que ser completada antes que a requisição seja terminada. Esta opção é desabilitada por padrão no Apache 1.3 e superiores. Deixe isto inativo e utilize programas pós-processamento como o logresolve para determinar os IPs dos logs. Logresolve vem com Apache.

Quando utilizar as diretivas Allow from ou Deny from, utilize endereços IP ao invés de nomes de domínios. Caso contrário uma consulta dupla ao DNS será executada para ter certeza de que o domínio ou host não está sendo spoofado.

AllowOverride

Se o AllowOverride está setado para ‘None’, então o Apache irá tentar abrir o arquivo .htaccess (especificada pela diretiva AccessFileName) em cada diretório que for acessado. Por exemplo:

DocumentRoot /var/www/html
<Directory />
AllowOverride all
</Directory>

Se uma requisição for feita para acessar /index.html, o Apache irá tentar abrir /.htaccess, /var/.htaccess, /var/www/.htaccess, and /var/www/html/.htaccess. Estas tentativas aumentam a latência. Se o arquivo .htaccess for necessário para um diretório, habilite apenas para este diretório.

FollowSymLinks e SymLinksIfOwnerMatch

Se a opção FollowSymLinks estiver setada, então o servidor permitirá que links simbólicos possam ser seguidos neste diretório. Se a opção SymLinksIfOwnerMatch estiver setada, então o servidor permitirá acessar o link apenas se o destino dele bater com o dono do link.

Se a opção SymLinksIfOwnerMatch estiver setada, então o Apache terá que realizar consultas adicionais ao sistema para verificar se os donos coincidem. Chamadas adicionais também são necessárias quando a opção FollowSymLinks NÃO está setada. Por exemplo:

DocumentRoot /vaw/www/html
<Directory />
Options SymLinksIfOwnerMatch
</Directory>

Para uma requisição feita para /index.html, o Apache irá executar lstat() em /var, /var/www, /var/www/html, and /var/www/html/index.html. Estas requisições adicionais também irão aumentar a lantência. Os resultados do lstat não são cacheados, então as consultas irão ocorrer em cada requisição.

Para uma máxima performance, sete FollowSymLinks em cada lugar e nunca sete SymLinksIfOwnerMatch. Ou então, se SymLinksIfOwnerMatch for necessário para um diretório, sete ele para apenas este diretório.

Content Negotiation

Evite utilizar content negotiation para respostas mais rápidas. Se content negotiation é necessário para o site, utilize arquivos type-map ao invés da diretiva Options MultiViews. Com MultiViews, Apache precisa scanear o diretório em busca de arquivos, o que adiciona latência.

MaxClients

O MaxClients seta o número máximo de clientes simultâneos que pode ser suportada por cada servidor. Nenhum processo além do que está definido será aberto. Ele não deve conter um número muito baixo já que as requisições serão colacadas em fila, o que eventualmente irá dar time-out e os recursos do servidor continuarão não utilizados. Setar este valor muito alto irá causar o início de swap e o tempo de resposta irá cair drasticamente. O valor apropriado para MaxClientes pode ser calculado por: MaxClientes = Total RAM / Tamanho Máximo de Processos . O tamanho dos processos para arquivos estáticos é de mais ou menos 2-3MB. Para dinâmicos como PHP, deve ser por volta de 15MB. A coluna RSS de:

# ps -ylC httpd --sort:rss

Mostra a memória física non-swapped utilizada pelos processos do Apache em kilo Bytes.

Se existem mais usuários concorrentes do que MaxClients, as requisições serão colocadas em fila até o número baseado na diretiva ListenBacklog. Aumente o ServerLimit para setar o MaxClients acima de 256.

MinSpareServers, MaxSpareServers, e StartServers

MaxSpareServers e MinSpareServers determina quantos processos filhos devem ser mantidos rodando. Se MinSpareServers for muito baixo e muitas requisições forem iniciadas, então o Apache terá que abrir processos adicionais para atender as requisições. Criar processos filhos é relativamente caro. Se o servidor estiver ocupado criando processos, ele não estará disponível para servir as requisições imediatamente. MaxSpareServers não deve ser muito alto, ele pode causar problemas de recursos desde que cada processo consome os recursos da máquina.

Sete MinSpareServers e MaxSpareServers para um valor com que o Apache não precise frequentemente abrir mais de 4 processos por segundo. (O Apache pode abrir o máximo de 32 processos por segundo). Quando mais de 4 processos por segundo forem abertos, uma mensagem será logada no ErrorLog.

A diretiva StartServers define o número de processos criados na inicialização do Apache. O Apache irá continuar abrir os processos até que alcance o número de MinSpareServers. Não afeta muito a performance já que o servidor não é reiniciado frequentemente. Se existem muitas requisições e o Apache é reiniciado frequentemente, sete este valor para um número alto.

MaxRequestsPerChild

A diretiva MaxRequestsPerChild definie o número de requisições que um processo do servidor irá gerenciar. Depois as requisições MaxRequestsPerChild irão morrer. É definido para 0 por padrão, o que significa que o processo não irá expirar nunca. É apropriado setar este valor para alguns milhares. Isto pode ajudar a previnir vazamento de memória desde que o processo morre depois de servir um número de requisições. Não sete este valor muito baixo, já que criar novos processos causa overhead.

KeepAlive and KeepAliveTimeout

A diretiva KeepAilve permite que múltiplas requisições possam ser enviadas pela mesma conexão TCP. Isto é útil para páginas com muitas imagens. Se o KeepAlive estiver Off, então para cada imagem, uma nova conexão TCP precisa ser aberta.

KeepAliveTimeout determinada quanto tempo deve esperar até a próxima requisição. Sete para um valor baixo, por volta de 2 a 5 segundos. Se for setado para um valor muito alto, os processos ficam amarrados esperando pelo cliente quando eles poderiam ser utilizados para servir novos clientes.

Compressão HTTP & Caching

O servidor utiliza os métodos gzip ou deflate para as respostas payload antes que ele seja enviado para os clientes. Então o cliente descompacta o payload. Não existe necessidade de instalar softwares adicionais no lado do cliente desde que a maioria dos navegadores suporta isto. Utilizar compressão irá economizar banda e irá aumentar o tempo de resposta, estudos mostram que em média o ganho da compressão é de 75%. A compressão pode ser habilitada utilizando módulo mod_deflate. O Payload é compactado apenas se o navegador requisitar a compactação, ou então o conteúdo descompactado será enviado. Um navegador capaz de utilizar o conteúdo compactado envia o seguinte cabeçalho na requisição: “Accept-Encoding: gzip,deflate”. Então o servidor irá enviar o payload compactado e o cabeçalho da reposta é “Content-Encoding: gzip”

O exemplo a seguir utiliza o telnet para verificar os cabeçalhos de requisição e de resposta:

bash-3.00$ telnet www.webperformance.org 80
Trying 24.60.234.27...
Connected to www.webperformance.org (24.60.234.27).
Escape character is '^]'.
HEAD / HTTP/1.1
Host: www.webperformance.org
Accept-Encoding: gzip,deflate

HTTP/1.1 200 OK
Date: Sat, 31 Dec 2005 02:29:22 GMT
Server: Apache/2.0
X-Powered-By: PHP/5.1.1
Cache-Control: max-age=0
Expires: Sat, 31 Dec 2005 02:29:22 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 20
Content-Type: text/html; charset=ISO-8859-1

O module mod_cache pode ser utilizado no lado do servidor, está em produção estável na versão 2.2 do Apache.

Servidor separado para conteúdo estático e dinâmico

Processos do apache para conteúdo dinâmico consome cerca de 3-20MB de RAM. E cresce para acomodar o conteúdo e nunca diminui até que o processo termine. Digamos que um processo cresca até os 20MB para servir um conteúdo dinâmico. Depois de completar a requisição, ele está libre para servir outra requisição. Se vier uma requisição para uma imagem, então esses 20MB de processos está servindo um conteúdo estático que poderia ser executado por um processo de 1MB. A memória é utilizada ineficientemente.

Utilize uma pequena compilação do Apache (com o mínimo de módulos compilados estaticamente) como sendo o servidor front-end para servir conteúdos estáticos. As requisições para conteúdos dinâmicos serão encaminhadas para um apache robusto (compilado com todos os módulos necessários). Utilizar um servidor front-end leve tem a vantagem de que os conteúdos estáticos são enviados rapidamente sem o consumo alto de memória e apenas o conteúdo dinâmico é passado para o servidor robusto.

Encaminhamento de requisições pode ser implementado utilizando os módulos mod_proxy e mod_rewrite. Suponha que exista um servidor apache leve rodando na porta 80 e o robusto na porta 8088. Então a configuração a seguir pode ser utilizada no apache leve para encaminhar todas as requisições de conteúdo dinâmico para o servidor robusto.

ProxyPassReverse / http://%{HTTP_HOST}:8088/
RewriteEngine on
RewriteCond   %{REQUEST_URI} !.*\.(gif|png|jpg)$
RewriteRule ^/(.*) http://%{HTTP_HOST}:8088/$1 [P]

Todas as requisições, exceto as imagens serão encaminhadas para o apache robusto. As respostas são recebidas pelo servidor front-end que as encaminha para o cliente. Todas as respostas aparentam vir de um único servidor.

Conclusão

Configurar o Apache para obter o máximo de performance pode ser traiçoeiro, não existem regras rápidas. Entenda as necessidades do servidor web e experimente com várias opções. Utiliza ferramentas como ab e httperf para medir a performance do servidor. Servidores leves como tux, thttpd também podem ser utilizados como servidores front-end. Se um servidor de banco de dados é utilizado, tenha certeza de que ele está otimizado para que ele não crie nenhum gargalo. No caso do MySQL, mtop pode ser utilizado para monitorar querys lentas. Performance de scripts PHP pode ser melhorada utilizando produtos de cache como o Turck MMCache. Ele elimina o overhead da compilação realizando cache dos scripts em seu estado compilado.

Fonte

• http://www.howtoforge.net/configuring_apache_for_maximum_performance
• http://under-linux.org/wiki/Tutoriais/Apache/Apache-performance

Autor

Escrito por: Vishnu Ram is an MTech. in Communication Systems from IIT Madras. He joined Bobcares in 2003 and has been working for Poornam since then.

Depois de apresentar a configuração do Apache, PHP, APC e Memcached na primeira parte, agora é hora do Nginx. Basicamente, vamos utilizar o Nginx para servir apenas conteúdo estático (imagens, css, javascript, etc), pois ele possui recursos que garantem uma boa performance para este fim, como por exemplo usar o Memcached como cache. Quando ele recebe uma requisição para processar um arquivo PHP, ele “passa a bola” para o Apache, servindo também como um proxy. Fica mais fácil de entender olhando o fluxo abaixo:

                                PHP
requisição --> [Nginx] ------------> [Apache] ---> (PHP + APC)
                  |
                  |
                  |
                  | conteúdo estático
                  | (imagens, js, css, etc)
                  |
            (Memcached)

Após o famoso comando apt-get install nginx, devemos editar os arquivos de configuração e acertar os detalhes para que tudo isso aí em cima funcione corretamente. Vamos começar pelo arquivo /etc/nginx/nginx.conf, onde estão as configurações globais:

Não há muito segredo, principalmente se você já mexeu com os arquivos de configuração de outros web servers, como o Apache. O próximo passo agora é a configuração do virtual server, onde ficam os detalhes mais importantes. O arquivo para configuração do virtual server default é o /etc/nginx/sites-enabled/default:

Após acertar as configurações, reinicie o daemon do Nginx com o comando /etc/init.d/nginx restart. Podemos conferir o benchmark usando o Apache Benchmark:

Fonte: http://www.bragil.net/

A seguir vou detalhar o passo-a-passo resumido da configuração usada, que eu apelidei carinhosamente de NAPALM (sigla para Nginx + Apache + PHP + APC + Linux + Memcached).

Nginx é um servidor web que tem ganhado fama por ser extremamente rápido e também por ser uma excelente escolha para servir conteúdo estático, sendo usado como proxy para servidores de aplicação.

O Apache dispensa apresentações, assim como o PHP.

O APC é uma extensão para o PHP que otimiza o código intermediário e mantém um cache dos dados e do código compilado na memória compartilhada. Isto faz aumentar sensivelmente a performance de aplicações PHP.

O Memcached é um sistema de cache em memória de alta performance, bastante usado por grandes nomes da Internet, como Twitter, Flickr, Wikipedia, Youtube, dentre outros.

Quer performance para sua aplicação PHP? Basta misturar isso tudo!! E o melhor, a configuração é tranquila.

Para começar, instale o Apache 2 e o PHP 5. Não vou abordar a instalação e configuração do servidor Apache 2 + PHP 5, pois basta ir no Google, você encontrará bastante coisa.

Configuração do Apache

Depois do Apache + PHP instalados e configurados, altere a porta onde o Apache receberá as conexões para 8080. No Debian, edite as seguintes linhas do arquivo /etc/apache2/ports.conf para o seguinte:

E altere também a porta na configuração do virtual host:

Isto significa que o Apache deixará de atender as requisições na porta 80 (padrão). Ou seja, usaremos o Apache apenas para processar os arquivos PHP, deixando todo o conteúdo estático (imagens, javascript, css, etc) para o Nginx.

Reinicie o servidor Apache. No Debian, o comando é /etc/init.d/apache2 restart.

Instalação e Configuração do APC

Agora é a instalação do APC. No Debian 5, isso é extremamente simples:

Após instalar, edite o arquivo /etc/php5/conf.d/apc.ini, adicionando as seguintes linhas:

É possível configurar vários parâmetros, consulte a documentação do APC.

Para a nova configuração surtir efeito, reinicie o Apache:

Instalação e Configuração do Memcached

Após a instalação, edite o arquivo /etc/memcached.conf. Geralmente não é necessário mudar muita coisa, a não ser o tamanho máximo da memória para o Memcached (o default é 64 MB). O Memcached usa a porta 11211 por padrão, mas também é possível mudar. O arquivo de configuração vem todo comentado, não há segredo.

Para alterar o tamanho do espaço de memória, altere a linha -m 64 para o quanto for necessário (128, 256, 512, 1024,…). Lembrando que o Memcached só ocupa o espaço de memória que estiver em uso pelo cache, ele não reserva todo o espaço inicialmente. Feita a configuração, reinicie o daemon do Memcached com o comando:

/etc/init.d/memcached restart

Agora só falta o Nginx.

Instalação do Nginx

Adivinhem?

Vamos abordar a configuração em um outro artigo. Até lá, que tal dar uma olhada nos arquivos de configuração do Nginx, em /etc/nginx ? Bons estudos!

Fonte: http://www.bragil.net/

In part one of this series I tested the raw throughput performance of Varnish and Squid.  My results are consistent with all the blogs and comments floating around the blogosphere – Varnish blows away Squid.

Unfortunately, the first series of tests were somewhat uninformative.  Since they only tested the raw performance of serving cached content from memory, it did not mimic a real world scenario of serving cached content as well as fetching content from the backend and caching it.

While we would hope for a primed, full cache, it is unlikely to happen and you will undoubtedly see a decent amount of backend requests from your caching proxy.

A better test of the two proxies would involve a large set of random URLs, but not too random because we want to simulate both cache hits and cache misses.  To accomplish this, I wrote a small PHP script that would take two parameters: total number of URLs to generate and the hostname for those URLs.

Generating a usable URL list

Generating the list is simple.  This script looks like this:

<?php
        ob_start();
        $total = $_GET['total'];
        $host = $_GET['host'];
        for ($i = 0; $i < $total; $i++) {
                // generate random numbers
                srand(time());
                $random = mt_rand(10, 40);
                $random2 =  mt_rand(1, 100);

                if (substr($random2,0,1) > 1) {
			$as="?as=$random2";
		} else {
			$as = "";
		}
                echo "http://$host/varnish/gen/$random$as\n";
                flush(); ob_flush();
        }
        echo "http://$host/varnish/gen/$random$as";
?>

All this does is create a long list of URLs.  I used PHPs output buffering mechanisms to flush the buffer which is necessary when creating large URL lists so that you don’t wait forever.  Maybe it could have been written better but I don’t care – that wasn’t the point of this test.

The URLs that are created are in the format of:

http://host/varnish/gen/50?as=100

http://host/varnish/gen/50

This URL is mapped to another PHP file that simply generates dummy data of the size specified in the URL.  In the above cases, the files would be 50Kb large.  The query parameter “as” is just a useless piece of information that is meant to tell the proxy to cache it.  If the “as” query parameter does not exist, the proxy will forward the request to the backend and not cache it.  Its a simple way to generate cacheable and non-cacheable URLs.

To generate the list and store it in a local file, I used this command:

curl http://192.168.165.101/varnish/makelist.php?total=10000&host=192.168.165.104:8080
	> urls-10k.txt

Verify the results of the script

For your own sanity, make sure that the script did in fact generate a list of URLs that suits your needs.

Count the amount of URLs generated:

cat urls-10k.txt | wc –l

(yes, I know it creates one extra URL … Its fine by me.)

Count the amount of cacheable URLs containing the “as” query parameter:

cat urls-10k.txt | grep as | wc –l

Count the amount of unique cacheable URLs:

cat urls-10k.txt | grep as | sort | uniq | wc –l

Running the tests

In part one I used ApacheBench to load the servers but for these tests, I used Siege and http_load which both allowed me to load URLs from a file.

I started with Varnish using the following commands:

curl http://192.168.165.101/varnish/makelist.php?total=100000&host=192.168.165.104:8080
	> urls-100k.txt

http_load -parallel 10 -fetches 100000 urls-100k.txt
http_load -parallel 25 -fetches 100000 urls-100k.txt
http_load -parallel 50 -fetches 100000 urls-100k.txt
http_load -parallel 100 -fetches 100000 urls-100k.txt
http_load -parallel 200 -fetches 100000 urls-100k.txt
http_load -parallel 400 -fetches 100000 urls-100k.txt

In between each http_load command, I restarted the Varnish service so that each test ran with an empty cache.  When I was done with the Varnish tests, I ran the same tests against Squid using the same commands above.

The results

The results of these tests represent the typical web application much better than the original tests did.

This first graph shows the average time for the proxy to accept a connection.  As concurrency goes up, it is expected that the time to connect would go up too.  Squid suffers more than Varnish does, but the difference is negligible.

The second graph is much more interesting.  As concurrency goes up, the Time-To-First-Byte for Squid goes up very sharply while Varnish holds its ground and remains very quick around 25ms.

This third graph shows another interesting behavior.  As concurrency goes up, Varnish begins to even itself out at just under 800 fetches per second while Squid peaks at around 1100 fetches per second with around 50 concurrent connects and then sharply drops off as concurrency goes up.

Conclusion

Squid versus Varnish is just another holy war that may never end.  The tests that I have performed have been very helpful for me and my team but your results may vary.  Of course, there are many more things to consider and I plan to write about some of the major differences between Squid and Varnish.

My results show that in raw cache hit performance, Varnish puts Squid to shame.  In real world scenarios I found that Squid can hold its own when dealing with small amounts of traffic, but it’s performance drops off very sharply as it begins to handle more connections. Varnish handles them without a sweat, as it was designed to do.

My next blog post will detail the differences between Varnish and Squid’s architecture, features, and the reasons I am pushing for Varnish in our environment.

Edit:

Some people are complaining in comments on Reddit and HackerNews that I have not provided any information about the hardware or operating system for my tests.  This information was posted in Part one of this post.

Fonte: http://deserialized.com

Typical web applications require dozens of SQL queries to generate a single page.  When your application is serving over 1,000,000 pages per day, you quickly realize that the performance bottleneck is your database.  The typical answer to slow database queries is “just use memcached!”  Memcached and other data caches can only take you so far.  This is where reverse proxies come in.  There are a handful of them out there, including Nginx, Perlbal, Squid and Varnish.  Which to use is up to you.

Deciding what is best for you

Assuming that you have taken a step back and really analyzed your problem first, the next step is to analyze the possible solutions.  For us, Varnish seems like the best option with Squid close behind.  To be fair, I’ve set up a test server with both Varnish and Squid running.  I’ll use ApacheBench to generate load and requests.

I’ve analyzed our pages to see what the typical page size is and recorded the average page sizes for 5 different page types.  They range from around 10KB to 35KB (gzipped).  For my test, I’ll be benchmarking with 10KB, 15KB, 20KB, 30KB, 40KB, and 50KB files to get a good range of different size requests.

To test under different load capacities, I’ll use ApacheBench to generate loads with different amounts of concurrent users ranging from 10 to 400.

The test

I’ll be using two identical machines on the same local class C network to eliminate (as much as possible) network latency.

The machines look something like this:

• Pentium 4 3GHz (8KB Level 1, 512KB Level 2)
• 2GB (4×512 DDR 400MHz)
• 120GB ATA Western Digital Caviar WD1200JB
• CentOS 5

(I don’t have more information than that.  Suffice to say that it is a few years old and not very powerful)

I am using Varnish 2.04 and Squid 2.6.STABLE21.  There are newer versions of Squid but i am using this version because the 3.x branch is missing features found in the 2.x branch and I have read several reports of 2.7 crashing, etc.

The command to run the load test looks something like this:

ab –c concurrent_users –n total_requests “url”

This will let you specify how many concurrent users to run and how many requests to make.  I have the proxy servers running on ServerA and I run the benchmark from ServerB.

The results

In general, Varnish seems to perform twice as well as Squid does.  In every test, Varnish serves nearly 2x more requests per second and has half the average response time.

Here are the graphs of the above data for easier visualization:

Something is wrong here

These are simply benchmarks and are not meant to represent real world scenarios for a few reasons.  Most importantly, this test takes place on a local network that goes through one router.  Running this test on a local network does not take into consideration the typical network latency you would find across the internet.

Secondly, this test only illustrates the raw speed of serving up cached content which isn’t a typical real world scenario.  To really test the overall performance of both of these, we need to simulate the three major steps of a reverse proxy:

1. Forwarding a request to a backend server
2. Physically caching it (memory or disk)
3. Serving the cached data

Testing any of these three steps is good, and shows the raw performance of that function but it doesn’t give us a general overview of the overall performance.

Next Steps

I need to come up with a way to generate load on the server such that it represents the typical flow of requests that we would normally see on a server.  I am running this on a test server, not against production data, so if anyone has an idea of how I can do this, please do let me know.  The results of this test will be Part 2 of this post.

Additionally, please let me know if you spot inefficiencies in my testing methodology. I don’t claim to be a load testing expert so any advice you can offer is appreciated.

Fonte: http://deserialized.com