Similar Posts

Pruebas de rendimiento en MySQL

ByLuis

Algo muy importante en cualquier desarrollo web son las pruebas de rendimiento, con ellas podremos prever cuales son los límites de nuestro sistema, ya sean a nivel de software o hardware. Las bases de datos deben ser algo fundamental en estas pruebas.

En el caso de MySQL, existe una herramienta disponible desde la versión 5.1.4 que nos permite realizar estas pruebas. mysqlslap es un programa de diagnóstico diseñado para emular la carga de un cliente para un servidor MySQL y ofrecer informes para cada estado. Funciona como si múltiples clientes accedieran a nuestro servidor.

mysqlslap [opciones] nombre_base_datos

Da la posibilidad de que las sentencias SQL se generen automáticamente, pero para unas pruebas correctas de rendimiento se deberían usar las sentencias que ejecuta nuestro sistema. Para lo cual recomiendo sacar por trazas las sentencias en un fichero y usar luego este fichero para simular a un usuario.

Hay que tener en cuenta que cuando lee un fichero usará para delimitar las queries el retorno de carro, por lo que cada query deberá ir en una única línea, aunque se puede usar la opción –delimiter para indicar la cadena delimitadora.

Son también importantes los campos –concurrency e –iterations, el primero indica el número de clientes simultáneos, y el segundo las veces que se ejecuta la prueba.

También es recomendable usar la aplicación jMeter para realizar nuestras pruebas.

|

Crear documentos OpenDocument con PHP

ByLuis

OpenDocument es un paquete PHP para generar, modificar y leer documentos en formato Open Document. Aún existe la costumbre de exportar la información a documentos con formato propietarios, ya sean de Microsoft o de Adobe, mientras que Open Document es un estándar.
Inicialmente fue un proyecto del Google Summer of Code 2006 Program que ahora a pasado parte del PEAR, en fase poco avanzada, la documentación no es la gran cosa, pero tres ejemplos que ofrecen en el paquete pueden ser suficientes para ir empezando.
OpenDocument para PHP

10 consejos para MySQL

ByLuis

Buenos consejos a tener en cuenta:

  • Ponle contraseña al usuario root y luego cámbiale de nombre: lo más normal es ponerle contraseña al usuario root, pero no nos sorprendamos si vemos un root sin password o con algo tan ridículo como root_1. Lo que si no se suele hacer mucho es cambiar el nombre al root y eso es una buena idea que habría que tener siempre en cuenta… pero que tampoco sea admin (como dice el artículo), sino algo más difícil de adivinar.
  • Oculta MySQL de Internet: MySQL no necesita estar accesible desde Internet, por lo que mejor evitar esa posibilidad.
  • Protege el directorio de instalación de MySQL de otros usuarios
  • No almacenes datos binarios: que MySQL lo permita no quiere decir que sea lo mejor hacerlo. MySQL envía los datos de una única vez, esto implica que hasta que no se envíe el campo completo, la aplicación no puede parsear la información. Es preferible almacenar los datos en el sistema de ficheros y almacenar en la BD un ruta hasta el fichero. Aunque yo casi recomendaría guardar en la BD una clave, para que mediante una lógica en la aplicación se pueda recuperar la ruta, así, si tenemos que modificar la ruta no tenemos que modificar todos los registros de la BD, tan solo la lógica del programa.
  • Usa SQL standard: MySQL ofrece posibilidades que no son del SQL estándar y que pueden aportarnos muchas ventajas, el problema es que nos limita a exportar nuestra aplicación a otras BD si en un futuro lo necesitamos. La solución es no ejecutar esas sentencias directamente, sino mediante una clase, que extienda de una clase genérica, así podremos simular esas funcionalidades de MySQL en otras BDs creando otras clases para cada motor de BD.
  • Crea tu propio generador de auto_increment: el auto_increment nos crea números consecutivos que podemos usar en nuestras tablas, pero con limitaciones, solo existe un auto_increment por tabla y son independientes de las tablas, por lo que distintas tablas pueden tener mismo id, lo cual puede no convenirnos en algunas circunstancias.
  • No mezcles código de presentación con el de acceso a BD: es el sistema MVC que siempre debemos usar.
  • Normalización y denormalización: la normalización nos permite tener una BD sin datos redundantes. Desafortunadamente, a veces esta pena el rendimiento, para lo cual, una vez normalizada la BD es conveniente denormalizarla.
  • Usa un pool de conexiones en el servidor Web o en el servidor de aplicaciones: la conexión a la BD es algo costoso, si compartimos conexión mediante un pool, ganaremos en rendimiento.
  • Mejoras tus queries con EXPLAIN SELECT: aunque es un comando difícil de seguir, nos puede ayudar mucho.

Ten MySQL Best Practices

Vía / Sheeri Kritzer Cabral

Marjory: webservice para indexar y buscar documentos

ByLuis

Marjory es un webservice que nos ayuda a indexar y buscar documentos realizado en PHP. Utiliza la búsqueda fulltext aunque también está disponible la búsqueda mediante Lucene (en un futuro pretenden sacar más).
No utiliza protocolos XML-RPC o SOAP, usa una interfaz REST para comunicarse con las otras aplicaciones. Aunque no estaría mal respuestas en JSON.
Está realizado con Zend Framework y usa la librería para Lucene como motor de búsqueda por defecto.
Marjory

Simular paquetes en PHP

ByLuis

Interesante script que nos permite cargar paquetes al estilo Java desde PHP. Aunque ya existen los phar, que es un paquete de PHP, esto puede resultar una posibilidad o al menos un método a tener en cuenta para importar varios archivos simultáneamente.

read())) 
        {
            /* Reject parent, current directories and sub directories */
            if(($file == '.')  ||
               ($file == '..') ||
               (is_dir($d->path . "/" . $file)))
            {
                continue;
            }
 
            require_once($basePath . $importFilePath . "/" . $file);
        }
    } else {
        /* If a single file is specified */
        $importFile = str_replace(".", "/", $classPath) . ".php";
    	require_once($basePath . $importFile);
    }
}
 
?>

Simulating Packages in PHP

2 Comments

  1. Voy a parecer la mosca cojonera del blog, pero aún así:
    Se ha estado hablando mucho de los acortadores de URLs. No son buenos.
    -aportan un nuevo punto de fallo
    -ocultan la dirección final (no sé donde me estoy dirigiendo, podría ser un sitio con fama de contener virus y otro software dañino)
    en caso de que se den de baja ( http://tr.im ) lo intentó hace poco y armó una buena en la blogosfera obligándoles a rectificar
    -resulta innecesario su uso en la mayoría de ocasiones y, como se indica en varios sitios, lo correcto es una de las siguientes dos opciones:
    1) que cada sitio se gestione sus propias URLs cortas de forma que si el sitio se da de baja también se pierden las URLs cortas, pero al menos ya depende de un punto de fallo (la página en la que se publican).
    2) que los sitios más importantes empiecen a ofrecer el servicio de URLs cortas como permalinks a los artículos. Si el script publicado aquí tiene esa finalidad, perfecto, ese sería el camino a seguir.

  2. Estoy de acuerdo con alsanan, y añado otro argumento: el rendimiento. Una redirección extra significa más tiempo de espera y mayor carga para las conexiones y servidores. De hecho, la existencia de los acortadores sólo tiene sentido por cosas como Twitter –lo cual me parece una estupidez porque bien podía Twitter permitir poner enlaces sin ser necesario poner la URL en el texto del mensaje–, y de hecho yo ya he visto ejemplos donde se utilizan acortadores para ocultar el verdadero destino del enlace (publicitario).

    No obstante, si se van a usar acortadores de URL, mejor que sean scripts conocidos y libres como el que presenta el post.

    Un saludo.

Comments are closed.