Exemplo em PHP

O memcached pode ser acessado de muitas linguagens de alto nível, como C/C++, Java, Python, PHP, e até .NET. Abaixo, um exemplo em PHP.
Antes do memcache, uma página poderia ter uma consulta do seguinte tipo:

<?php
// A query SQL está abreviada, apenas como exemplo
// Digamos que essa consulte demore cerca de 1 segundo
// para ser completada
$sql = "SELECT * FROM tabela INNER JOIN ......";
$res = pg_query($sql);
$arr = pg_fetch_all($res); // array com todos os resultados
?>

Com esse código, a cada acesso na página, teremos uma consulta de 1 segundo feita ao banco de dados. Muitas vezes, a consulta será exatamente a mesma. Modificando a consulta para uso do memcached, teríamos algo assim:

<?php
// Conecta ao memcached
$mc = new Memcache;
$mc->addServer('ip.do.servidor');
 
$sql = "SELECT * FROM tabela INNER JOIN ......";
$cache = $mc->get(md5($sql)); // Usamos o md5() da query como chave
 
if ($cache === false) {
    // Resultado não está no cache
    $res = pg_query($sql);
    $arr = pg_fetch_all($res);
    $mc->set(md5($sql), $arr);
}
else {
    $arr = $cache;
}
?>

Pelo exemplo acima, temos algumas modificações. Primeiramente conectamos ao memcached. A chamada a addServer() pode ser feita múltiplas vezes, caso existam vários memcached rodando em máquinas separadas. Pode ser dado um “peso” pra cada servidor também, de acordo com a memória disponível em cada um.
Logo em seguida, é feita a verificação no memcached se o resultado da consulta já está lá. Como chave, usei o hash md5 da consulta, pra gerar uma identificação única. O método get() pode retornar false, caso a chave não esteja no memcached, ou retornar o objeto que foi guardado.
A checagem é simples. Se o get() retornou false, então o sistema faz a consulta como já fazia antes, e no fim guarda o resultado no memcached, pra agilizar as próximas consultas. E caso não tenha retornado false, temos já o resultado da consulta diretamente. Ao fim do bloco if, teremos, de uma forma ou de outra, o resultado da consulta em $arr.
A diferença é que rodando a consulta no banco, o tempo será de cerca de 1 segundo (tempo que estimamos para a execução da consulta), e pegando o resultado direto do memcached, a consulta demorará algo da ordem de milissegundos para ser completada.

Problemas

Um dos problemas clássicos em qualquer abordagem que use cache é como saber se as informações em cache ainda estão atuais. Com o memcached, isso não é diferente. Existem algumas formas de se lidar com o problema.
A primeira delas, mais simples, e que pode ser usada livremente caso não seja de suma importância que os dados estejam atuais, é mexer no tempo em que a informação ficará no cache. O tempo pode ser especificado na chamada ao método set(), da seguinte forma:

<?php
$mc->set(md5($sql), $arr, MEMCACHE_COMPRESSED, 60);
?>

Temos neste exemplo todos os parâmetros para a chamada de set(): a chave, o objeto a ser guardado, uma flag (pode ser usado MEMCACHE_COMPRESSED, que indica que o objeto será comprimido para ocupar menos espaço, ou 0 pra indicar que deve ser guardado sem compressão), e por último o tempo de vida do objeto, no caso, 60 segundos.
Ou seja, caso não haja problema das informações permanecerem desatualizadas por 60 segundos no máximo, essa abordagem pode ser usada.
Caso a informação tenha que estar sempre atualizada, a forma de tratamento terá que ser outra. O memcached possui método para apagar o objeto associado a uma chave. Tendo a chave, basta usar:

<?php
$mc->delete('chave');
?>

e a entrada que existia no memcached para aquela chave será invalidada.
A idéia, nesse segundo caso, é justamente localizar no código todos os pontos que modificam o banco de dados de forma que possa alterar o resultado da consulta feita, e adicionar código para invalidar o cache nesses pontos. Assim, quando for feita a consulta no memcached, caso alguma informação tenha sido modificada, a entrada correspondente no memcached já terá sido apagada, e a chamada a get() retornará false naturalmente.
É claro que essa segunda abordagem dá muito mais trabalho, por isso a sugestão de se usar a primeira delas nos casos em que pode ser usada. Lembre-se que em um site com 100 acessos por segundo, um tempo de vida de 60 segundos evitará 5999 consultas ao banco (a primeira será feita e guardada).

Mais informações

O site do projeto tem um Wiki que responde a maior parte das dúvidas que se pode ter, em relação a instalação e ao uso.
No caso do PHP, as funções são bem documentadas na parte do manual sobre memcache.
Eu uso em produção o memcached, com 2 servidores, um com 768mb de memória disponíveis para o memcached e outro com 256mb. Dei pesos 3 e 1 respectivamente, para que um objeto tenha 3 vezes mais chance de cair no primeiro servidor. A configuração está bastante satisfatória, e o banco de dados agradece.

Artigos relacionados

• Evitando SQL injection em PHP
• Otimização: imagens inline
• Otimização de sites, parte 3 – Cache
• Otimização de sites, parte 2 – Compressão
• Otimização em PHP, parte 1: Minify
• Problemas com acentuação?
• O limite de 4 (ou 3?) Gb de memória

<img src="imagem.png" />

ou então, podemos carregá-la como imagem de fundo de um elemento qualquer usando CSS:

.classe { background-image:url(imagem.png); }

Um dos problemas em páginas que possuem muitas imagens é que cada imagem requer a abertura de uma nova conexão HTTP, e com a limitação de 2 conexões por host (é uma restrição dos navegadores que seguem a especificação HTTP), o tempo de carga da página pode acabar crescendo bastante.

A lógica

Uma solução para este problema é ao invés de carregar as imagens externas, colocá-las diretamente dentro da página, seguindo a mesma lógica que já usamos com CSS. Por exemplo, podemos especificar uma folha de estilo externa:

<link rel="stylesheet" type="text/css" href="arquivo.css" />

ou então podemos colocar os estilos inline:

<style type="text/css">
.classe1 { font-color:#f00; }
#id2 { width:200px; }
</style>

Codificando a imagem

Até aí, tudo bem, afinal CSS é texto, e texto entra bem dentro de uma página. Mas como colocar uma imagem dentro de uma página, uma vez que a imagem é binária?
Simples! Primeiro, codificamos a imagem de binário para ASCII usando a codificação base64. Existem várias formas de se fazer isso, e boa parte das linguagens de programação disponibiliza funções para fazer esta codificação. Por exemplo, em PHP, podemos fazer:

<?php
print base64encode(file_get_contents("arquivo.png"));
?>

A saída disso é algo mais ou menos assim:

iVBORw0KGgoAAAANSUhEUgAAAxYAAAAKCAAAAAAMKZcGAAAACXZwQWcAAAMWAAAACgALWq6
YAAAAOklEQVRYw+3TsQ0AIAwEMZT9F4Uh8vTUFCDZM9zV6nyt08kMXOypBnCwBdgCbAG2AF
uALcAWYAt4xQZXmxLmG7UZ3wAAAABJRU5ErkJggg==

Pronto, já temos a representação codificada da imagem.
Para que a saída coubesse na tela, quebrei a saída em 3 linhas. A saída real é toda em uma só linha, mas como veremos adiante, tanto faz, pois podemos usar quebras de linha.

URLs do tipo “data”

Antes de colocarmos a imagem dentro da página, precisamos ver como funcionam as URLs do tipo “data”. A URL segue o seguinte formato:

data:[<tipo MIME>][;charset="<charset>"][;base64],<dados>

onde:

• tipo MIME é o tipo do arquivo que vamos colocar, no nosso caso, image/png;
• charset é a codificação utilizada, para o caso de arquivos texto (não usaremos no nosso exemplo).
• base64 é a codificação utilizada. Se for omitida, o navegador entenderá que estamos usando US-ASCII, e no caso de imagens, não vai dar certo;
• e por último, dados contém a string com o arquivo codificado (aquela sequencia grande de caracteres ali de cima). A string pode ser quebrada com espaços ou quebras de linha.

Juntando tudo

Pois bem, agora que temos a representação codificada da imagem e já sabemos usar URLs do tipo “data”, podemos colocá-la diretamente na página, usando a própria tag img:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAxYAAAAKCAAAAAAMKZc
GAAAACXZwQWcAAAMWAAAACgALWq6YAAAAOklEQVRYw+3TsQ0AIAwEMZT9F4Uh8vTUFCDZM9zV6n
yt08kMXOypBnCwBdgCbAG2AFuALcAWYAt4xQZXmxLmG7UZ3wAAAABJRU5ErkJggg==" />

Ou então uma regra de CSS, da seguinte forma:

.classe { background-image:url(data:image/png;base64,iVBORw0KGgoAAAANSUh
EUgAAAxYAAAAKCAAAAAAMKZcGAAAACXZwQWcAAAMWAAAACgALWq6YAAAAOklEQVRYw+3TsQ0
AIAwEMZT9F4Uh8vTUFCDZM9zV6nyt08kMXOypBnCwBdgCbAG2AFuALcAWYAt4xQZXmxLmG7U
Z3wAAAABJRU5ErkJggg==); }

É claro que usar esta técnica, como quase tudo na vida, tem várias vantagens e desvantagens.

As vantagens

Temos várias vantagens em usar um esquema deste tipo:

• Suporte na grande maioria dos navegadores modernos: Firefox, Opera, Safari, Konqueror e Chrome;
• Antes de mais nada, estamos diminuindo o número de requisições HTTP, e consequentemente, evitamos o tráfego associado à requisição (cabeçalhos HTTP);
• Como a imagem está inline, conseguimos “fugir” do limite de 2 conexões por host, já que estamos evitando a abertura de novas conexões;
• Para imagens pequenas, temos um ganho real em bytes transferidos, pois embora a imagem codificada em base64 fique maior, estamos evitando de enviar os cabeçalhos HTTP (que somam em média 200 bytes).
• Conexões seguras (que usam https) só mostram o “cadeado” fechado se todos os elementos externos forem carregados através de https também. E o overhead associado a uma conexão https é bem maior que o de uma conexão http normal. Com a imagem inline, ganhamos mais um pouco.

As desvantagens

Temos várias desvantagens, algumas contornáveis:

• Internet Explorer até a versão 7 não tem suporte. Só a partir do 8. A forma de se usar para os dois navegadores é usando arquivos CSS separados para cada navegador (ou um pré-processador de CSS que detecte o navegador e dê a saída com o que for suportado);
• Imagem inline em uma página (usando tag img) não são cacheadas pelo navegador. Se usada dentro do CSS, aí sim teremos o cache em ação, pois o navegador irá cachear o CSS;
• Uma imagem codificada em base64 tem seu tamanho aumentado em 33%. Para imagens grandes, é uma perda considerável, mas para imagens pequenas (da ordem de 500 bytes), temos um ganho, pois mesmo com o aumento da imagem, estamos evitando o envio dos cabeçalhos, e podemos sair ganhando na soma;
• Dificuldade de manutenção: se uma imagem é alterada, ela precisa ser recodificada. Existem formas de se automatizar isso.

Um exemplo

A imagem que aparece aqui embaixo está inline, e foi colocada usando uma tag img (a qualidade está baixa pra não ficar muito grande):

Clicando o botão direito na imagem e escolhendo “Exibir imagem” (no Firefox ou em outro navegador que dê suporte), dá pra se ver na barra de endereços a URL usada pra criar a imagem.
E claro, se você não está vendo imagem nenhuma, provavelmente está usando o Internet Explorer. E já passou da hora de passar a usar um navegador decente, que suporta os padrões web, não é?

Artigos relacionados

• Evitando conteúdo duplicado
• Otimização de sites com memcached
• Otimização de sites, parte 3 – Cache
• Otimização de sites, parte 2 – Compressão
• Otimização em PHP, parte 1: Minify

Como o cache pode ajudar?

Nos outros artigos, vimos como diminuir o número de requisições (agrupando vários arquivos em um só) e também como diminuir o tamanho do que é transferido.
Mas… e se não precisarmos fazer todas essas requisições? A grande maioria das páginas de um site tem arquivos em comum, e que não mudam. Imagens estáticas, folhas de estilo CSS e scripts em JavaScript. E após a primeira carga, o navegador já vai ter esses arquivos localmente.
Só nos resta dizer pra ele quando e o que ele pode usar nas requisições seguintes.

Quais as formas de se usar o cache?

Uma vez que o navegador tenha, digamos, uma imagem estática em cache, existem duas formas dele proceder pra saber se o arquivo é atual ou não.
A primeira é fazer uma requisição indicando a data em que o arquivo foi buscado. Essa requisição é feita enviando um cabeçalho “If-Modified-Since”, com a data do arquivo local. Caso o arquivo não tenha sido modificado, o servidor responde com o código 304 (Not Modified) ao invés de devolver o arquivo novamente.
A segunda forma é somente pedir o arquivo caso ele já tenha expirado.
Logicamente a segunda forma é bem mais econômica, pois evita a abertura da conexão.
Porém, temos um problema: como saber se um arquivo já expirou?

O cabeçalho “Expires”

Qualquer arquivo solicitado em uma conexão HTTP pode ter associado um cabeçalho Expires, que indica explicitamente a “data de vencimento” daquele arquivo. Ou seja, até a data especificada, o arquivo é válido e não precisa ser checado novamente. Após isso, o navegador deve considerar o arquivo como expirado, e solicitar novamente.
Então, para arquivos estáticos, podemos colocar uma regra dizendo que a data de vencimento dele é em um futuro distante. Isso pode ser feito, em um servidor Apache, com uma regra semelhante a esta:

ExpiresActive On
ExpiresByType image/gif "access plus 5 years"
ExpiresByType image/jpeg "access plus 5 years"
ExpiresByType image/png "access plus 5 years"
ExpiresByType text/css "access plus 5 years"

Neste exemplo (que utilizo aqui neste site), estou indicando explicitamente que arquivos do tipo GIF, JPEG, PNG e CSS tem validade de 5 anos da data do download. Antes disso, o navegador pode assumir que o conteúdo é atual e utilizá-lo.
Deixei o JavaScript de lado porque atualmente não estou utilizando nenhum script neste site. Caso queira adicionar na lista, basta duplicar uma das linhas, usando o tipo text/javascript.
Após o primeiro acesso, todas as imagens e folhas de estilo serão cacheadas, e o navegador não irá solicitá-las novamente. Isso dá um bom ganho de desempenho, pois o número de requisições necessárias para carregar as páginas subsequentes (e o correspondente tamanho em bytes) cai consideravelmente.

O resultado

Tomando como exemplo a página inicial deste site, e testando com um navegador com o cache completamente limpo, temos, para o primeiro acesso 21 conexões, sendo 1 para a página propriamente dita, 3 arquivos CSS externos, e 17 imagens externas.
Em um segundo acesso à mesma página (cliquei no logotipo lá em cima à esquerda), apenas uma única conexão foi aberta, para baixar somente a página em si. Todas as imagens e folhas de estilo já estavam no cache do navegador, e ele “sabe” que elas só vão expirar daqui a 5 anos. Logo, não tem porque verificar se foram alteradas.

Possíveis problemas

Um dos problemas neste tipo de configuração é o que fazer caso se precise fazer uma alteração em uma imagem ou em um arquivo CSS.
Nesses casos, como o navegador não está nem checando, o melhor a fazer é alterar o nome do arquivo, por exemplo, colocando um número contendo a versão ou a data de modificação. Com isso, o navegador irá interpretar o arquivo como algo novo, que ele ainda não possui em cache, e que precisa ser baixado.
Porém, o ganho que se consegue com o uso dessa técnica faz, na minha opinião, valer a pena o esforço. Existem algumas formas de se automatizar o processo de alteração do nome do arquivo, que deixarei para discutir em um outro artigo.

Artigos relacionados

• Otimização de sites, parte 2 – Compressão
• Otimização em PHP, parte 1: Minify
• Otimização de sites com memcached
• Otimização: imagens inline
• Páginas de manutenção

Porém, tão importante quanto minimizar o número de conexões, é ter certeza de que a quantidade de dados transferidos seja sempre a menor possível. Como vimos antes, o Minify já ajuda nesse sentido, pois retira dos scripts e das folhas de estilo caracteres desnecessários como espaços em branco e quebras de linha.

Este artigo não é específico de PHP, pois lida uma camada abaixo, direto no protocolo HTTP. As soluções apresentadas aqui podem ser implementadas diretamente na linguagem, mas ficam bem melhores se implementadas no servidor (Apache, no caso), como demonstrado neste artigo.

Começando com o HTTP 1.1, os navegadores podem especificar formas de codificação aceitáveis para o conteúdo, através do cabeçalho Accept-Encoding. Por exemplo, utilizando:

Accept-Encoding: gzip, deflate

o navegador indica para o servidor web que pode receber o conteúdo solicitado de forma comprimida, utilizando um destes dois métodos (gzip ou deflate). Caso o servidor possa comprimir utilizando uma das formas solicitadas, irá retornar um cabeçalho Content-Encoding, informando a codificação usada, como por exemplo:

Content-Encoding: gzip

A codificação mais popular hoje em dia é o gzip, que é uma especificação aberta e bem documentada pela RFC 1952. A outra codificação (deflate) também pode ser usada, mas é menos popular e menos eficiente que o gzip.

A codificação gzip consegue comprimir conteúdo texto (HTML, CSS, JavaScript, e outros) em aproximadamente 70%. Levando-se em consideração que mais de 90% dos navegadores atualmente em uso suportam esta compressão, é altamente recomendável configurar o servidor web para comprimir arquivos texto.

Para o Apache, dependerá da versão utilizada. O Apache 1.3 utiliza o mod_gzip, enquanto que o Apache 2.x usa o mod_deflate. Como o Apache 1.3 já não é muito utilizado, vou mostrar os exemplos para o mod_deflate.

Devemos levar em conta que somente arquivos texto devem ser comprimidos. Arquivos binários, como imagens, áudio e vídeo em geral já estão em um formato comprimido, e colocar mais compressão em cima, além de não diminuir o tamanho do arquivo (pelo contrário, as vezes até aumenta!), causa também desperdício de CPU para o servidor.

A configuração do mod_deflate em geral é feita especificando quais tipos de arquivo serão comprimidos. Em geral, arquivos texto devem ser comprimidos. Podemos, por exemplo, especificar que alguns tipos devem ser comprimidos utilizando diretivas de Apache como:

SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript text/x-json

A primeira linha liga o mecanismo de compressão do mod_deflate, e a segunda especifica alguns tipos que devem ser comprimidos. No caso, estou informando ao servidor que arquivos tipo HTML, texto puro, XML, CSS, JavaScript e JSON devem ser comprimidos. Alguns navegadores mais antigos podem ter problemas com a compressão gzip, mas felizmente isto é coisa do passado. De qualquer forma, a página com a documentação do mod_deflate mostra como desligar a compressão de acordo com o navegador usado.

Um bom site para se testar se o servidor está configurado corretamente para servir conteúdo comprimido é o mod_gzip Test. Basta colocar a URL do site e clicar em “Test” para saber se o servidor está preparado para servir conteúdo comprimido.

Artigos relacionados

• Otimização em PHP, parte 1: Minify
• Otimização de sites, parte 3 – Cache
• Envio de emails em massa
• Otimização de sites com memcached
• Otimização: imagens inline
• Acessando sites fora do ar
• Páginas de manutenção

Existem alguns fatores que influenciam no tempo de carregamento de uma página:

• Tamanho total dos dados
• Tempo de geração da página
• Número de conexões HTTP necessárias

O tamanho total dos dados é de extrema importância, pois quanto mais dados pra se transferir (páginas, imagens, folhas de estilo, scripts externos, etc), maior o tempo de carregamento de uma página. O tempo de geração também é importante, e este tempo depende de uma programação eficiente e de um banco de dados rápido.

Porém, o número de conexões necessárias é frequentemente esquecido, e é um fator de extrema importância para que uma página seja carregada rapidamente.

Para entendermos o porque, precisamos saber o que o navegador faz quando pedimos para ele abrir uma página.

Primeiramente, é realizada uma consulta ao servidor DNS para se determinar o endereço do servidor que estamos tentando acessar. Esta consulta leva algum tempo, mas normalmente é cacheada pelo navegador uma vez feita. Num segundo passo, temos a primeira conexão, que baixa a página que foi pedida.

Após a busca da página, o navegador analisa sua estrutura, e busca elementos externos necessários, como imagens, folhas de estilo (CSS), scripts, arquivos de Flash, etc etc.

Cada elemento externo a ser baixado exige a abertura de mais uma conexão HTTP (nem sempre… existe pipelining e outras coisas que melhoram isso, mas pra simplificar, vou ignorar por enquanto). Cada conexão, para ser estabelecida, leva um tempo antes da transferência de dados ser iniciada. Este overhead gera um atraso, visto que muitas vezes, dependendo do tamanho do arquivo, o tempo para se estabelecer a conexão chega a ser maior que o tempo para se baixar o arquivo.

Some-se a isso uma regra que diz que navegadores devem abrir no máximo 2 conexões simultâneas por host. Ou seja, se a página possui 30 elementos externos a serem baixados, as conexões serão estabelecidas duas a duas até que os 30 sejam completados. Algo que se pode fazer para melhorar isto é dividir os elementos externos em alguns hosts diferentes, já que a regra manda 2 conexões por host, mas isto fica para mais adiante.

Muitas vezes, uma página possui vários arquivos CSS e vários scripts em JavaScript. Ao invés de utilizar, digamos, 5 tags para se carregar 5 arquivos CSS diferentes, e mais 10 tags para carregarmos 10 scripts externos, não seria muito melhor se pudéssemos abrir apenas duas conexões, e baixar todo o CSS em uma, e todo o JavaScript em outra? E melhor, que ao fazer isto eles já viessem “condensados”, de forma a diminuir seu tamanho?

Pois bem, a idéia do Minify é justamente fazer isto. O Minify é um script em PHP que recebe uma lista de arquivos como parâmetro (CSS ou JavaScript) e “junta” todos eles em um único download (ele faz mais, mas para mais detalhes, veja direto na página do Minify).

Para fazer a instalação, tudo muito simples. Basta descompactar o arquivo na raiz do site, e fazer algumas modificações nas tags. Ao invés de termos:

<script type="text/javascript" src="/js/script1.js"></script>
<script type="text/javascript" src="/js/script2.js"></script>
<script type="text/javascript" src="/js/script3.js"></script>
<script type="text/javascript" src="/js/script4.js"></script>
<script type="text/javascript" src="/js/script5.js"></script>

passamos a ter somente:

<script type="text/javascript" src="/min/?f=/js/script1.js,/js/script2.js,/js/script3.js,/js/script4.js,/js/script5.js"></script>

Ou seja, chamamos somente o “/min/”, e passamos como parâmetro (chamado f) uma lista com os scripts, separados por vírgulas, e o Minify se encarrega do resto. Com o CSS, a mesma coisa. Ao invés de termos:

<link rel="stylesheet" type="text/css" href="/css/style1.css" />
<link rel="stylesheet" type="text/css" href="/css/style2.css" />
<link rel="stylesheet" type="text/css" href="/css/style3.css" />
<link rel="stylesheet" type="text/css" href="/css/style4.css" />
<link rel="stylesheet" type="text/css" href="/css/style5.css" />

teremos somente:

<link rel="stylesheet" type="text/css" href="/min/?f=/css/style1.css,/css/style2.css,/css/style3.css,/css/style4.css,/css/style5.css" />

Apenas usando o Minify, já podemos conseguir baixar o número de conexões HTTP necessárias para se carregar a página inteira, e com isso, diminuir o tempo total.

Um site interessante, que fornece um mapa com todos os elementos do site, assim como o tempo de carregamento de cada um é o Full Page Test do Pingdom. O tempo de cada elemento é dividido em 3: tempo para se começar, tempo para se estabelecer a conexão e a transferência em si. Olhando bem, dá pra perceber que o tamanho das páginas (parte azul da barra) tem uma influência menor do que o número de conexões.

Existem outras técnicas, que podem ser usadas em conjunto com o Minify para melhorar ainda mais, mas ficarão para os próximos artigos da série.

Artigos relacionados

• Otimização de sites, parte 2 – Compressão
• Otimização de sites, parte 3 – Cache
• Agendando eventos no WordPress
• Removendo o “generator” do Wordpress
• Envio de emails em massa
• Escrevendo plugins para o Wordpress
• Otimização de sites com memcached
• Evitando SQL injection em PHP
• Otimização: imagens inline
• Criando CAPTCHAs em PHP
• Pegadinhas no PHP
• Precedência no PHP
• Acessando sites fora do ar
• Páginas de manutenção
• Imprimindo em formulários contínuos em PHP
• XML no PHP com XML_Serializer, parte 2 de 2
• XML no PHP com XML_Serializer, parte 1 de 2
• Envio de emails em PHP
• Validação de dados em PHP
• Segurança no envio de emails em PHP