ADS Local Server and simultaneous requests

[ricardo arraes]

Well, I'm not sure everything I said is extremely precise...

but after exhausting tests and simulations, that's what I observed.

If there's any ADS expert reading this post, make yourself comfortable to correct any of my considerations!

[charly]

Hola,

Primero de todo hemos de entender lo que se entiende por concurrencia, o lo que entiendo yo ! Yo separaría conceptos en este hilo y la problemática aquí descrita.

1.- Yo entiendo que una concurrencia es cuando muchas peticiones sobre una base de datos se realizan al mismo tiempo, pero quizas en este hilo focalizaria esta petición sobre una misma tabla/registro en el mismo momento.

2.- Hemos de entender y/o diferenciar como trabaja un BBDD como por ejemplo MySql y nuestras Dbfs.

3.- Si nos centramos ahora en nuestras Dbf's, la "concurrencia" en un registro se manejan con los propios comandos que ofrece Harbour para el bloqueo de registros, como p.e. Rlock() Unlock(),...

4.- Cuando diseñas la aplicación quizás nunca ocurra la actualización de un mismo registro por 2 o mas peticiones al mismo tiempo, pero hemos de tener en cuenta evidentemente este caso, esto es sagrado con nuestras dbfs.

5.- Vamos ahora a focalizar sobre mod_harbour. Si ejecutamos varias peticiones sobre el mod, se crean varios procesos en apache y puede ejecutar estos procesos al mismo tiempo, e intentará de actualizar una misma tabla/registro. Si tenemos bien codificado el proceso, no ha de pasar nada. Si tu tienes un registro bloqueado y viene en el mismo momento otra petición tienes solo 2 opciones: O se espera, o se va (que tiene prisa )

6.- El problema que veo yo aquí es un tema de uso de ADS en local, y seguramente hay o tiene algún mecanismo para que actúe de una manera sencilla y monopuesto digamos. Ricardo comenta que en la versión server va todo perfecto, pues yo creo que allí esta la diferencia

7.- A nivel harbour puro y duro me he creado un pequeño test q inserto un registro en una tablita y bloqueo el primer registro para actualizarlo. Al pasar un test de apache p.e. de 100 peticiones y 10 concurrencias, el sistema funciona perfectamente, y no encontramos ninguna petición que haya fallado.

Código: Seleccionar todo

Concurrency Level:      5
Time taken for tests:   28.165 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      17500 bytes
HTML transferred:       0 bytes

Como podeis observar "Failed requests: 0"

Una vez verificada la tabla, todo es correcto: se crean 100 registros y el primero siempre se actualiza con la última petición procesada

Si me da tiempo, pondré el test en NetIO para hacer el mismo test, pero ha de funcionar de la misma manera…

8.- Es por eso, que hemos de analizar bien cada situación, entorno, arquitectura,… para poder valorar correctamente. Yo hace 15 años que no toco ADS, pero puedo pensar que los programadores de ADS no son tontos y quizás la versión local tiene algún tipo de limitación, como por ejemplo usar este tipo de concurrencias, sino quizás todo el mundo usaría este sistema y no compraría licencias, pero tampoco lo se de modo cierto, simplemente me lo imagino.

Pienso que la solución de Ricardo, que básicamente es un semáforo, es una ingeniosa solución que le permite de momento solventar este problema en modo local. Desgraciadamente un ejemplo autocontenido con las dll de ads, etc... es tiempo que necesitas para prepararlo y analizarlo. Pero en resumen, yo me quedo con esta visión, a no ser que venga otro y pueda aportar mas luz al tema.

Para acabar solo os puedo decir que durante los 5 años que trabaje con ADS (hace 15) era de lejos, el mejor sistema para trabajar con dbfs en modo cliente/servidor.

[ricardo arraes]

Hola,

Primero de todo hemos de entender lo que se entiende por concurrencia, o lo que entiendo yo ! Yo separaría conceptos en este hilo y la problemática aquí descrita.

1.- Yo entiendo que una concurrencia es cuando muchas peticiones sobre una base de datos se realizan al mismo tiempo, pero quizas en este hilo focalizaria esta petición sobre una misma tabla/registro en el mismo momento.

2.- Hemos de entender y/o diferenciar como trabaja un BBDD como por ejemplo MySql y nuestras Dbfs.

3.- Si nos centramos ahora en nuestras Dbf's, la "concurrencia" en un registro se manejan con los propios comandos que ofrece Harbour para el bloqueo de registros, como p.e. Rlock() Unlock(),...

4.- Cuando diseñas la aplicación quizás nunca ocurra la actualización de un mismo registro por 2 o mas peticiones al mismo tiempo, pero hemos de tener en cuenta evidentemente este caso, esto es sagrado con nuestras dbfs.

5.- Vamos ahora a focalizar sobre mod_harbour. Si ejecutamos varias peticiones sobre el mod, se crean varios procesos en apache y puede ejecutar estos procesos al mismo tiempo, e intentará de actualizar una misma tabla/registro. Si tenemos bien codificado el proceso, no ha de pasar nada. Si tu tienes un registro bloqueado y viene en el mismo momento otra petición tienes solo 2 opciones: O se espera, o se va (que tiene prisa )

6.- El problema que veo yo aquí es un tema de uso de ADS en local, y seguramente hay o tiene algún mecanismo para que actúe de una manera sencilla y monopuesto digamos. Ricardo comenta que en la versión server va todo perfecto, pues yo creo que allí esta la diferencia

7.- A nivel harbour puro y duro me he creado un pequeño test q inserto un registro en una tablita y bloqueo el primer registro para actualizarlo. Al pasar un test de apache p.e. de 100 peticiones y 10 concurrencias, el sistema funciona perfectamente, y no encontramos ninguna petición que haya fallado.

Código: Seleccionar todo

Concurrency Level:      5
Time taken for tests:   28.165 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      17500 bytes
HTML transferred:       0 bytes

Como podeis observar "Failed requests: 0"

Una vez verificada la tabla, todo es correcto: se crean 100 registros y el primero siempre se actualiza con la última petición procesada

Si me da tiempo, pondré el test en NetIO para hacer el mismo test, pero ha de funcionar de la misma manera…

8.- Es por eso, que hemos de analizar bien cada situación, entorno, arquitectura,… para poder valorar correctamente. Yo hace 15 años que no toco ADS, pero puedo pensar que los programadores de ADS no son tontos y quizás la versión local tiene algún tipo de limitación, como por ejemplo usar este tipo de concurrencias, sino quizás todo el mundo usaría este sistema y no compraría licencias, pero tampoco lo se de modo cierto, simplemente me lo imagino.

Pienso que la solución de Ricardo, que básicamente es un semáforo, es una ingeniosa solución que le permite de momento solventar este problema en modo local. Desgraciadamente un ejemplo autocontenido con las dll de ads, etc... es tiempo que necesitas para prepararlo y analizarlo. Pero en resumen, yo me quedo con esta visión, a no ser que venga otro y pueda aportar mas luz al tema.

Para acabar solo os puedo decir que durante los 5 años que trabaje con ADS (hace 15) era de lejos, el mejor sistema para trabajar con dbfs en modo cliente/servidor.

Thank for the explanantion Charly!
Yes, it's important to understand that it's not a mod_harbour issue, that's probably some strange ADS Local behaviour

But, once again, let me make it clear... the problem is not when I try to manipulate a locked table/register. the lock/unlock system is working fine.

the problem is when 2 or more requests are arriving at my webservice at the same time and they are trying to open a table (that is not locked by anybody).

[charly]

Ricardo,

Si, entiendo el problema , y he comentado que debe ser problema del ADS local. El rdd harbour funciona correctamente como muestro realizando 100 peticiones con 5 concurrentes, es decir, hay 5 procesos que abren la tabla compartida al mismo tiempo.

[wilsongamboa]

Buenas tardes
ADS LOCAL SERVER
no funciona para accesos concurrentes porque no esta escrito para eso sino para ciertas tareas como probar los aplicativos ( los desarrolladores ) ya que tiene muchas caracteristicas de la parte server ( funciones ), la he usado con pequeñas empresas con unos 3 puestos de trabajo que no requieran mucha concurrencia en operaciones y lo he usado hasta con 5 usuarios y ha funcionado
Advantage Database server trabaja con accesos de la misma forma que cualquier rdbms ( en eso no soy experto ) por lo que los accesos a las tablas los maneja muy bien con 300 usuarios concurrentes solo una vez tuve un problema pero fue porque hubo cortocircuito
Charly me envío unas rutinas para probar concurrencia ya las instale y estoy en espera que el haga sus pruebas ya comentare
un abrazo a todos
cualquier duda a las ordenes
Wilson
pd: adjunto una prueba de insertar 100 registros a ese server desde un programa Harbour OJO es un server muy pequeño con poca ram ( 8GB) y windows 12 y ademas atiende par de empresas con escritorio remoto ( estamos en fase de pruebas ) en programa corre de forma remota

[charly]

Hola,

He lanzado la prueba de concurrencia contra netio, de 100 peticiones con 5 concurrentes

Código: Seleccionar todo

Document Path:          /pre/apptruck/concurrency
Document Length:        8 bytes

Concurrency Level:      5
Time taken for tests:   30.830 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      18300 bytes

Saludos.
C.