ARQUITETURA RESTFULL COM MUITOS REQUESTS
Me perguntaram isso em um teste e eu não sei responder...
Citação:[Ô]Imagine um cenário onde você precisa construir uma arquitetura de API Restful onde existe um alto número de requests (50% GET, 50% POST), descreva uma solução para suportar esse volume.[Ô]
(A solução deve contemplar tanto a camada de aplicação (http) , quanto a camada de armazenamento de dados.)
Por favor, alguém podem me explicar?
Obrigado,
Tunusat.
eu tenho um problema parecido, e olha que minha aplicação é pequena.
As vezes quando o dispositivo mobile fica ocioso, Quando tento fazer requisições na webapi, acontece bastante problema com timeout.
Tenho sistema para restaurantes e o acesso é quase a todo momento, mas se deixar ocioso por um tempinho... problema a vista.
Geralmente a estrutura é um PC no caixa que é o servidor, usando IIS, e o roteador compartilhado pra todos.
TUNUSAT, com certeza então o backend tem que ser algo bem rápido, por isso, soluções prontas como Entity Framework podem não ser uma boa alternativa. Nesse caso, um bom e velho CRUD feito à mão, bem simplificado pode ser sua solução. De preferência, sem o uso de Reflection ou outras operações que podem ser bastante lentas.
Como existe uma grande quantidade de requisições, deve-se adotar um formato de comunicação bem leve, como o JSON. A estrutura de um xml pesaria bastante, e como o REST não te obriga a usar um formato especÃfico, JSON possivelmente pode ser uma boa solução. Assim você diminuiria consideravelmente a quantidade de dados trafegados.
Sobre a camada de armazenamento, não sei muito bem o que falar. Para os GET serem rápidos, uma boa indexação no banco de dados é essencial. No demais, é o que o Kerplunk comentou... as vezes vale a pena perder as facilidades de uma camada de persistência mais complexa e fazer operações mais cruas, pra não perder tempo buscando os dados das propriedades e seus atributos por Reflection..
Abraços!
Citação:CLEVERTON, esse problema pode ser devido à rede. Quando a conexão fica ociosa, o pipe é destruÃdo e para recriar pode levar um tempinho. Verifique as configurações de rede.
O ocioso que me refiro é no máximo, 5~10 minutos.
vc se refere que isso pode ser um problema no equipamento de rede ( roteador, firewall ) ?
vc acha uma boa prática eu ficar dando acessando algum método que só me retorne um 1bit na webapi quando o dispositivo estiver em descanso de tela ?
Citação::
KERPLUNK
CLEVERTON, esse problema pode ser devido à rede. Quando a conexão fica ociosa, o pipe é destruÃdo e para recriar pode levar um tempinho. Verifique as configurações de rede.
O ocioso que me refiro é no máximo, 5~10 minutos.
vc se refere que isso pode ser um problema no equipamento de rede ( roteador, firewall ) ?
vc acha uma boa prática eu ficar dando acessando algum método que só me retorne um 1bit na webapi quando o dispositivo estiver em descanso de tela ?
Já que se trata de uma rede interna, esse pode ser um quebra-galho até você ver porque o pipe está sendo derrubado.
