Entradas

Mostrando las entradas etiquetadas como benchmark

Azure SQL Database DTU Calculator en español

Imagen
Si has llegado a esta entrada es porque tienes una base de datos SQL Server que quieres (o piensas) migrar a Azure SQL Database y deseas saber cuales de los planes tendrías que elegir para ello, y sobre todo, cuanto tendrías que invertir. Si es así estas en el sitio correcto. Azure dispone de 3 planes de alojamiento: Azure SQL Database, Elastic Database y Azure SQL Data Warehouse ; en esta entrada me centraré en los dos primeros.  Cuando migras a la nube de Microsoft desde tu plataforma local (on premise) debes olvidarte de cores y RAM, lo importante son las unidades de rendimiento de base de datos o en sus siglas en inglés DTU, una equivalencia aproximada sería: 1 DTU = 1 transacción por segundo. ¿Cómo calcular cuántas DTU necesita mi base de datos?  Muy sencillo, existe una herramienta para ello llamada  Azure SQL Database DTU Calculator  donde te descargas un script PowerShell que monitorizará durante una hora tu consumo de CPU, las lecturas ...

Eliminar muchas carpetas vacías en Windows

Imagen
Cuando digo muchas digo miles, imaginad un disco duro con más de un millón de carpetas y de ellas vacías más de la mitad, es mi caso. La herramienta que he utilizado se llama Remove Empty Directories y hace exactamente eso, a vosotros os tocará juzgar si es rápido o no. La máquina dónde se han realizado las pruebas es un Windows Server 2008 R2 Standard SP1 x64, con 2 cores Intel Xeon E5620 2.4GHZ y 16 GB de RAM. En la siguiente tabla os dejo los tiempo que ha tardado en mi caso al identificar y luego borrar todos los directorios vacíos. Recomiendo en la opciones de la aplicación borrar directamente los directorios en vez de enviarlos a la papelera. carpetas vacías identificar borrado tiempo carpetas/s tiempo carpetas/s 1001465 468318 0:07:40 2177,10     977874 444727 0:07:15 2247,99 11:36:54 10,64 534612 6807 0:02:30 3564,08 0:10:39 10,65 527822 ...

PHP rendimiento curl vs file_get_contents

Una de las opciones para mejorar la seguridad de nuestro código que planteaba en el post asegurar php desde el archivo de configuración era la de evitar que archivos remotos pudiesen ser abiertos o incluidos desde nuestro código fuente, también comentaba que una de las consecuencias directas era la imposibilidad de utilizar file_get_contents para abrir urls. Después de realizar varias pruebas internas utilizando ambas instrucciones para obtener un json de una página externa a mi sitio veo que no solo es en seguridad que ganamos sino en rendimiento, desde mi código he podido constatar que utilizar curl es de media un 30 % más rápido que llamar directamente a file_get_contents. Haciendo una búsqueda luego de ver estos resultados (que todo sea dicho fueron hechos con una versión de PHP muy antigua la 5.2.1) he encontrado que hay otros usuarios a los que les ha pasado lo mismo y han obtenido resultados muy similares a los míos. La función que utilicé está dentro de una clase con lo cua...

Internacionalización (i18n) con PHP

Cuando trabajamos con un sitio que debe estar disponible en  varios idiomas hay múltiples alternativas para traducirlo en PHP pero todas básicamente se basan en incluir un archivo de idioma y sustituir cada frase por su equivalente. Cuando tenemos que traducir un sitio deberíamos plantearnos seriamente la internacionalización del mismo ¿qué es? Básicamente es no solo traducir el texto sino mostrar fechas y configuraciones regionales según el idioma elegido. La mejor herramienta para esto es la extensión de PHP gettext , herramienta que aún no he probado pero que sospecho tendrá un rendimiento más que aceptable y mucho mejor que el resto de opciones que veremos en este post. Lo único malo de esta librería y precisamente será lo que garantice su rendimiento es el uso de la cache para almacenar los idiomas con lo cual cualquier actualización requeriría un reinicio de apache, cosa que en muchos casos no es viable salvo que tengamos un servidor dedicado. Os prometo que intentaré imp...

Nuevas funcionalidades en PHP 5.5

Una vez que hemos visto todas las ventajas que nos puede traer PHP 5.4 y sabiendo que esta no es la última versión estable sería interesante ver cuáles son las ventajas de esta para una vez decididos migrar optemos por una u otra. Generadores Una de las necesidades de programación más comunes, es ser capaz de realizar una acción sobre todos los elementos de un objeto. Por ejemplo, usando un foreach en una matriz, para obtener cada clave o, un foreach sobre un objeto, para obtener el nombre de cada parámetro y su valor. El mecanismo para la aplicación de este comportamiento es conocido como un iterador, que se utiliza para recorrer todos los elementos de un objeto o una matriz. Los iteradores se pueden definir de forma explícita con clases personalizadas, pero eso puede ser un proceso difícil de manejar y complejo, con apaños y, más que un puñado de funciones. ¿Qué pasa si quiero actuar en un subconjunto de una matriz, y realizar algo de lógica a medida que avanzo, pero aún así ser...

¿Por qué actualizar a PHP 5.4?

Imagen
Como hemos visto en el post anterior sobre la evolución de las distintas versiones de PHP 5 , PHP 5.3 es la versión más utilizada en la web aún cuando lleva sin tener una actualización desde diciembre del pasado año y estar en el mercado 2 versiones estables y superiores a ella. He elegido PHP 5.4 por los escépticos, porque es una versión estable y consolidada, con un desarrollo que se inició con el primer lanzamiento de la alpha 1 en junio de 2011 y que tras casi un año de pruebas lanzó su versión inicial para entornos de producción en marzo de 2012, una versión todavía con soporte por parte de PHP y que su ultima actualización ha sido este mismo mes de mayo con la versión 5.4.28. Muchas de las mejoras en PHP 5.4 no son algo que se pueda ver. No son algo que ni siquiera uno se daría cuenta mirando la página de novedades en el manual de PHP . En el centro de estos cambios está la optimización del tiempo de ejecución y una base de código más limpio en general. Si vemos el manual de PH...

Optimizando MySQL 5.6 innodb_buffer_pool_size

Imagen
Uno de los parámetros de configuración que hablé en el artículo anterior era innodb_buffer_pool_size , como su nombre indica es el buffer de almacenamiento de innodb, mientras mayor sea este valor menores serán las lecturas y escrituras en el disco duro y por consiguiente mayor será la velocidad de las operaciones. Lo único malo es que este buffer va directamente a la memoria RAM con lo cual si es poca tenemos que ajustarnos. El valor por defecto en MySQL 5.6.10 son 100 MB y lo que se recomienda en un servidor dedicado es el 80 % de la memoria RAM, pero bueno siendo MySQL muy pocos utilizamos un servidor dedicado para ello casi siempre compartimos con apache y otros servicios con lo cual lo mejor es ir probando configuraciones hasta dar con la ideal, yo tengo 3 GB de RAM y por ahora he puesto un buffer de 700 MB y no he notado carga en el servidor pero si una mejoría increíble en el acceso a disco. Os dejo las gráficas. Veamos el comportamiento del buffer innodb, nótese el cambio dr...

Aumentar la velocidad de tus páginas web

Si eres desarrollador de páginas web, o administrador de algún sitio web, sin duda una de tus principales preocupaciones es optimizar la carga de las mismas, un tiempo de carga pequeño se traduce en una mejor experiencia de usuario y de cara a los buscadores un sitio de más calidad. Buscando por internet encontré este maravilloso tutorial con unas excelentes y completas técnicas para aumentar la velocidad de una web , aunque para mi lo mejor fueron los enlaces externos al final del mismo y de ellos el más relevante y sobre el que basaré este tutorial es web page test . Cómo bien dice el nombre Web Page Test es un sitio que examina tu página web y te muestra las recomendaciones necesarias para corregir o mitigar cada uno de los fallos que sus test encuentran. Los test se basan en 6 bloques fundamentales: First Time Byte Keep alive enabled Compress text Compress images Cache static content CDN detected Sobre el primer punto el Time to First Byte ya he hab...

Benchmark Apache y MySQL en CentOS

Imagen
Decir que este post es un benchmark en toda regla es muy ambicioso, lo que voy a hacer es compartir los datos que he obtenido en mi caso particular que tal vez puedan ser aplicados a otros casos en los cuales no creo que difieran mucho los resultados globales. Para los que no estén familiarizados con el tema, un benchmark no es más que una comparativa, en este caso será medir el rendimiento de Apache y MySQL luego de una actualización de versiones. Servidor de pruebas de carga: Sistema Operativo: CentOS 5.5 (Final) Versión Núcleo de Linux: 2.6.18-194.17.4.el5 Versión GCC: 4.1.2 20080704 (Red Hat 4.1.2-48) CPU: 4 x Six-Core AMD Opteron(tm) Processor 2423 HE 2009 MHZ RAM: 5 GB Versiones y programas a comparar: Apache 2.2.3 vs. 2.2.8 PHP 5.2.10 vs 5.3.5 MySQL 5.0.64 vs 5.5.8 En el siguiente gráfico se muestra el consumo de CPU durante una semana, la línea roja significa el momento ...

Celtic Kane Javascript Benchmark

Imagen
De los test específicos realizados este es el que me ha aportado unos datos más relevantes además de ser de un grupo independiente no asociado a ningún motor JavaScript de ningún navegador, por tanto la imparcialidad está, como mínimo, más garantizada. La ventaja de este test es que prueba los elementos más básicos de JavaScript y además AJAX, con el cual me llevé la gran sorpresa pues si la prueba de AJAX no se hubiera realizado Safari sería el glorioso vencedor pero por esta  prueba es, aunque suene increíble, el aplastado perdedor, incluso por debajo –y ni yo me lo creo- de Internet Explorer 8. Las pruebas se realizan sobre la mayoría de los objetos de JavaScript: Arrays, Date, Math, RegEx, String; además incluye pruebas sobre el DOM, el manejo de errores y la conflictiva declaración de AJAX. Los resultados son los siguientes: Si hubiésemos eliminado la prueba de AJAX los resultados hubiesen sido totalmente distintos, veamos: El test lo podéis realizar desde aqu...

V8 Benchmark Suite

Imagen
Si el anterior test estaba diseñado por los miembros de WebKit este está diseñado por los miembros de Google Chrome y más concretamente de su nuevo y reluciente motor JavaScript V8, por lo cual está de sobra decir quien se lleva la palma en el mismo. Este test es al contrario de los demás, el que alcance la mayor puntuación es el mejor. La suite V8 consta de 7 pruebas independientes escritas por diferentes programadores y en ellas se basan para optimizar Google Chrome, las pruebas miden desde el propio Kernel del SO hasta encriptación, expresiones regulares y manipulación de datos. La última versión la podemos encontrar aquí junto con una explicación breve (en inglés) y un histórico de las mismas. Los resultados arrojados fueron los siguientes: Recordad que en este test mientras más grande mejor, o sea que aquí el tamaño SI importa. Como aclaración decir que al salir la versión 4 de Safari se dijo que era la más rápida y luego de pasar este test quedó por detrás de Chro...

SunSpider WebKit Benchmark

Imagen
El test SunSpider realiza una serie de pruebas sobre el navegador para saber el tiempo que le toma para procesar ciertas instrucciones, las cuales abarcan: renderizado 3D; acceso a arrays, propiedades de objetos y variables; procesos matemáticos con enteros y punto flotante; control de flujo (bucles, recursión, condicionales); encriptado; performance de objetos "date"; expresiones regulares y tratamiento de cadenas. La fiabilidad de este test ha surgido porque realiza un ciclo de 5 repeticiones de cada prueba y hace una media estadística de estas mediciones además de brindar el porcentaje de error de las mismas. Es un test creado por los desarrolladores de Webkit el motor de renderizado de Safari y también Chrome lo utilizó en sus diseños anteriores por lo que su V8 está basado en Webkit. Está de más decir que es lógico que estos dos navegadores salgan bien parados en esta comparativa. Veamos los resultados: Y esta es la tabla comparativa según los bloques de prueba...

Test Acid3

Imagen
El test Acid3 pone a prueba lo navegadores con los estándares web, especialmente los de DOM y ECMAScript. La parte principal de Acid3 esta escrita en ECMAScript (JavaScript), y consiste de 100 sub-pruebas divididas en seis grupos, llamados "buckets", más cuatro pruebas especiales. El único requerimiento de la prueba es que el navegador tenga la configuración de forma predeterminada. El renderizado final debe mostrar un 100/100 y además no sólo debe ser idéntico al de referencia sino que además la animación debe ser fluida (la prueba en teoría no debe tomar más de 33 milisegundos). Esto son datos sacados de la wikipedia sobre este test, ahora veamos los resultados: Los Navegadores Safari, Opera y Chrome obtuvieron el 100 % la única diferencia fue el tiempo de carga del test siendo en el Safari el más rápido de estos y Chrome el más rezagado, aunque la diferencia no supera los 5 milisegundos.   Nuestro amigo Firefox en su versión 3.6 alcanzó la no despreciable cif...

Pruebas de velocidad en navegadores

Imagen
Desde hace unos días vengo aprovechando en casa para ir escribiendo un pequeño manual sobre nuevas tendencias en JavaScript y por supuesto en él he tenido que hablar de los navegadores y sus respectivos motores de renderizado y motores de JavaScript. Como soy un poco quisquilloso y no se me da fiarme de lo que ponen en las web sobre las ventajas de uno u otro, decidí crearme mi propio sistema para ver, después de varias pruebas, cual era el realmente más rápido de todos. En fin que manos a la obra me puse a googlear y descubrí que existen unos cuantos test para los navegadores y personalmente elegí solo 6, en este post pondré las condiciones básicas en que desarrollé cada una de las pruebas las cuales iré explicando en un post individual y al final pondré unas conclusiones. Equipo Utilizado El ordenador dónde se realizaron las 7 pruebas es un Intel Core 2 Quad a 2,4GHZ con 4 GB de RAM DDR2 bajo el innovador Windows 7 Ultimate en la versión de 64 bits.   Navegadores Tes...