Interneteando

Para realizar las pruebas se ha utilizado una tabla en formato MyISAM con 1753184 registros rellenados con datos aleatorios.

Ambos almacenan datos de tipo cadena, la longitud de que ocupa cada caracter suele ser de 1 byte, exceptuando las cadenas “unicode” que pueden llegar a ocupar hasta 3 bytes por caracter. El tamañó máximo para este tipo de campos es de 256 bytes. En los ejemplos me referiré siempre a letras en vez de bytes para hacer más facil su comprensión.

CHAR: Es un tipo de longitud fija, esto quiere decir que el espacio necesario para su almacenamiento es el mismo para una palabra de 5 letras que para una frase de 20.

VARCHAR: Es un campo de longitud dinámica, es decir una palabra de 5 letras, ocupará el espacio de 5 letras más un caracter de fin de cadena.

Casos de uso.

SELECT campo2 from tabla WHERE campo2 = ‘cadena’;
campo2 => VARCHAR(200) => 1,82 segundos sin indexar => 0,00 indexado
campo3 => CHAR(200) => 1,77 segundos sin indexar => 0,00 indexado

SELECT campo2 from tablal where campo2 like ‘%dena%’;
campo2 => VARCHAR(200) => 3,86 segundos sin indexar => 1,75 indexado
campo3 => CHAR(200) => 1,84 segundos sin indexar => 2,19 indexado

Después de estas pruebas, podemos concluir que CHAR se comporta mejor que VARCHAR en campos no indexados, y que VARCHAR es la mejor opción para campos que si soporten indexación.

A la hora de devolver gran número de resultados VARCHAR también se muestra superior sobre CHAR. Un SELECT con 1000000 de resultados tardó en devolver una columna de tipo char 1,24 segundos. La misma columna en formato VARCHAR tan solo tardó 1,06 segundos.

Hoy leía en el blog de Pichongol un interesante artículo sobre la cache que incorpora MySQL y el uso de Memcached para optimizar la carga de sitios web con gran carga de trabajo, pero creo que no está del todo acertado en algunos aspectos.

En su análisis sobre Sistemas intensivos en lecturas vs. Sistemas intensivos en escrituras, pasa por alto un detalle de gran importancia. Las páginas web (que es lo que nos ocupa), son sistemas en los que se acometen muchas lecturas y pocas escrituras por lo que en el 99% de los casos el uso del query cache será beneficioso. Además siempre se pueden utilizar tablas auxiliares para cierto tipo de operaciones de escritura masiva (contadores,estadísticas,sesiones, etc) y utilizar las extensiones de MySQL INSERT DELAYED y INSERT DELAYED … ON DUPLICATE UPDATE para acometer las actualizaciones en estas tablas sin influir en el tiempo de ejecución del script.

Sobre el uso de Memcached, también se pasa por alto un detalle importante, Memcached puede hacer persistir objetos en memoria para distintas máquinas a lo largo de una red y de esta forma varias máquinas se aprovechan del calculo realizado por una. Si hablamos de instalaciones de un solo servidor, el coste de las funciones serialize y unserialize reducen bastante las ventajas de utilizar Memcached.

Por mi experiencia, Memcached es especialmente productivo para entornos de balanceo de carga y funciona especialmente bien en combinación con Lighttpd+FastCGI.

Llevo utilizando PDT desde sus primeras versiones, y según me iba acomodando, también cambiaba mi forma de programar en PHP.

Antes utilizaba BBedit y ahora utilizo PDT.
Antes utilizaba programación modular y ahora programación orientada a objetos.

Sobre si es mejor la programación modular o la programación orientada a objetos, hay mucha gente más lista que yo ya ha opinado sobre ello así que lo pasaremos por alto.

Ahora bien, si al final decides que tu proyecto en concreto vas a utilizar objetos, el PDT ofrece ciertas ayudas de las que no dispone ningún otro editor de texto que yo conozca. En esta comparativa entre PDT y Zend Studio for Eclipse hay un montón de características que hacen del PDT, la mejor herramienta para la programación orientada a objetos en PHP a falta de probar a fondo el Zend Studio.

Esta transición, me ha llevado a producir un código mucho más entendible, extensible y fácil de mantener, a costa de hacer unos programas con más lentos.

De momento estoy contento con los resultados obtenidos, puesto qué tiempo de procesador me sobra mientras qué mi tiempo de programación escasea cada vez más.

Tengo varios servidores montados con Apache2.2 y en los últimos tiempos venía escuchando maravillas acerca de un nuevo navegador, Lighttpd, pequeño, sencillo y sobre todo muy rápido.

Lógicamente, antes de con un traspaso de esta magnitud decidí realizar una pequeña comparativa. Además llevaba tiempo queriendo probar las diferencias entre eAccelerator, XCache y APC así que me puse manos a la obra y estos son los resultados.

Durante los tests he ido observado como APC arrojaba mejores resultados que XCache y eAccelerator, así que para mis pruebas el mejor “opcode cache” ha sido: APC.
Solo hay una circunstancia en la que APC se ve superado por XCache ligeramente. Al tratarse de páginas sencillas con pocas necesidades de carga y utilizando Lighttpd como servidor. Si vas a utilizar Apache, APC es sin duda la mejor elección.

En cuanto a los servidores, Lighttpd es hasta 2x más rápido que Apache al servir páginas estáticas, sin embargo a medida que vamos aumentando la complejidad de la página el rendimiento de Lighttpd va decayendo hasta quedar ligeramente por debajo del rendimiendo de Apache.

Vamos a los datos…
(more…)

Dropdown es un pequeño script basado en mootools que muestra una ventana de dialogo emergente de la parte superior de la ventana, con un efecto de fundido mediante una petición Ajax a la una dirección.

El uso es muy sencillo, basta con incluir los dos scripts y la hoja de estilos.

<script src="mootools.js" type="text/javascript" language="javascript"></script>
<script src="dropdown.js" type="text/javascript" language="javascript"></script>
<link rel="stylesheet" href="/dropdown.css" type="text/css" media="screen" />

Y luego en la página incluimos un enlace de la siguiente manera:

<a href="/ejemplos/dropdown.html" rel="dropdown">Ejemplo de dropdown</a>

Donde /ejemplos/dropdown.html es la página que queremos mostrar en el dropdown.

Ejemplo de dropdown

El uso de frameworks, ya sea ruby on rails, zend framework, Struts, Spring, etc, según mis pruebas puede provocar que una página que sin Framework se despachaba en 30 ms pase a despacharse en 300 o 400ms. Estos incrementos aunque son aceptables para una aplicación online, no lo son en absoluto para una página web de uso general y por lo tanto tenemos que decidir entre utilizar caches o no utilizar X framework.

En el caso de que hayamos decidido utilizar Zend Framework, existe una implementación que se puede realizar en cuestión de minutos, y es valida para cualquier página web. En principio, bastaría con incluir en el Bootstrap un código similar a este.

/**
 * Cache
 */
require_once 'Zend/Cache.php';

$frontendOptions = array(
   'lifetime' => 7200,
   'debug_header' => false,
   'default_options' => array(
		'cache' => true,
		'cache_with_get_variables' => true
    ),
   'regexps' => array('/*' => array('cache' => true))
);
$backendOptions = array(
    'cache_dir' => '/tmp/cache'
);

// getting a Zend_Cache_Frontend_Page object
$cache = Zend_Cache::factory('Page', 'File', $frontendOptions, $backendOptions);

$cache->start();

Es recomendable incluir este código al principio del BootStrap puesto que solo necesita que la ruta a la librería del Zend Framework este correctamente configurada.