Blog

Etiqueta: hosting hyperv

WordPress: mysql y soluciones de cache

Publicado en Desarrollo web Nuestros servicios Sistemas TI en febrero 26, 2010 1:43 pm

Hace algunos días me resultó interesante el debate que se formó en torno a un post en Loogic, en el cual se hablaba de la problemática de tener cuello de botella en el backend de base de datos de una aplicación web.

Desde nuestra experiencia podemos decir que no es tanto culpa de la base de datos el que ocurran estos problemas, sino de la programación en la aplicación web o una mala o desatendida gestión en la base de datos y configuración del servidor.

En muchas ocasiones se suele comentar que un cms tiene una muy mala gestión de consultas sobre la base de datos que utiliza, que abusa de ellas o incluso que hace auténticas chapuzas. En algunos casos puede ser cierto, en otros como en el caso de WordPress mayormente esas afirmaciones radican en un desconocimiento técnico en cómo funcionan realmente esta herramienta y qué cuidados requiere las misma.

WordPress

Si bien es cierto que podemos ahorrarnos muchas consultas a la base de datos desde WordPress evitando el uso de algunas de sus Template Tags (funciones que ayudan a crear themes) o plugins que hacen consultas que wordpress ya hace previamente desde su core, esto puede ser totalmente ineficaz si por ejemplo no tenemos especial cuidado en la gestión de la base de datos.

Deshabilitar el motor innodb o los logs del servidor pueden ahorrarnos mucha carga en el servidor, pero no nos libra de tener que hacer una optimización en los valores de query_cache por ejemplo.

Es importante también prestar especial atención en la actualización del propio cms, ya que puede efectuar cambios en el esquema de base de datos, pero mantener funcionalidad obsoleta por compatibilidad, especialmente con plugins o funciones que se puedan seguir usando.

Plugins como WP SuperCache, basado en WP Cache 2 de Gallir (en el antiguo blog de Gallir encontramos una descripción de cómo funciona y actúa WP-Cache 2), son imprescindibles para reducir los accesos de datos a mysql. Pero en algunos casos hemos encontrado problemas debido a malas actualizaciones de WordPress que se llevaban arrastrando varias versiones atrás.

En un caso concreto nos hemos peleado con algún wordpress que hacía consultas antes de lanzar la acción init, que es la acción que activa plugins como WP SuperCache. Esto hacía ineficaz toda posibilidad de cacheo a través de plugins.

Podríamos evitar esta situación cacheando todo el sitio en archivos estáticos html, en memoria a través de módulos memcached a nivel de servidor web, usando sistemas de proxy caché tipo Squid o infinidad de soluciones más. Personalmente creo que este tipo de cosas hay que hacerlas después de asegurarse que la parte de la aplicación web está optimizada o al menos no abusa demasiado de la base de datos. Más que nada porque este tipo de soluciones conllevan una serie de costes asociados, por ejemplo si optamos por cachear todo a disco necesitaremos, en sitios web con medio o alto tráfico, disco SAS a 10k o 15k revoluciones para evitar los cuellos de botella que tendríamos con discos SATA. Muchos proveedores venden esto como “un servidor más grande”, nosotros preferimos abordarlo de otra forma. Evidentemente tiene más sentido optar por soluciones basadas en memoria, como memcached, pero no disponemos de estas opciones en todos los entornos.

Hay otras situaciones en las que un sólo plugin puede ser el culpable de problemas de rendimiento. Muchas veces se confía demasiado en el buen hacer de los desarrolladores de plugins muy utilizados como el All In One Seo Pack, que resulta no ser tan óptimo como cabría esperar.

Nosotros en Blackslot empezamos por hacer un diagnóstico de la aplicación web, en el caso de basarse en wordpress limpiar el theme y el sitio web de funciones y plugins desactualizados, comprobar el buen estado de la base de datos para el CMS en cuestión, desarrollar plugins o themes que utilicen la última versión de la api y si fuese necesario buscar soluciones a nivel de sistema que mejoren el rendimiento de la aplicación.

Estas soluciones pueden ser desde realizar optimizaciones del servidor web y la base de datos, implantar soluciones de cache en memoria, opcode cache para php, distribuir el contenido estático del blog entre varios servidores o servicios de terceros (cloud o no, dependiendo de los requisitos del cliente) hasta soluciones más avanzadas para sitios web de gran cantidad de datos y tráfico.

No siempre una solución puede ser la cura a todas las enfermedades. Se suele escuchar por ejemplo que un tipo de motor de almacenamiento en mysql frente a otro, como el caso de myisam frente a innodb, es más rápido en lectura pero esto no siempre es así. También se pueden ver casos como que una solución memcached de menos rendimiento que algún otro tipo de servidor de base de datos, o frecuentemente que cachear en disco penalice mucho más que almacenar en la base de datos. No se pueden tratar todos los casos por igual en problemas de rendimiento web.

Por lo general hemos tenido alguna experiencia con clientes que teniendo un servidor dedicado saturado con prestaciones no precisamente moderadas, hemos podido migrarles a uno de nuestros servidores HyperV R2 con Linux ahorrándose, con sólo algunos cambios en su cms y últimas versiones en tecnologías de servidor, bastante dinero en hardware al mes.

Virtualizando SQL Server 2008 sobre Hyper-V R2

Publicado en Sistemas TI en febrero 10, 2010 9:12 am

Unos rápidos apuntes a tener en cuenta a la hora de virtualizar un entorno SQL Server.

Discos:
- De espacio fijo: En SQL Server es muy importante el I/O de los volúmenes con los que se trabaja, por ello la recomendación es utilizar siempre discos fijos.
- Controladora SCSI: Al igual que sucede en entornos físicos, en virtual sólo podremos colocar hasta 4 discos IDE, por lo que si necesitamos más discos lo mejor es utilizar un bus SCSI.
- Usar varios VHD: Es decir, uno para el propio sistema y los archivos de instalación de SQL, otro para tempdb, otro para los logs, otro para los datos… Esto al igual que en un entorno real permite mejorar el I/O, sobre todo si disponemos de una cabina y dedicamos discos separados (spindles) o LUN para mejorar aún más el I/O. Aún cuando no dispongamos de discos separados sigue siendo recomendable utilizar diferentes VHDs.
- Sistema de archivos: NTFS con unidad de asignación a 64 K para obtener mejor rendimiento.

Red:
- Importante que la red sea Gigabit y la velocidad esté configurada en full-duplex.
- Siempre usaremos los adaptadores sintéticos que usan los Servicios de Integración instalados en la VM para funcionar, ya que ofrecen mucho mejor rendimiento que los emulados, los cuales sólo son útiles por razones de compatibilidad en sistemas que no soportan los Servicios de Integración (anteriores a MS Windows Server 2003 R2, kernels de linux no soportados, etc…).
- Si es posible usar teaming para mejorar el rendimiento y ofrecer redundancia, sobre todo para conexiones a una cabina vía iSCSI.

Memoria:
La memoria se comporta exactamente igual que en una máquina física, a diferencia de otros hypervisores en Hyper-V no se permite el sobreuso (aunque MS ya está trabajando en ello) por lo que la cantidad asignada a una VM se reserva en el anfitrión por completo. Es importante dejar al propio nodo anfitrión 2 GB libres para el sistema y sus tareas.

Obtener el nombre de una máquina HyperV desde la propia máquina HyperV

Publicado en Sistemas TI en enero 3, 2010 8:08 pm

A veces nos puede resultar útil obtener el nombre de la máquina hypervirtualizada desde la misma.

Lo podemos solucionar con este código powershell:


$Name = Get-ItemProperty -path "HKLM:SOFTWAREMicrosoftVirtual MachineGuestParameters" -Name VirtualMachineName

$Name.VirtualMachineName