none
Desempenho Web Services RRS feed

  • Pergunta

  • Boa tarde

    Tenho uma aplicação desktop que consome um web service. O problema é que o tempo de resposta do web service é muito ruim. O cliente possui uma excelente conexão de Internet e o volume de dados enviado pelo web service é relativamente baixo (BEM abaixo de 1 MB). E já utilizo compressão de dados (GZip).
    Já pesquisei em vários sites, procurando técnicas para melhorar a performance dos Web Services, configurações do servidor ou qqr coisa que possa melhorar a performance do meu Web Service, mas não obtive sucesso.

    Alguém poderia me dar uma luz, indicar um site com mais informações sobre o assunto ou me algumas dicas de performance com Web Services?
    sexta-feira, 27 de novembro de 2009 16:54

Respostas

  • Entao.. esse casos ocorrem com internet ADSL ou Cable ?

    3G é muito util para mobilidade... mas ela tem o costume de perder pacotes com grande facilidade mesmo sendo uma coxeção de 1GB, a taxa de retransmição e reconexão é altissima

    Se vc vai trabalhar com um conexão desse porte, seria o caso de ter uma abordagem mais voltada para metodoligas de sistemas mobiles... mantendo o maximo possivel das informações em cache no cliente, e fazendo poucas postagens, mesmo que maiores, mas so quando for estritamente necessario....


    What would Brian Boitano do ? ((2B || !2B) is Question) ?
    quinta-feira, 10 de dezembro de 2009 12:34
    Moderador

Todas as Respostas

  • Bah, estou começando a me convencer de que terei que conviver com os problemas de performance dos meus web services. Encontrei vários artigos dizendo que o protocolo SOAP possui tal problema (perfomance). Alguns até apresentam soluções paliativas, q na verdade não me ajudaram.

    Mais alguém se deparou com este problema? Será que devo desistir, e me conformar com a lentidão do meu web service? Será que é assim mesmo??
    segunda-feira, 30 de novembro de 2009 12:16
  • Gabriel... o que é lento para vc ? eu uso Webservices normalmente mesmo com um links ruins e tenho uma performace muito boa....

    tipo da uma mensurada.... como por exemplo uma resposta de tantos kb leva tantos segundos para trafegar...

    outra coisa... coloca um sniffer para verificar o tempo de envio e recebimento de dados pela rede....

    a unica coisa ai q me chamou a atenção foi o fato de vc estar compactando os dados antes de enviar....

    o tempo q vc perde para fazer a compressão e descompressão dos dados, num pacote de 5 megas por exemplo.... pode estar sendo maior do que vc simplesmente enviar os dados sem compactação nenhuma

    entao o interessante eh vc tirar uma medida, calculando quanto tempo vc leva para processar os dados antes de enviar para o webservice... o tempo que os dados levam para trafega pela rede... e o tempo q vc leva processando os dados no seu webservice....

    depende da arquitetura de cada sistema... mas eu gosto de trabalhar com webservices apenas como uma camada de acesso aos dados.... mantendo as minas regras de negocio e todo processamento mais demorado dentro da minha classe proxy de acesso ao webservice....
    What would Brian Boitano do ? ((2B || !2B) is Question) ?
    segunda-feira, 30 de novembro de 2009 12:50
    Moderador
  • Pois é Rui. Já fiz algo parecido com o q vc sugeriu. Estou medindo o tempo q meu WebMethod leva para executar a rotina, q consiste basicamente em pegar um XML, com pouquíssimos dados, montar uma query, consultar no banco, comprimir o dataset e retornar. O tempo de execução desta rotina é muito baixo. Inclusive, dentro da empresa, na rede local, a resposta do web service é satisfatória. O problema é quando o web service é utilizado pelos clientes de fora.
    Fiz um teste, conectado num 3G (com uma conexão não muito boa) e em alguns casos  chegou a demorar 20 segundos, para me retornar 20 KB. Ok, como disse, a conexão não era boa, mas 20 s me parece muito tempo. E os usuários de nosso sistema, na grande maioria, tem conexões de banda larga muito boas, e ainda assim estão reclamando de performance.
    Como falei, na rede local o webservice me dá respostas muito boas. Mas o problema é quando chamamos o webservice fora da rede local. O tempo que leva para trafegar os dados é muito alto. Não sei, mas talvez eu esteja procurando o problema no lugar errado...
    segunda-feira, 30 de novembro de 2009 13:10
  • Entao.. esse casos ocorrem com internet ADSL ou Cable ?

    3G é muito util para mobilidade... mas ela tem o costume de perder pacotes com grande facilidade mesmo sendo uma coxeção de 1GB, a taxa de retransmição e reconexão é altissima

    Se vc vai trabalhar com um conexão desse porte, seria o caso de ter uma abordagem mais voltada para metodoligas de sistemas mobiles... mantendo o maximo possivel das informações em cache no cliente, e fazendo poucas postagens, mesmo que maiores, mas so quando for estritamente necessario....


    What would Brian Boitano do ? ((2B || !2B) is Question) ?
    quinta-feira, 10 de dezembro de 2009 12:34
    Moderador
  • Os teste de desempenho q fiz foi com um 3G, porém os usuários d nosso sistema tem Internet banda larga, via cabo, tradicional. Mas gostei da idéia manter informações em cache. O q não sei é como vou garantir q os dados q estão em cache não estão atualizados. Talvez eu poderia ter uma rotina q, "por d trás dos panos", verifica o log dos dados, o q é uma informação bem mais leve para consultar.
    Mas gostei desta idéia. Vou seguir esta linha de raciocínio.

    Valeu Rui
    • Marcado como Resposta Gabriel Bauermann quinta-feira, 10 de dezembro de 2009 13:45
    • Não Marcado como Resposta Gabriel Bauermann quinta-feira, 10 de dezembro de 2009 13:45
    quinta-feira, 10 de dezembro de 2009 13:45
  • Ah... vc não disse que queria uma solução facil :P kkkk

    Realmente tem que analisar... existem tabelas com pouca alteração que podem ser carregadas manualmente... por exemplo um cadastro de fornecedores... quando o cliente nao encontra um fornecedore que deve ter sido cadastro por outro usuario no dia... vc pode deixar um botao para carregar a lista de fornecedores atual... o qual ele so vai usar nesses casos....

    Agora o caso de informações mais dinamicas q mudando o tempo todo... as mesmas costuma conter informacoes estaticas.... por exemplo.. uma venda acontece o tempo todo... mas o material vendido e o fornecedor do mesmo sao informaçoes mais estaticas.... vc pode trafegar apenas o codigo delas pelo service ao inves de todos os dados e juntar tudo na sua aplicação cliente

    é bem trabalhodo na verdade... mas vc vai ter um ganho de performance consideravel com um baixo impacto na sua regra de negocio...


    P.S. Antes que alguem leia e caia duro para tras... kkkkk 3G tem conexao de 1Mb... nao 1Gb como dito no post anterior :P


    What would Brian Boitano do ? ((2B || !2B) is Question) ?
    quinta-feira, 10 de dezembro de 2009 16:04
    Moderador
  • Hehehe, eu qro um 3G destes p mim. Se tu não fala não teria nem reparado...

    Mas d fato, concordo contigo. Vai dar bastante trabalho, mas acho q vale a pena.
    Outra coisa q estamos implementando aqui é paginar as listas (grids). Assim garanto q não vou puxar um volume de dados tão grande. Claro, quando trocar d página, vou consultar d novo, mas o volume d dados será baixo. E os dados da página já consultada serão guardados em cache. Não parece uma boa idéia, mas a maioria das vezes a informação q o usuário pesquisa está nos primeiros 20 registros, não havendo necessidade de mudar d página.

    Enfim, tenho muito trabalho pela frente. Mas tenho certeza q vai ficar bom.

    Obrigado pelas dicas Rui.
    quinta-feira, 10 de dezembro de 2009 17:18
  • Concordo com o Rui, solução fácil não é mol...

    É interessante trabalhar com filtros no cliente, até porque o usuário dificilmente precisará de todos os dados a cada momento. Tu pode aplicar filtros, trazer um objeto mais conciso, com menos informações e buscar o resto somente quando necessário. Também dá pra fazer chamadas assincronas. Enterte o usuários com alguns dados e em background busca o resto.

    São meus $0,02.
    sexta-feira, 11 de dezembro de 2009 17:51
  • Esta é a minha idéia André, utilizar um filtro e nas listas mostrar apenas o necessário. As demais informações busco depois. Se o usuário utilizar o filtro da forma correta, receberá somente a informação q precisa...
    Não tentei ainda com chamadas assíncronas. Algumas pessoas me desencorajaram a fazê-lo. Mas vou tentar ir por este caminho tbm. Pelo menos p ver como vai ficar.

    Obrigado

    sexta-feira, 11 de dezembro de 2009 18:22
  • Teu código client está numa página ASP.NET? Aí sim tem que ter alguns cuidados extras usando programação async, por exemplo, se a solicitação fosse concluída só depois de enviar a página pro browser. Mas concordo contigo, vale a pena ver como fica.
    segunda-feira, 14 de dezembro de 2009 12:06
  • Boa Tarde Gabriel

    Estou tendo problemas para retornar um WebService com vários registros (cerca de 3 milhoes) como vc fez essa compressão com GZIP?? vc tem algum exemplo que possa me ajudar

    até ++

    Leandro Prado

    http://projetofinal.wordpress.com/
    sábado, 20 de fevereiro de 2010 19:44
  • Cara,

    Dá uma olhada nestes links, acho q vão t ajudar.
    http://www.devmedia.com.br/articles/viewcomp.asp?comp=4424
    http://msdn.microsoft.com/pt-br/library/system.io.compression.gzipstream.aspx

    Falou
    segunda-feira, 22 de fevereiro de 2010 11:38
  • Obrigado Gabriel pelas dicas

    agora só nao entendi como aplicar o GZIP em um WebService ??

    em meu método estou retornando um DataTable, como faco para zipar o DataTable e trafegar ele compactado??

    Obrigado

    Leandro Prado

    http://projetofinal.wordpress.com/
    segunda-feira, 22 de fevereiro de 2010 23:02
  • Assim, teu método deve retornar um array de bytes. Então, tu pega o teu datatable, comprime com o gzip e manda. O método q consome o web service deve receber um array de bytes e descomprimi-lo com o gzip.
    terça-feira, 23 de fevereiro de 2010 11:12