Experiencias de RDDs lentos

[karinha]

Gracias Lucas, mira porfa... saludos.

Code: Select all  Expand view

#include "FiveWin.ch"

function Main()

   If !WIN_OSNETREGOK() //Precisa direitos ADM

      If !WIN_OSNETREGOK(.t.,.t.) //primeiro .t. é para ajustar XP/W98..., o segundo ajusta no vista.

         MsgInfo('Registro do windows não ajustado !')

      EndIf

   EndIf

RETURN NIL

#include "common.ch"
#include "directry.ch"

#define WIN_HKEY_LOCAL_MACHINE 0
#define WIN_HKEY_CLASSES_ROOT 1
#define WIN_HKEY_CURRENT_USER 2
#define WIN_HKEY_CURRENT_CONFIG 3
#define WIN_HKEY_LOCAL_MACHINE 4
#define WIN_HKEY_USERS 5

/* NOTE: To change any of these registry settings
    Administrator rights are required by default in Windows. [vszakats] */

FUNCTION WIN_OSNETREGOK( lSetIt, lDoVista )

   LOCAL bRetVal := .T.
   LOCAL cKeySrv
   LOCAL cKeyWks

   IF ! ISLOGICAL( lSetIt )

      lSetIt := .F.

   ENDIF

   IF ! ISLOGICAL( lDoVista )

      lDoVista := .T.

   ENDIF

   IF ! lDoVista .AND. Os_IsWinVISTA() //win_osIsVistaOrUpper()
      /* do nothing */
   ELSEIF Os_IsWin9X() // hb_osIsWin9x()
      bRetVal := QueryRegistry( WIN_HKEY_LOCAL_MACHINE, "System\CurrentControlSet\Services\VxD\VREDIR", "DiscardCacheOnOpen", 1, lSetIt )
   ELSE
     cKeySrv := "System\CurrentControlSet\Services\LanmanServer\Parameters"
     cKeyWks := "System\CurrentControlSet\Services\LanmanWorkStation\Parameters"

     IF lSetIt
        lSetIt := ! Os_IsWinNT() .OR. os_IsUserAnAdmin() //wapi_IsUserAnAdmin()
     ENDIF

     /* Server settings */
     bRetVal := bRetVal .AND. QueryRegistry( WIN_HKEY_LOCAL_MACHINE, cKeySrv, "CachedOpenLimit", 0, lSetIt )
     bRetVal := bRetVal .AND. QueryRegistry( WIN_HKEY_LOCAL_MACHINE, cKeySrv, "EnableOpLocks", 0, lSetIt ) /* Q124916 */
     bRetVal := bRetVal .AND. QueryRegistry( WIN_HKEY_LOCAL_MACHINE, cKeySrv, "EnableOpLockForceClose", 1, lSetIt )
     bRetVal := bRetVal .AND. QueryRegistry( WIN_HKEY_LOCAL_MACHINE, cKeySrv, "SharingViolationDelay", 0, lSetIt )
     bRetVal := bRetVal .AND. QueryRegistry( WIN_HKEY_LOCAL_MACHINE, cKeySrv, "SharingViolationRetries", 0, lSetIt )

     IF Os_IsWinVISTA() // win_osIsVistaOrUpper()
        /* If SMB2 is enabled turning off oplocks does not work, so SMB2 is required to be turned off on Server. */
        bRetVal := bRetVal .AND. QueryRegistry( WIN_HKEY_LOCAL_MACHINE, cKeySrv, "SMB2", 0, lSetIt )
     ENDIF

     /* Workstation settings */
     bRetVal := bRetVal .AND. QueryRegistry( WIN_HKEY_LOCAL_MACHINE, cKeyWks, "UseOpportunisticLocking", 0, lSetIt )
     bRetVal := bRetVal .AND. QueryRegistry( WIN_HKEY_LOCAL_MACHINE, cKeyWks, "EnableOpLocks", 0, lSetIt )
     bRetVal := bRetVal .AND. QueryRegistry( WIN_HKEY_LOCAL_MACHINE, cKeyWks, "EnableOpLockForceClose", 1, lSetIt )
     bRetVal := bRetVal .AND. QueryRegistry( WIN_HKEY_LOCAL_MACHINE, cKeyWks, "UtilizeNtCaching", 0, lSetIt )
     bRetVal := bRetVal .AND. QueryRegistry( WIN_HKEY_LOCAL_MACHINE, cKeyWks, "UseLockReadUnlock", 0, lSetIt )

     IF Os_IsWinVISTA() //win_osIsVistaOrUpper()

        bRetVal := bRetVal .AND. QueryRegistry( WIN_HKEY_LOCAL_MACHINE, cKeyWks, "FileInfoCacheLifetime", 0, lSetIt )
        bRetVal := bRetVal .AND. QueryRegistry( WIN_HKEY_LOCAL_MACHINE, cKeyWks, "FileNotFoundCacheLifetime", 0, lSetIt )
        bRetVal := bRetVal .AND. QueryRegistry( WIN_HKEY_LOCAL_MACHINE, cKeyWks, "DirectoryCacheLifetime", 0, lSetIt )

     ENDIF

     IF Os_IsWinNT() //hb_osIsWin2K()

        bRetVal := bRetVal .AND. QueryRegistry( WIN_HKEY_LOCAL_MACHINE, "System\CurrentControlSet\Services\MRXSmb\Parameters", "OpLocksDisabled", 1, lSetIt )

     ENDIF

     // Gracias Lucas, mi duda major és aqui:
     IF Os_IsWin7() //hb_osIsWin7()

        bRetVal := bRetVal ... ??? Entende?

     ENDIF

     IF Os_IsWin8() //hb_osIsWin8()

     ENDIF

   ENDIF

RETURN bRetVal

FUNCTION WIN_OSNETVREDIROK( /* @ */ nResult )

   LOCAL aFiles

   nResult := 0

   IF Os_IsWin9X() // hb_osIsWin9x()

      aFiles := Directory( GetEnv( "WINDIR", "C:\WINDOWS" ) + "\SYSTEM\VREDIR.VXD" ) /* Check for faulty files. */

      IF ! Empty( aFiles )

         IF aFiles[ 1 ][ F_SIZE ] == 156749 .AND. aFiles[ 1 ][ F_TIME ] == "11:11:10"

            nResult := 1111

         ELSEIF aFiles[ 1 ][ F_SIZE ] == 140343 .AND. aFiles[ 1 ][ F_TIME ] == "09:50:00"

            nResult := 950

         ENDIF

      ENDIF

   ENDIF

RETURN Empty( nResult )

#pragma BEGINDUMP
 
#include <windows.h>
 
HB_FUNC( OS_ISUSERANADMIN )
 {
 BOOL b;
 SID_IDENTIFIER_AUTHORITY NtAuthority = SECURITY_NT_AUTHORITY;
 PSID AdministratorsGroup;
 b = AllocateAndInitializeSid( &NtAuthority, 2,
 SECURITY_BUILTIN_DOMAIN_RID,
 DOMAIN_ALIAS_RID_ADMINS,
 0, 0, 0, 0, 0, 0,
 &AdministratorsGroup );
 if( b )
 {
 if ( !CheckTokenMembership( NULL, AdministratorsGroup, &b ) )
 b = FALSE;
 FreeSid( AdministratorsGroup );
 }
 
hb_retl( b );
 }
 
#pragma ENDDUMP
 



[thefull]

Buenas

Otra prueba más;

Windows 2008 R2 64bits con clientes Windows 7 64bits, se aprecia una velocidad brutal al aplicar los cambios en el registros de windows!

Saludos Cordiales

[gmart1]

Hola, voy a exponer mi experiencia con un cliente que lleva 6 meses con lentitud a raíz de un cambio en su red.
El sistema estaba compuesto por un servidor con Server 2003 a 32 bits y una red de unos 10 ordenadores con windows XP SP3 a 32 bits. Mi programa estaba construido con FW2.3, clipper 5.3b y blinker 4.00. Es una aplicación con muchos años funcionando, primero en MS-DOS y a partir del año 2006 en windows con FW2.3.
En diciembre de 2013 cambian los 10 ordenadores e instalan windows Siete a 64 bits. Actualizo el programa con FWH 7.11, xHarbour 0.99.71 y bcc55. Entonces me dicen que el programa va lento en algunas pantallas, compruebo que son en las que se hace un filtro desde la clase tcbrowse, uso base de datos DBF e indices NTX.
Después de hacer varias pruebas : cambiar a Harbour build 1.1-1, usar indices CDX, desactivar SMB2 (como se dice en este hilo)... No consigo ninguna mejora, cuando dos usuarios abren el mismo fichero y están en una pantalla con filtro, el tcbrowse tarda más de 20 segundos en refrescar la pantalla con 23 registros.
En febrero de 2014 cambian el servidor por un server 2008 a 32 bits y no se consigue mayor rapidez, al revés los ficheros tienen más datos y se ralentiza cada vez más, la única solución que les pude dar es que se salieran de las pantallas si no estaban usando el programa.
En mayo estuve analizando la clase wbrowse para saber porque al usar el SetFilter se ralentizaba tanto y encontré que en el metodo SetFilter a bLogicLen se le asigna una llamada a Self:RecCount (uVal1), donde se recorren un máximo de ::nMaxFilter registros según el indice activo. Al refrescarse el browse se evalúa bLogicLen 4 veces por cada línea del browse, así que 4 veces por 23 líneas del browse y un nMaxFilter de 40 hace que se recorran 3680 registros para cada refresco. La solución que he aplicado es quitar la asignación de bLogicLen y ejecutar el RecCount (uVal1) solo cuando se añade o borra un registro, todavía están probando esta versión, pero ahora ya no hay lentitud.
Por otro lado, me he hecho una pregunta : ¿ Por qué con FW23 funcionaba rápido y con FWH70 va lento, si la clase wbrowse no ha cambiado en su metodo SetFilter y también recorría los 3680 registros ? La respuesta no la sé todavía, pero sospecho que el motivo está en el sistema operativo, creo que windows siete a 64 bits ralentiza la aplicación cuando está movimiéndose por los registros de una DBF. Esto lo sé porque en otro cliente tenía una búsqueda secuencial en una base de datos de 5000 registros y con fw23 tardaba 3 segundos si la recorría completamente, pero en un ordenador con siete 64 bits aparecía en la ventana principal el mensaje "No reponde" y podía tardar 45 segundos. Simplemente añadí un MsgMeter que ejecuta la función de búsqueda y mejoró mucho. Por eso creo que cuando el programa está haciendo algo que no envía mensajes o se comunica con windows, el siete a 64 bits lo ralentiza, supongo que para evitar que se quede bloqueado todo el sistema.
Bueno espero no haberles aburrido y que mi experiencia les pueda servir.
Un saludo.

[Antonio Linares]

Gabriel,

Muchas gracias por tu valiosa información. En concreto esto me parece muy importante y hay que revisar todos los codeblocks y ver si alguno se está evaluando más veces de lo necesario:

En mayo estuve analizando la clase wbrowse para saber porque al usar el SetFilter se ralentizaba tanto y encontré que en el metodo SetFilter a bLogicLen se le asigna una llamada a Self:RecCount (uVal1), donde se recorren un máximo de ::nMaxFilter registros según el indice activo. Al refrescarse el browse se evalúa bLogicLen 4 veces por cada línea del browse, así que 4 veces por 23 líneas del browse y un nMaxFilter de 40 hace que se recorran 3680 registros para cada refresco. La solución que he aplicado es quitar la asignación de bLogicLen y ejecutar el RecCount (uVal1) solo cuando se añade o borra un registro, todavía están probando esta versión, pero ahora ya no hay lentitud.

[hmpaquito]

Antonio,

Hace muuucho tiempo leí (cosadenegro/ puertosur) que xHarbour tenia un profiler para poder conocer qué partes del programa ocupaban más tiempo... la verdad... aquello no lo llegué ni tan siquiera a probar. ¿ Cuanto codigo ineficiente puede haber en nuestras aplicaciones ? Probablemente pensemos que seguramente no habra mucho... pero si no tenemos una herramienta que evalue esa circunstancia ¿ como estamos tan seguros de la eficiencia de nuestros programas ?

Saludos

[Antonio Linares]

Paco,

Yo desarrollé la versión inicial del profiler de Harbour, luego lo conozco bien

Es muy válido, pero en Windows, no solo se trata de la eficiencia de nuestro código, sino de armonizar los tiempos de ejecución con Windows. Es decir, nuestras aplicaciones son aplicaciones que corren sobre otra gran aplicación que es el software de Windows.

En el IDE de Visual Studio hay un profiler realmente poderoso que aún no he tenido tiempo de revisar a fondo pero estoy seguro que nos podrá ayudar en casos así, porque no sólo hace profiling del código Harbour, sino de todo el código en C que usamos puesto que en realidad lo que construimos con Harbour es una auténtica aplicación en C, y a este nivel no llega (ni remotamente) el profiler de Harbour

De ahi mi insistencia en familiarizarnos con el IDE de Visual Studio, para poder hacer mediciones profesionales de eficiencia de la aplicación entera.

[hmpaquito]

Antonio,

Es genial lo que dices. Lo ignoraba todo.

Muchas gracias por la explicación.

Saludos

[thefull]

Buenas

En mi cruzada con el pésimo rendimiento con el SMB, estoy encontrando un caso
WINDOWS 2003 32Bits SP2, contra clientes de Windows 7 64 bits, he realizado todo y no
consigo mejoría apreciable.

También podemos echar un vistazo a esta entrada,http://technet.microsoft.com/en-us/library/cc731957.aspx ,donde nos dice que el tema de seguridad en SMB,
puede degradar la red en un 15%!!!

Por lo tanto tenemos otro camino para ir haciendo retoques para averiguar más sobre el tema.

Saludos

[Carlos Mora]

Rafa,

¿tus pruebas incluyen el código de Lucas, en lo que hace a oplocks? Esos parámetros son muy significativos, y más cuando el servidor es Linux/Samba o Win2003, las versiones antiguas.
Otra cosa que habría que considerar es si estamos hablando de dominios o grupos de trabajo. En el caso del dominio la administración de recursos está concentrada, en cambio si es un grupo de trabajo SMB tiene un sistema horroroso para asignar los roles administrativos, hace 'votaciones' entre todos los nodos participantes para elegir los Master Browsers y cosas así. Usando Samba este último problema se puede controlar, porque se le asigna al servidor manualmente ese rol de Master, pero la votación mezclando win7 con Win2003 no se como funcionará, ya que el peso de los votos al elegir el Master lo da la versión de windows que estás usando, no tengo idea si Win7-64 es mayor, menor o igual que win2003-32.

Sería recomendable pasar al menos a versiones de 64 bits en el servidor, no? Por la velocidad de acceso que dan los 64 bits, y el manejo de memoria para cachimg y eso.

Un saludo

[thefull]

Carlos, si , incluyen el código de Lucas, el mío, el del vecino, y del mismo diablo

Sigo con las pruebas y hemos dado con algo significativo, que es que si en el server hay un Sql Server corriendo, nos penaliza en el acceso a los datos, no tiene nada que ver con la red.
Porque el movimiento de red, solo supone 800Kb, es insignificante.

Lo que si he visto, es que el servidor estaba configurado como prioridad para Servicios en segundo plano vs Programas, que es seguramente como cambia el Sql Server para su propio beneficio.
De aquí un rato, he procedido a cambiar la configuración y estoy pendiente de reinicios de la máquina.

En cuanto a los 64 bits, estoy de acuerdo, pero no es una cosa que podamos controlar. Los clientes tienen esos sistemas, y no podemos hacer gran cosa, solo sugerir que si poner clientes de Win7 64bits,
contra un server 2003 32bits, puede que la combinación no sea la más optimo.

Saludos Cordiales

[thefull]

Buenas

Sigo mirando y vemos una mejora sustancia a la hora de configurar el server;


El server estaba configurado como "Servicios en segundo plano" y se cambia a Programas y la se nota bastante la mejora.
De todas maneras, dentro de unos días vamos a poner otra máquina con el mismos sistema W2003, sin el SQL Server, y volveremos a probarlo

Saludos Cordiales

[Antonio Linares]

Rafa,

Muchas gracias por tu información, como siempre, muy valiosa

[lucasdebeltran]

Hola,

Sobre esto, ¿hay algún avance?.

Un saludo