none
Lentitud Proceso de Aplicacion Visual Basic 6.0 RRS feed

  • Pregunta

  • Hola Amigos

    Tengo un problema con una aplicación de VB 6.0.  Resulta que corría en un servidor de 64 bits con un Windows Server 2008 Standard SP1 de 32 bits con una base de datos SQL Server 2008 R2 Standard x86 SP3.  Este servidor tenía 8 GB pero solo le eran reconocidos 4 GB.  Es por esto que se decidió migrar a otro servidor de 64 bits (y por ende la aplicacion) el cual tiene instalado Windows Server 2008 R2 SP1 con 8 GB de RAM y SQL Server 2008 R2 Standard SP3 x64.

    El programa que tenemos de VB6.0 realiza un proceso batch que involucra conexiones con otros servidores y un proceso batch de manera central.

    El hecho es que hemos visto una especie de degradación en el tiempo que se ejecuta la aplicación.  Por ejemplo un proceso que tomaba 4 minutos ahora se demora 45 minutos (Proceso Local)

    Hemos revisado contadores de Rendimiento tanto a nivel de Windows como  de SQL y no se ha mostrado algún tipo de fallo en el performance. 

    Me gustaría saber:

    Es  posible aplicaciones de VB 6.0 concebidas para 32 bits pueden sufrir algun tipo de degradacion al no ser nativos en un servidor de 64 bits aunque este tengan la funcionalidad de WOW? y de ser así es posible establecer algún tipo de configuración

    que permita ajustar esta ejecución para aplicaciones de 32 bits?

    Gracias de antemano por la ayuda, la verdad no se que pueda ser

    jueves, 18 de diciembre de 2014 14:37

Respuestas

  • Hola, El problema fue la conexion ODBC estaba utilizando el driver que corresponde a SQL Server 2000 (SQL Client).  Procedí a cambiar los ODBC para que trabajen con el driver SQL Client 10.0 y todo funcionó de manera correcta y mucho más rápido.

    Gracias José y Jesús por sus comentarios

    Saludos

    • Marcado como respuesta Aleds lunes, 23 de febrero de 2015 22:26
    lunes, 23 de febrero de 2015 22:25

Todas las respuestas

  • No me parece que la aplicación deba sufrir por estar corriendo en WOW.  ¿La aplicación VB6 tiene algún tipo de traza o bitácora que muestre información de dónde está el cuello de botella?  Yo empezaría buscando ahí.

    Jose R. MCP
    Code Samples

    viernes, 19 de diciembre de 2014 4:09
  • Yo creo que lo más probable es que las consultas se hayan vuelto lentas.

    ¿Has probado a reconstuir los índices de la base de datos y a actualizar la estadísticas?

    Te aconsejo que identifiques las consultas más pesadas y procures optimizarlas.



    Jesús López


    EntityLite a lightweight, database first, micro orm

    • Propuesto como respuesta Pedro Ávila viernes, 19 de diciembre de 2014 12:37
    viernes, 19 de diciembre de 2014 6:48
  • Gracias José y Jesús por sus comentarios.

    Les comento que hicimos un reverso del servidor es decir volvimos al servidor anterior (el de 32 bits) con la misma base de datos y los tiempos fueron mejores.

    Esta vez si no tengo idea, pues si fuera un problema de base de datos el tiempo sería el mismo.

    De hecho este servidor es de 32 bits y solo reconoce  4 GB de 8 GB.  El sql  lo tengo configurado para que tome solo hasta 2400 MB. El Maximum working Threads (Máximo de hilos de ejecución) que tengo es de 1024 y el proceso corre muchísimo más rápido

    En el servidor de 64 bits tenía 8 GB y reconocía los 8 GB. El SQL en este caso lo tengo configurado para que consuma hasta 5200 GB. Con hilos de ejecución hasta de 1024.

    Sinceramente ya no creo que sea Performance de equipo o el motor ya que la configuración que estoy aplicando desde el punto de vista de motor es la correcta.

    Todo lo que me queda es el sistema operativo, porque ya he analizado además los promedios de lectura y Escritura den disco y son relativamente bajos.

    Si tienen otra teoría me ayudarían muchisimo

    Gracias de antemano

    Saludos

    viernes, 19 de diciembre de 2014 16:49
  • Pues mi respuesta nunca fue una teoría.  Fue una sugerencia para determinar exactamente qué parte del código de la aplicación se está tomando mucho tiempo y partir la investigación desde ahí.

    Una prueba que puede hacer con respecto al sistema operativo es instalar Server 2008 (el que funciona bien) pero versión de 64-bit.  Así podría ver si hay algún impacto solamente por cambiar de 32-bit a 64-bit.


    Jose R. MCP
    Code Samples

    viernes, 19 de diciembre de 2014 19:36
  • Hola, El problema fue la conexion ODBC estaba utilizando el driver que corresponde a SQL Server 2000 (SQL Client).  Procedí a cambiar los ODBC para que trabajen con el driver SQL Client 10.0 y todo funcionó de manera correcta y mucho más rápido.

    Gracias José y Jesús por sus comentarios

    Saludos

    • Marcado como respuesta Aleds lunes, 23 de febrero de 2015 22:26
    lunes, 23 de febrero de 2015 22:25