Conexão de auto-retorno via servidor de travamentos de tamanho getimage do PHP (CMS do Magento)

Question

Conseguimos rastrear um problema que está travando nosso servidor NGINX executando o Magento até o seguinte ponto:

Informação de fundo: O Magento Backend tem uma função CMS com um editor WYSIWYG. Este editor carrega algumas imagens através de um controlador em magento (cms / directive).

Quando definimos o nível de error_log do NGINX para info, obtemos as seguintes linhas (quebra de linha inserida para melhor legibilidade):

2012/10/22 18:05:40 [info] 14105#0: *1 client closed prematurely connection, 
  so upstream connection is closed too while sending request to upstream, client: 
  XXXXXXXXX, server: test.local, request: "GET 
  index.php/admin/cms_wysiwyg/directive/___directive/BASEENCODEDIMAGEURL,,/ 
  HTTP/1.1", 
  upstream: "fastcgi://127.0.0.1:9024", host: "test.local" 

Ao verificar o código no depurador, a chamada a seguir nunca retorna (em ´Varien_Image_Adapter_Abstract :: getMimeType () '

# $this->_fileName is http://test.local/skin/adminhtml/base/default/images/demo-image-not-existing.gif' 
# $_SERVER['REQUEST_URI'] = http://test.local/admin/cms_wysiwyg/directive/___directive/BASEENCODEDIMAGEURL

list($this->_imageSrcWidth, $this->_imageSrcHeight, $this->_fileType, ) = getimagesize($this->_fileName);

As solicitações de nome de arquivo são

• um URL para o mesmo servidor que está solicitando o script
• um link para um .gif estático que não existe.

URL da amostra:

http://test.local/skin/adminhtml/base/default/images/demo-image-not-existing.gif

Quando a linha acima é executada, qualquer solicitação subseqüente ao servidor NGNIX não responde mais. Depois de esperar por cerca de 10 minutos, o servidor NGINX inicia as solicitações de resposta novamente.

Eu tentei reproduzir o erro com um script de teste simples que só chama getimagesize() com a URL fornecida - mas isso não falha. Simples leva a uma exceção dizendo que a URL não pôde ser carregada (o que é bom, pois a URL está errada)

    

Answer 1

Teoria atual:

NGINX / PHP O FCGI possui um número limitado de processos que pode manipular. O editor CMS WYSIWYG dispara em torno de 5 solicitações paralelas na ação cms_wysiwyg/directive que o NGINX tenta concluir. Digamos que o NGINX possa lidar com apenas 5 solicitações paralelas: agora, o NGINX faz uma solicitação adicional dentro de uma dessas solicitações em execução, o que obviamente não pode ser atendido porque os slots estão cheios. Os slots também não podem ser liberados, porque o preenchimento de uma solicitação depende de fazer uma solicitação adicional.

Soluções possíveis:

• Aumentar o número de slots
• Permitir que as solicitações falhem mais cedo quando os slots estiverem cheios

Answer 2

Eu quase tive o mesmo problema aqui. Depois de visualizar um bloco CMS contendo uma imagem enviada, a configuração completa do php / php-fpm não respondeu.

O problema acabou sendo uma chamada para getimagesize (no meu caso em torno da linha 72 em lib / Varien / Image / Adapter / Gd2.php). Embora o arquivo de imagem em questão estivesse localizado no próprio site, o parâmetro para getimagesize era um URL HTTP. Devido a uma estranha configuração de firewall, o servidor não pôde contatar a si mesmo via HTTP, então solicite a interrupção e, por motivos desconhecidos, o php-fpm parou de atender às solicitações.

Finalmente, o nginx perdeu a paciência e registrou um erro de tempo limite.

Depois de permitir que o servidor faça solicitações HTTP para si mesmo, os erros de tempo limite desapareceram.

Ainda estou confuso por que o Magento acessaria um arquivo local via HTTP, mas provavelmente era a maneira mais fácil de suportar imagens externas no editor wysiwyg.

(Magento 1.8.1.0)