PHP - o curl roda de forma assíncrona no meu sistema? [fechadas]

1

Estou criando um aplicativo da web. Eu tenho um banco de dados de livros indexados em ElasticSearch e API REST escritos em PHP.

No aplicativo, há uma caixa de pesquisa, onde eu digito um nome do livro e o script JS chama a solicitação de pesquisa que executa uma solicitação de curl com a consulta de pesquisa para o ElasticSearch.

O problema é que, quando o usuário digita rápido, há muitas solicitações. Ele começa a desacelerar e, apesar de normalmente uma única solicitação durar cerca de 200ms, ela vai até 5-10s, o que é muito longo. Eu poderia executar menos solicitações, mas quero esse feedback instantâneo.

Então, eu pergunto - será que o núcleo da onda no meu servidor executa apenas uma solicitação de cada vez, mesmo que elas sejam chamadas em solicitações PHP separadas ou é outra coisa?

    
por Michal Artazov 23.05.2014 / 19:24

2 respostas

3

Resposta curta é não, não é assíncrona. A resposta mais longa é "Não, a menos que você mesmo tenha escrito o backend para fazer isso".

Se você estiver usando o XHR, cada solicitação terá um thread de trabalho diferente no back-end, o que significa que nenhuma solicitação deve bloquear qualquer outra, bloqueando o processo de batida e os limites de memória. Enquanto o XHR apresenta uma interface baseada em eventos, ainda é uma requisição HTTP ao vivo sendo manipulada de forma síncrona pelo navegador (você só recebe 1 thread em js). O backend php também faz chamadas curl de forma síncrona, não retornando resultados para a solicitação http do seu XHR até que a chamada curl termine. Agora, você pode configurar o seu javascript para pesquisar resultados, mas como o seu tempo de vida é de < 3-5 segundos, não vale a pena.

Se você estiver usando websockets, terá que nos informar. Um determinado websocket está vinculado a um processo no backend, mas você pode fork / thread / fazer qualquer coisa nesse processo. Ele também permite que você envie eventos diretamente ao navegador sem que o cliente inicie uma solicitação. Isso poderia ser assíncrono, mas se a lentidão estiver em seu back-end, isso não ajudará a mudar para um design assíncrono.

Realisticamente, você deve ter o seu cliente javascript aguardando para emitir a próxima pesquisa até a última pesquisa retornar. No verso, para evitar o DOS, se um único cliente começar a enviar muitas solicitações de pesquisa de conclusão, comece a eliminar as solicitações com HTTP 429 e manipular 429 respostas em seu JS para fazer backoff incremental e tente novamente mais tarde, se apropriado.

Outra coisa que você definitivamente deve fazer é definir o tempo limite da solicitação em curl para algo muito mais baixo, para que o tempo limite seja apropriadamente. Se os dados da pesquisa forem úteis apenas por dois a três segundos, o tempo limite da solicitação de curl deverá ser o mesmo. Se seu backend for inteligente o suficiente, ele interpretará uma conexão fechada para significar "pare de procurar" e esperamos que você pare a perda de recursos a tempo de outro processo usá-los.

    
por 24.05.2014 / 00:53
2

Do jeito que eu entendo, você tem um servidor web, que executa algum script que pode ser usado para preenchimento automático. Este script executa uma consulta em outro servidor usando cURL.

Primeiro, para responder à sua pergunta: seu servidor da Web, com toda a probabilidade, pode executar vários processos PHP em paralelo, e como o cURL é chamado pelo PHP, ele também será executado em paralelo. Você não disse qual servidor você executa, mas a maioria suporta isso.

No entanto, parece que sua configuração é bastante intensiva em rede: cada pressionamento de tecla gerará uma solicitação para seu servidor, o que gerará uma solicitação para o outro servidor. Se o seu servidor não tiver recursos, ou se o outro servidor tiver um limitador de taxas, você terá um desempenho ruim. Talvez armazene em cache os resultados em seu servidor da Web (para que você não precise se enganar com tanta frequência) ou faça seu Javascript aguardar alguns milissegundos para que as pessoas mais rápidas não acionem muitas solicitações.

    
por 23.05.2014 / 22:52