Recebendo falha de E / S no servidor de análise

Question

Estou usando o parse server como um BAAS para meu aplicativo Android. Tudo está funcionando como um charme, exceto quando uso o aplicativo como um único usuário intensamente I.E. se eu enviar várias solicitações em um período muito pequeno (atualizando os dados muitas vezes rapidamente) do meu cliente Android para o servidor de análise, o servidor congelará. e recebo uma mensagem da minha função de nuvem dizendo: "falha de E / S".

Não estou recebendo nenhuma informação no meu arquivo parse.logs relacionado ao problema além da mensagem "falha de E / S" no lado do cliente Eu ficaria mais feliz em entender a causa deste problema. e eu como resolver isso.

Configuração do ambiente

servidor

versão do servidor parse: 1.17.3

Sistema Operacional: Ubuntu (imagem Bitnami)

servidor remoto? AWS

Banco de dados

Versão do MongoDB: v3.0.9

Localhost

    

Answer 1

Existem algumas coisas que você vai querer ver.

1) Você provavelmente está usando uma instância t2.micro. São adequados para desenvolvimento / prototipagem, mas não produção. Toda a série t é, na verdade. Encontre o uso geral um, pelo menos. Porém, dependendo do seu caso de uso, outros podem ser melhores.

2) Otimize seus pedidos. Quando você atualizar no aplicativo, cancele as solicitações abertas em vez de deixá-las completas por nada. tente agrupar o que você puder. Faça coisas em série em vez de paralelas para minimizar conexões abertas simultâneas

3) Certifique-se de indexar corretamente seu banco de dados. O parse-server não cria índices automaticamente, então fazer um monte de consultas pode realmente sobrecarregar o seu banco de dados, fazer com que demore mais tempo para obter dados, o que faz com que todo o servidor seja copiado. Se você estiver no mlab para seu banco de dados, abra seu console e vá para a guia de consultas lentas para o cluster. cmd / ctrl + f - "construa o índice" e construa cada um.

Para ser honesto, o número 1 é um problema de escala. A menos que você tenha uma base de usuários considerável, você deve ser capaz de conviver com o 2 e o 3. Parece que você está fazendo isso de uma forma muito ruim, e o seu aplicativo está tentando fazer muito de uma vez que não deveria ser, e fazendo o que está fazendo de forma ineficiente. Usamos um t2.micro para nosso servidor por mais de um ano sem problemas, embora isso tenha sido feito com no mínimo duas instâncias em um aplicativo do EB com escalonamento automático.