none
Performance ASP x VB.Net RRS feed

  • Pergunta

  • Bom dia,

    Tenho uma aplicação VB.Net que acessa e manipula um banco de dados na Locaweb com cerca de 120MB, dezenas de tabelas totalizando quase 100.000 registros.

    Estou tendo problemas para abrir alguns forms mais "pesados".

    Essa mesma aplicação teria melhor performance se desenvolvida em ASP.Net?

    Grato

    quinta-feira, 25 de setembro de 2014 12:38

Respostas

  • Não... Pode ser que a aplicaçao fique até mais lenta.

    ASP classico (com vb script) ou ASP.NET com VB.NET (pode ser com c# tambem) sao tecnologias de frontend... O seu problema (aparentemente) esta na forma como vc vai buscar esses dados..

    100.000 registros é pouco... Trabalho com bases que tem milhoes de registros e em todas as tecnologias possiveis (ASP Classico, Asp.Net, Asp.net MVC)... Mas eu nao "importo" essa massa de dados para a interface.... 

    Vamos lá. um ser humano consegue analisar na media 50 ou 60 registros por minuto.. 100mil rtregistros uma pessoa vai demorar 33 horas para analisar. Entao, nao há necessidade de trazer esse 100mil para interface.

    Agora se o processamento desses 100mil registros é feito de forma automatica (tipo faturamento) entao eu sugiro criar um camada de negocios que rode no servidor (mais uma vez.. o problema é a tecnologia usada para o tratamento e nao exibiçao)

    Mas tudo isso sao conjecturas... Descreva melhor o seu problema.. com isso poderemos te ajudar mais.

    Att



    William John Adam Trindade
    Analyste-programmeur
    ----------------------------------------------------------

    • Marcado como Resposta Cláudio Más sexta-feira, 26 de setembro de 2014 09:10
    quinta-feira, 25 de setembro de 2014 13:18
    Moderador

Todas as Respostas

  • Não... Pode ser que a aplicaçao fique até mais lenta.

    ASP classico (com vb script) ou ASP.NET com VB.NET (pode ser com c# tambem) sao tecnologias de frontend... O seu problema (aparentemente) esta na forma como vc vai buscar esses dados..

    100.000 registros é pouco... Trabalho com bases que tem milhoes de registros e em todas as tecnologias possiveis (ASP Classico, Asp.Net, Asp.net MVC)... Mas eu nao "importo" essa massa de dados para a interface.... 

    Vamos lá. um ser humano consegue analisar na media 50 ou 60 registros por minuto.. 100mil rtregistros uma pessoa vai demorar 33 horas para analisar. Entao, nao há necessidade de trazer esse 100mil para interface.

    Agora se o processamento desses 100mil registros é feito de forma automatica (tipo faturamento) entao eu sugiro criar um camada de negocios que rode no servidor (mais uma vez.. o problema é a tecnologia usada para o tratamento e nao exibiçao)

    Mas tudo isso sao conjecturas... Descreva melhor o seu problema.. com isso poderemos te ajudar mais.

    Att



    William John Adam Trindade
    Analyste-programmeur
    ----------------------------------------------------------

    • Marcado como Resposta Cláudio Más sexta-feira, 26 de setembro de 2014 09:10
    quinta-feira, 25 de setembro de 2014 13:18
    Moderador
  • Utilizando o SSMS (o banco de dados é o SQL Server 2008), a instrução abaixo retorna pouco mais de 31.000 registros e demora 25 segundos para executar no meu computador, com conexão de 10MB da Net Virtua.

    Em empresas com internet de 5Mb compartilhada entre várias máquinas, torna-se inviável.

    Alguma idéia?

    SELECT        tb05_PCLR.IdCliente, tb01_CadLeg.Id AS IdLeg, tb05_PCLR.Id AS IdPCLR, ISNULL(tb01_TiposDiploma.TipoDiploma, '') + ' ' + ISNULL(tb01_CadLeg.AuxOrg, '') 
                             + ' ' + ISNULL(tb01_CadLeg.Referencia, '') + ' - ' + ISNULL(CONVERT(nvarchar(10), tb01_CadLeg.Emissao, 103), '') AS Ref, tb01_CadLeg_Obrigações.Item, 
                             tb01_CadLeg_Obrigações.Obrigações
    FROM            tb05_PCLR INNER JOIN
                             tb01_CadLeg ON tb05_PCLR.IdLeg = tb01_CadLeg.Id INNER JOIN
                             tb05_PCLR_Obriga ON tb05_PCLR.Id = tb05_PCLR_Obriga.Id_PCLR INNER JOIN
                             tb01_CadLeg_Obrigações ON tb05_PCLR_Obriga.IdObrig = tb01_CadLeg_Obrigações.Id INNER JOIN
                             tb01_TiposDiploma ON tb01_CadLeg.IdTipoDiploma = tb01_TiposDiploma.Id
    ORDER BY Ref, tb01_CadLeg_Obrigações.Item

    quinta-feira, 25 de setembro de 2014 15:21
  • Porque o cliente precisa de 31000 registros? 

    Filtre essa consulta.

    Att


    William John Adam Trindade
    Analyste-programmeur
    ----------------------------------------------------------

    quinta-feira, 25 de setembro de 2014 15:37
    Moderador
  • O filtro será feito pelo usuário, em tempo de execução. Ele precisa consultar quais obrigações (campo nvarchar(max), alguns com mais de 3.000 caracteres) têm a palavra "treinamento", por exemplo. Por isso preciso trazer toda a base de 31.000 registros para um datagrid no form.

    Mas já entendi que o problema não está no front-end, mudar para ASP.Net não irá resolver.

    Obrigado


    Em tempo: retirando da consulta a tabela que contém o tal campo "obrigações", o resultado passa a ser quase instantâneo.
    • Editado Cláudio Más quinta-feira, 25 de setembro de 2014 15:57 tipo de dados do campo
    quinta-feira, 25 de setembro de 2014 15:54
  • Nao faça a filtragem depois... faça a filtragem antes. 

    Crie uma consulta parametrizada onde vc passa o filtro. Com isso vc reduz a quantidade de registros para o usuario.

    Nos meus projetos isso é limitado a 100 registros (para as telas de consulta) . Exceto na geraçao de arquivos de exportaçao, onde o usuario sabe que vai demorar um pouco.

    Att


    William John Adam Trindade
    Analyste-programmeur
    ----------------------------------------------------------

    quinta-feira, 25 de setembro de 2014 19:02
    Moderador