Por que o APC (ou similar) causa problemas de desempenho para hospedagem compartilhada?

Question

Estou usando hospedagem compartilhada e não posso ativar o APC. Havia um tópico sobre esse aqui e o único motivo sugerido foi para segurança (php-cgi vs mod_php). Eu perguntei ao host, e eles disseram que era devido a razões de desempenho, especificamente que o I / O traria a caixa para baixo. Eu realmente não entendo isso - certamente com um cache de opcode de memória compartilhada, haveria menos I / O? Basicamente, se eu estava montando uma empresa de hospedagem compartilhada (não que eu pudesse!) Eu teria pensado que faria todo o sentido usar um cache (se a segurança permitisse) para melhorar o desempenho de todos os clientes.

Alguém pode lançar alguma luz sobre isso para mim? TIA

    

Answer 1

Eu diria que a APC em planos de hospedagem compartilhada geralmente não é uma boa idéia.
A resposta da sua hospedagem está certa, mas essa não é a única razão.

Quando você recebe uma hospedagem compartilhada, deve estar ciente de que não é a única pessoa que está usando o servidor em que seu site está hospedado. Dependendo do servidor da empresa de hospedagem, pode haver 300 (ou mais) clientes que também hospedam seus sites nessa máquina.

Muitas vezes, esses sites têm MUITOS arquivos php. Por exemplo, um site com joomla 1.6 tem arquivos ~ 3000 php (~ 10mb) (inclui o site e o painel de administração). Imagine que todos esses 300 clientes estão usando a plataforma Joomla e os sites são

1. visitou com muita frequência
2. Gerar carga média do servidor

Isso significa que todos esses clientes terão ~ 900000 arquivos a serem armazenados em cache - ~ 3000mb de RAM será usado apenas para o cache dos arquivos php. Como você sabe no APC, também é possível armazenar "Entradas do cache do usuário", onde normalmente é possível armazenar configurações ou objetos serializados. Eu não posso dizer o quanto a RAM vai lá porque depende do que você armazena, mas digamos 50-100mb extras.

Por enquanto, usamos cerca de 3,1 GB de RAM.
Agora adicione alguma RAM necessária para os serviços básicos executar - Apache, FTP, PHP, MySQL, PostgreSQL, SendMail e ferramentas de backup do servidor. Você provavelmente vai acabar em algum lugar perto de 5-6GB de RAM que será quase permanentemente em uso.

Os outros problemas com a APC surgem quando você faz cache - todos podem ver o que você armazenou em cache (até onde eu sei). Então você provavelmente precisará criptografar o que você armazena - isso exigirá mais CPU porque você estará criptografando / descriptografando o tempo todo. Além disso, se alguém limpar acidentalmente todos os arquivos / entradas de usuário em cache, o servidor ficará louco ao tentar fazer o cache novamente.

A linha de fundo é que nenhum administrador de sistemas passará por todas as dificuldades no * ss para ativar e suportar o APC. Isso também não é um benefício para a empresa. Eles preferem ter mais 300 clientes pagando-lhes dinheiro do que negociando com a APC e imaginando se o servidor não vai cair ou algo não vai dar errado a qualquer momento.

Uma solução melhor seria se o cliente obtivesse um servidor dedicado (gerenciado). Dessa forma, o cliente será o único que hospedará um site nesse servidor e poderá solicitar o suporte para instalar o que quiser no servidor. Isso será muito mais fácil e salvará o clietn, o sistema de administração e a empresa de hospedagem de cabelos brancos:)

Espero que isso ajude você a entender um pouco melhor por que o APC não está incluído nos hosts compartilhados.

    

Answer 2

Por: link

apc.mmap_file_mask string
If compiled with MMAP support by using --enable-mmap this is the mktemp-style file_mask to pass to the mmap module for determining whether your mmap'ed memory region is going to be file-backed or shared memory backed. For straight file-backed mmap, set it to something like /tmp/apc.XXXXXX (exactly 6 Xs). To use POSIX-style shm_open/mmap put a .shm somewhere in your mask. e.g. /apc.shm.XXXXXX You can also set it to /dev/zero to use your kernel's /dev/zero interface to anonymous mmap'ed memory. Leaving it undefined will force an anonymous mmap.

Se usar o backup de arquivos, isso aumentaria sua IO, dependendo da quantidade de tráfego que chega ao servidor.

    

Answer 3

Isso eliminaria o desempenho de qualquer host compartilhado, a menos que você tenha memória suficiente para manter todos os arquivos PHP carregados na memória. Quando você tem um monte de usuários tentando armazenar em cache arquivos que podem não ser comumente atingidos, o servidor vai começar a trocar, o que vai matar o desempenho de tudo naquela máquina.

    

Answer 4

De acordo com o link , o cache é liberado quando a memória está cheia e se o ttl é 0. Se não for definido como zero, ele usará um mecanismo LRU (Least Recently Used).
Parece-me que é sempre benéfico usar o APC.

    

Answer 5

O @tftd declarou as principais razões para não ativar o APC, o Memcached etc em hospedagem compartilhada. Mas um caso de uso pode surgir se o seu servidor compartilhado não for realmente compartilhado, mas usado apenas pelos seus próprios projetos (ou clientes de web design / desenvolvimento e se você não estiver dando acesso FTP / painel), então esse servidor ainda pode se beneficiar da APC / Memcached / etc.

De qualquer forma, eu imaginava que o problema de E / S dependesse da RAM disponível para a APC, já que ela tentaria constantemente invalidar algumas entradas e armazenar em cache novas entradas se a RAM disponível fosse baixa ou se o número de sites / Os arquivos PHP são muito altos (um caso comum em hospedagem compartilhada). Isso não deve ser um problema se houver RAM suficiente e você estiver de olho no apc.php (página de informações do APC).

Além disso, o benefício da APC seria melhor em sites de tráfego moderado / alto, já que o armazenamento em cache de arquivos PHP raramente visitados não importaria muito.