Vserver: prueba de stress

Después de leer este verano las pruebas de stress que se han realizado a los distintos bancos para ver si eran capaces de superar las crisis, se me ocurrió plantear una prueba del mismo tipo con el vServer.

La idea es sencilla. Crear una aplicación con una sola tabla pero con un número grande de registros y someterla a unas cuantas pruebas sencillas y ver cómo se comportaba.

Para ello creé una aplicación con las siguientes tablas

  • NAMES: tabla a la que importé nombres de personas. Indices Código y Nombre
  • APELLIDOS :  en ella importé un listado completo de apellidos. Indices Código y Nombre
  • PERSONAS:  la tabla con la que realicé las pruebas. Inices Código, Nombre, Palabras y Trozos

Un demonio llamaba a un proceso que daba de alta 3000 registros de cada vez en la tabla PERSONAS, escogiendo aleatoriamente , un nombre propio y dos apellidos.

Tras dejarlo cargado en el vServer unas 26 horas, se habían generado 4.689.000 registros.

Ficha técnica de la prueba

HARDWARE Y S.O.

Pentium Dual Core a 2,5 GHz y con 4 Gb de memoria RAM

Microsoft Windows Server 2003 standart edition  service pack 1

vServer versión 6.3.9

Registros en la tabla: 4.689.000

Tamaño del archivo .dat :     609.022 Kb

Tamaño del archivo .idx:  1.538.008 Kb

Realicé siempre las mismas pruebas:

  1. Búsqueda por código. Sencillo ,simplemente cargar la lista en pantalla con la opción de menú Búsqueda
  2. Una vez tenía el resultado anterior, reordenar por código
  3. Una vez ordenada por código, reordenar por Nombre

Además, realicé el paso 2 y el 3 una segunda vez sin cerrar el vClient, para ver si el comportamiento mejoraba tras las primeras ordenaciones.

Los resultados fueron estos

1. Búsqueda por código:   8 seg.

2. Reordenar por código: 1ª vez 8 min 40 seg    2ª vez 45 seg.

3. Reordenar por nombre: 1ª vez 12 min 15 seg    2ª vez 37 seg.

Tras estas pruebas, hice una regeneración de índices de la tabla que tardó en finalizar  5 min y 32 seg. Con ello esperaba una mejora significativa en los tiempos de las pruebas pero los resultados no produjeron mejoras dignas de mención.

ACTUALIZACION

Repetida la prueba en remoto, con el navegador atacando la aplicación en el vServer desde otro equipo

  1. Búsqueda por código  1 min 35 segundos
  2. Reordenar por código: 42 minutos 30 segundos.

NUEVA ACTUALIZACIÓN A 30-8-2010.

Prueba en local.

Siguiendo la sugerencia de Paco, he reducido el campo código a numérico de 3 cifras con los siguientes resultados

  1. Búsqueda por código:  8 segundos
  2. Reordenar por código: 7 minutos 3 segundos

Prueba en remoto

  1. Búsqueda por código : 1 minuto 5 segundos
  2. Reordenar por código: 40 minutos 5 segundos

    Nuevos tamaños de los archivos:

    • personas.dat    595.284 Kb
    • persona.idx  1.094.204 Kb
    Anuncios

    Acerca de Agustin
    Velneoadicto. Tuve la grandísisma suerte de que me enseñaran los más grandes: Juan Muñoz-Cobos , Jesús Arboleya y Jesús Inclán..

    15 Responses to Vserver: prueba de stress

    1. fernando says:

      Ahora hay que hacer lo mismo con 7.4

    2. Francisco Hoyos says:

      Ahora habría que hacer una nueva prueba. Quitar los índices de la tabla (salvo el Código, claro) y tratar de dar de alta los 4.689.000 registros de un tirón, sin el uso de un demonio. Si el proceso no rompe, sería interesante comprobar la diferencia de tiempo empleado. Sospecho que será muy inferior. Y en la práctica interesa hacerlo así y luego añadir los índices para que los regenere en 5 minutos. ¿No creeis?

      • agustin says:

        La prueba no está pensada para saber en cuánto tiempo generaba las fichas sino para comprobar cómo maneja los datos con tablas con muchos registros, ver lo que tarda en cargara la lista con una búsqueda por código y luego reordenarla.
        Hace tiempo hice una prueba aún más redical con 56 millones de registros y la búsqueda por código tardaba en cargarse una eternidad. Y eso en la misma máquina. Probada desde otra máquina, ni devolvía una rejilla.

    3. Francisco Hoyos says:

      Estaría bien saber algunos datos técnicos de la segunda prueba. ¿Red local o remota? En caso de ser remota, velocidad de subida y bajada. Y para terminar, tiempo invertido en una segunda ordenación (debería coincidir con la primera prueba).

    4. Agustin says:

      Remoto : tanto en la red del vServer como en la del navegador red de telecable con 30 Mb con 1,3 de subida.

    5. fernando says:

      me llama mucho la atención la diferencia de tiempos en local y en remoto…

      ¿cómo está hecho el mapa?

      ¿es solo una búsqueda y nada más? (se supone que debería hacerlo el servidor y devolver solo resultados)

    6. Francisco Hoyos says:

      La búsqueda devuelve los registros que se visualizan en la pantalla (rejilla) y el índice completo declarado en la búsqueda. Ahí radica el problema. Son 4.689.000 códigos que tiene que devolver al cliente y debe hacerlo por medio de infinidad de paquetes tcp que tardan una barbaridad. Es sólo una sospecha, claro.

    7. Agustin says:

      Fernando : la estructura del mapa es más sencilla que el mecanismo de un chupete.
      La búsqueda es una búsqueda de la tabla por el índice código, nada más.

    8. Francisco Hoyos says:

      Voy a ponerme ‘fisno’. Ese código es numérico de 3 o de más dígitos??? Si es de más, ajústalo a 3 y vuelve a realizar la prueba. Deberían de bajar los tiempos.

    9. Agustin says:

      Voy a hacerlo, Paco, y os informo.

      • Mgalvezh says:

        Hola, Agustín, creo que sería bueno ver esa misma prueba en V7, principalmente en la nube, buen trabajo.

        Saludos cordiales.
        Miguel.

        • agustin says:

          Ánimo. Al que quiera le paso las tablas de nombres y apellidos en .txt para que las exporte y haga la generación de personas.

    10. Francisco Hoyos says:

      Jopé, baja bastante la reordenación, pero lo más sorprendente es la reducción del tamaño del archivo idx.

    11. Basset says:

      ¿porqué tarda menos un proceso, si al principio de este se carga la tabla a utilizar?
      ¿que se puede hacer para mejorar velocidad teniendo registros de más de 100 campos?

      • Francisco Hoyos says:

        !.- Cuando lees una tabla, Velneo guarda los datos en la memoria del programa puesto de trabajo (la famosa caché). El resultado es que cuando se vuelve ha solicitar un dato de la tabla, en vez de volver a acceder al disco, accede a la memoria interna y por ello se agiliza muchísimo el acceso a datos.

        2.- Si la tabla no tiene demasiados registros, leerla al comienzo de la aplicación no es mala política, pero eso dependerá del tamaño de la tabla y, por supuesto, del tamaño de la memoria disponible.

        Un saludo.

    Responder

    Introduce tus datos o haz clic en un icono para iniciar sesión:

    Logo de WordPress.com

    Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

    Imagen de Twitter

    Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

    Foto de Facebook

    Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

    Google+ photo

    Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

    Conectando a %s

    A %d blogueros les gusta esto: