WEB. Dbfs con modHarbour o no ?

De

Hace unos días, un programador harbour que ofrecia un ejemplo de prototipo de browse usando modharbour junto a dbfs. Hasta aqui nada raro  si no fuera porque para el manejo de los Dbf's usaba unas funciones con php ! Que ?

https://forums.fivetechsupport.com/viewtopic.php?f=3&t=44607&sid=2bbfd37fed3fa1edeeae5be067c265a3 

Bueno, pues estas son un poco mis reflexiones sobre esta tema y mas porque después de que justamente cuando este programador defiende que el poder de modHarbour y la "marca" es el uso de dbf's, va y busca la solución con otro lenguaje. Solo comentar... mama mia😕

Todo estriba en que cuando montas un sistema web, la velocidad es importante para tener una aplicación fluida, justamente como una aplicación de escritorio. Cuando tenemos por ejemplo el típico browse con 50 registros, si avanzamos página el sistema ha de ser fluido sino peca de morir en el intento de ofrecer un sistema ágil y versátil.

Publicó un bonito ejemplo de browse y el sistema iba realmente ágil, pero claro para alguien que todo el día va publicando que si modharbour 1.0 es lo mejor para programar web, que las dbfs son mejores que SQL, ... y ves que al final usa php para el manejo y gestión de la dbf... pues parece como hacer un poco de trampas al poker ! 😀

Para que se entienda, puedes tener un programa que use modharbour y te crea una pantalla que seria nuestro browse, pero los controles de esta pantalla usarian javascript para conectarse via ajax a un servidor php y ejecutara la petición !  

Funciona ? Si 

Tiene sentido ? No

Es realmente necesario ? No

Claramente vi su problema real y claramente sabia su solución. Todo es un problema de cuello de botella que empieza en el uso de la versión de modHarbour, en la que siempre ha usado la versión 1. Esta versión es funcional pero defectuosa para proyectos en producción, es lenta, da problemas de memoria, problemas con las dlls, ... Esta versión demora en cada petición al servidor una media de 150ms en tiempo de petición,  colapsos de memoria, dlls no liberadas,... problemas típicos en cualquier primera versión de cualquier software.  El mismo Antonio puso un enlace en su día comentando dicho problema: 

https://forums.fivetechsupport.com/viewtopic.php?f=6&t=42204&p=253500&hilit=fastcgi&sid=211f609faebc5830e542f5c81e2240ca#p253452

Porque no usar la versión 2.1 ? Bueno, yo tengo mi opinión al respecto pero tampoco es relevante, lo que si que es relevante  en que la versión 2.1 ejecutaría estas peticiones entre 0.02ms y 0.05ms. y solo esto es lo que ya le da una buena performance a nuestro sistema a parte de otros temas como seguridad, integridad y sobretodo...velocidad.

Hoy en día, el mundo web es un entorno de conectividad. Conectamos a microservicios, apis rest, ai,..en resumen, que conectamos con otros sistemas que no sabemos ni como están hechos (o si) e interfasamos información de una lado para otro de muchas maneras.

Si hablamos en clave Harbour nuestro querido RDD system es lo mas poderoso que existe a nivel de manejo de dbfs, íntegramente programado en C y cumpliendo perfectamente el objetivo con el que se diseñó. Porque hemos de usar otros sistema para gestionar dbfs, como por ejemplo php ?  (y que encima no hace la mayoría de cosas y virtudes que puede hacer un rdd...)

Le respondí en ese foro que efectivamente hay otros sistemas, todos ellos harbour, mas potentes que la solución que proporcionaba y que al final era una solución harbour 100% . Le dije que si quería me prestaba a hacer un test con una simple carga de 50 registros de una dbf, hechos con diferentes soluciones harbour: modharbour v1.0, v2.1, runnerxbase (UT), ... y que si me enviaba su rutina php también  la adaptaría al mismo test. El objetivo era crear unas métricas sencillas para ejecutar en una misma máquina todas estas pruebas.

El test, básicamente es sencillísimo, no tiene secreto: Abrir tabla, leer, codificar en json, enviar. Podemos hacer una variedad de tests, pero ahora el tema estaba en la velocidad para tener acceso  a las dbf.

function main()

    local cDbf   := hb_getenv( 'PRGPATH' ) + '/database.dbf'
    local aRows  := {}
    
    use (cDbf) shared new

    for n := 1 to 50
    
        Aadd( aRows, {;
                'first' => FIELD->first,;
                'last' => FIELD->last,;
                'street' => FIELD->street,;
                'city' => FIELD->city,;
                'state' => FIELD->state,;
                'married' => FIELD->state;               
            })

        DbSkip()
    next
       
    AP_SetContentType( "application/json" )
    
    ?? hb_jsonEncode( aRows )
    
retu nil

Una vez creado este código era hora de crear el entorno de test y realizar las pruebas en los distintos escenarios

Hay muchas lecturas que podemos extraer de estos resultados:
  • El sistema mas rápido es V2.1
  • CGI es muy rápido pero falla en redundancia
  • PHP es muy rápido pero no ofrece la versatilidad del RDD system de harbour (y tampoco es Harbour 😄 )
  • RunnerXbase es un sistema all-in construido todo con Harbour con unos resultados espectaculares
  • V1.0 fue el pionero, quien abrió la lata y la entrada a los mods, pero es un sistema absorbido por los demás.

Creo que el resultado es claro y nos da una visión clara que no es necesario recurrir a estos sistemas para alcanzar el objetivo. Por otra parte analizando un poco la rutina php, es una rutina sencillísima de lectura a bajo nivel del dbf,  capaz de leer de a --> b secuencialmente, pero nada mas. Toda la potencia que tenemos con nuestro sistema RDD de Harbour no existe, no se aplica. Que sentido tiene ? Cuando lees que los indices no son necesarios piensas, para que se inventaron pues ? :-) 

Ya puestos en el análisis de la rutina php podria resumir las siguientes impresiones:

  • Lectura secuencial del fichero a bajo nivel ordenado por recno. Imposibilidad de usar indices
  • Codepages en función del idioma 
  • No existe control de caracteres especiales
  • Necesidad de servidor+php
  • No existe bloqueos
  • No existen scopes  
  • Es una rutina buena para importar datos desde una aplicación php, no harbour (existen otras opciones)
  • Resumen: Peor rendimiento que sistema rdd harbour

Pienso que hemos de caminar para encontrar soluciones directamente con nuestro Harbour. Si buscamos las soluciones en otros lenguajes, nos salimos de nuestro Harbour.

Siempre comento que tenemos varias maneras de entrar en la web, pero mis preferidas son:

    modHarbour 2.1 para entornos de alta rendimiento de manera profesional, pero que requiere mas conocimiento técnico en varios ámbitos: servidores apache, lenguajes, arquitectura web,...

    RunnerXbase o UT para entornos de pequeñas, medianas empresas que con poco conocimiento de la web y rápidamente tienes armado soluciones. Realmente potente 

    Httpd2 librería Harbour

Tenemos todas las herramientas necesarias para crear todo tipo de aplicaciones web. Solo falta entender bien y aplicar correctamente cada una de ellas, pero para el manejo de los DBF's yo lo tengo claro... 😉


[EDITADO] Curiosamente parece que quizás no entendió bien los resultados y quiso portar la rutina de php a harbour. Ya le comenté que crear rutinas a nivel prg no superaría el rendimiento del rdd en C. Me molesté ha crear el objetivo que quería leyendo directamente el dbf a bajo nivel con una simple, clara y potente rutina usando simplemente el rdd. El resultado:

  • Solución que propuso: 11ms.
  • Solución via RDD System: 1ms.

El código no hace falta. Cualquiera que trabaje en Harbour la sabria hacer, es muy simple...




 

 




Comentarios

Publicar un comentario