PHP-FPM e APC para hospedagem compartilhada?

Question

Estamos procurando uma maneira de fazer com que a APC crie apenas um cache por conta / site. Isso pode ser feito com o Fastcgi (última atualização 2006…), mas com o Fastcgid, o APC terá que criar vários caches para múltiplos processos executados pela mesma conta.

Para contornar este problema, estamos analisando o PHP-FPM

O gerenciador de processos PHP permite que vários processos PHP compartilhem um único cache APC.

Mas pelo que li (espero que esteja errado), mesmo que você crie um pool por processo, todos os sites em todos os pools compartilharão o mesmo cache do APC. Isso nos traz de volta ao mesmo problema do Memcached compartilhado: não é seguro!

No site do php-fpm eu li que você pode fazer chroot em php-fpm e definir um UID e um GID específicos por pool ... se esse for o caso, a APC não deve usar esse usuário e não ter acesso a outros pools cache?

Um artigo aqui (em 2011) sugere que você precisaria executar um processo por pool criando vários lançadores em diferentes portas e diferentes arquivos de configuração com um pool por arquivo de configuração:

link

Isso ainda é necessário?

Em caso afirmativo, qual seria o impacto da execução, digamos, 800 processos de php-fpm? Seria principalmente memória? Se sim, como posso descobrir qual seria o impacto da memória?

Eu acho que seria melhor rodar 800 vezes php-fpm e ter contas criando vários caches APC para um único site?

Se, em média, uma conta cria um cache de 50MB e cria 3 caches por conta, o que gera 150Mb por conta, o que gera 120GB…

No entanto, se cada conta usa, em média, apenas 50Mb, isso daria 40GB

Teremos pelo menos 128GB de RAM no nosso próximo servidor, então 40GB será aceitável se a execução de 800 x PHP-FPM não criar uma sobrecarga de mais de 20GB!

O que você acha que é o PHP-FPM a melhor maneira de fornecer cache APC seguro em hospedagem compartilhada com um servidor com uma quantidade razoável de memória?

Ou eu deveria estar procurando outro sistema?

Obrigado!

    

Answer 1

Eu sei o que você está tentando fazer, já que é parte do projeto que estou liderando. Eu já investiguei sobre isso e parece que a única maneira de resolver o problema é usar uma versão modificada do memcached e do apc.

Eu achei que atualmente a APC permitiu salvar dados no memcached, mas descobri que não, então a maneira mais fácil de resolver o problema é hackear o memcached, permitindo que ele tenha diferentes contas com diferentes caches, e talvez um cache diferente. tamanhos e, em seguida, hackear APC também, permitindo consultar memcached para buscar opcodes a partir dele.

O hack do Memcached também seria útil, pois você poderia definir um tempo de expiração para o cache e avaliar o que deveria ser armazenado em cache e o que não deveria: assim, você economizaria mais memória RAM e o usaria apenas sob demanda. Para selecionar a conta que você deseja usar, você usaria a autenticação SASL (que já foi desenvolvida para o memcached) no servidor do memcached, colocando mais segurança nessa configuração.

A implantação do Memcached também seria útil para outras coisas, como o armazenamento em cache, portanto, vou seguir esse caminho.

    

Answer 2

Eu realmente não vejo problema em usar o FastCGI aqui. Explicarei: o APC é necessário para sites com alta frequência de acessos e não é necessário para sites que acessam ocasionalmente.

Assim, com relação à eficiência da memória: você tem vários sites no seu servidor, alguns deles populares e outros não. Você tem pool de processos FastCGI para cada site e o PHP gerencia seus funcionários (usando o shell do FastCGI com a variável PHP_FCGI_CHILDREN), cada pool FastCGI tem tempo de vida, o cache APC é compartilhado em todos os processos PHP do pool.

Sites populares receberão hits frequentemente e o pool FastCGI não morrerá, o APC permanecerá na memória, um digamos 50MB de cache para todos os funcionários do PHP.

Sites não tão populares ativarão a política de eliminação de FastCGI e os funcionários serão desligados completamente com a memória de liberação de cache da APC. Quando este site for atingido, o pool será reiniciado e o primeiro hit será mais lento. Este modelo combina efetivamente o modo PHP-CGI com baixo consumo de memória e alto uso de recursos com o conjunto de processos PHP-FPM com cache ativo e pronto.

Com o modelo PHP-FPM, você terá que manter pelo menos UM funcionário para cada site, resultando em grande consumo de memória.

ps. Há um remendo de encomenda para o php-fpm mas ainda não o testamos na produção.

    

Answer 3

Eu adicionarei que seu post me ajudou a encontrar um bug onde o cache opcode da APC estava misturando vários arquivos de configuração entre várias instâncias chrooted. Portanto, quando usar conjuntos com chroot com daemons php-fpm separados ainda é uma necessidade, você nunca deve usar vários pools onde o caminho do chroot pode se contrair entre os pools.