Servidor JPEGmini

Después de que tuve la oportunidad de probar y revisar el software JPEGmini Pro , me di cuenta de lo poderoso que es este software no solo para exportar imágenes y ser parte de un flujo de trabajo de Lightroom , sino también para muchos otros usos, incluida la optimización de imágenes que ya están en nuestro grandes dispositivos de almacenamiento. Otro uso que pensé de inmediato fue el servidor web desde donde se origina el tráfico de Photography Life. Dada la cantidad de tráfico que PL atiende en todo el mundo día a día y el hecho de que las imágenes por sí solas representan aproximadamente 5 Terabytes de tráfico por mes, la idea de poder comprimir imágenes JPEG usando el motor JPEGmini era algo que realmente quería. implementar más temprano que tarde. Así que me embarqué en un nuevo proyecto: ahorrar tanto tráfico como dinero a largo plazo para PL, usando elServidor JPEGmini .

Cuidado con los fotógrafos: esta es una revisión muy técnica de un software que no está relacionado con la fotografía. Decidí publicar la revisión en PL, ya que siento que otros sitios web con muchas fotografías podrían beneficiarse enormemente de la implementación del servidor JPEGmini.

1) Descripción general del entorno del servidor

Antes de entrar en la revisión, me gustaría señalar algunos fragmentos de información potencialmente importantes sobre la configuración de mi servidor web. En primer lugar, ejecuto CentOS Linux en todos los servidores (y hay algunos). Los dos servidores web back-end que manejan las llamadas PHP desde el balanceador de carga es donde instalé el servidor JPEGmini, aunque solo el primero realmente importa, ya que es el que maneja todas las cargas al sitio (WordPress no puede manejar esto directamente, así que solo es posible observar las llamadas de wp-admin y dirigirlas al servidor apropiado a través de nginx/apache). Desafortunadamente, no hay una manera fácil de ejecutar más de un servidor de WordPress sin problemas de carga de archivos, ya que no está diseñado para usarse en un entorno de clúster (mover todo a AWS con instancias de servidor en ejecución EC2, RDS ejecutando DB y S3 manejando los archivos sería una buena solución, pero después de probarlo, no fue una solución barata de ninguna manera, especialmente una vez que comienza a generar algunos servidores EC2 que manejarían la carga de back-end) . Por lo tanto, he estado sincronizando todas las cargas a través de rsync. No es una solución elegante, pero funciona bastante bien. Tengo rsync monitoreando la carpeta "wp-content", por lo que todos los cambios se replican de una manera (básicamente, una vez que las imágenes se cargan en el servidor01, el servidor02 las recoge automáticamente). La sincronización tarda uno o dos segundos, pero una vez que sucede, las imágenes se sirven fácilmente para cargar las solicitudes del balanceador. No es una solución elegante, pero funciona bastante bien. Tengo rsync monitoreando la carpeta "wp-content", por lo que todos los cambios se replican de una manera (básicamente, una vez que las imágenes se cargan en el servidor01, el servidor02 las recoge automáticamente). La sincronización tarda uno o dos segundos, pero una vez que sucede, las imágenes se sirven fácilmente para cargar las solicitudes del balanceador. No es una solución elegante, pero funciona bastante bien. Tengo rsync monitoreando la carpeta "wp-content", por lo que todos los cambios se replican de una manera (básicamente, una vez que las imágenes se cargan en el servidor01, el servidor02 las recoge automáticamente). La sincronización tarda uno o dos segundos, pero una vez que sucede, las imágenes se sirven fácilmente para cargar las solicitudes del balanceador.

Todas las llamadas del servidor web son manejadas por un balanceador de carga, que solo atiende el tráfico web https. Todas las imágenes son manejadas por un CDN externo. La razón principal para implementar JPEGmini fue reducir los costos de CDN, que solo aumentan cada mes a medida que continuamos publicando más contenido.

Tenga en cuenta que su servidor web debe ejecutar una versión de Linux: el servidor JPEGmini no se ejecuta en servidores Windows. Aquí está la lista de plataformas de servidor compatibles.

2) Instalación del servidor JPEGmini

La instalación del servidor JPEGmini es muy fácil, especialmente si ejecuta RHEL, CentOS y otras distribuciones populares de Linux. Para mi servidor CentOS, JPEGmini proporcionó un archivo RPM, por lo que fue fácil de instalar con un solo comando. Una vez que se instaló el archivo binario (/usr/bin/jpegmini por defecto), el siguiente paso fue copiar el archivo de licencia .jpegmini.cfg en el directorio de inicio del usuario. A partir de ahí, ejecutar "jpegmini" debería generar algo como lo siguiente:

===============================
Iniciar jpegmini 3.14.2.84235
============== =================
Se requiere la opción -f: -f=<nombre de archivo jpeg>
Use -help para obtener ayuda

===============================
Terminar jpegmini 3.14.2.84235
============== =================

Mi prueba inicial comenzó con la versión 3.13 del servidor JPEGmini, pero después de algunos cambios solicitados en el ejecutable, JPEGmini proporcionó un archivo RPM 3.14 actualizado. La principal adición a la versión 3.14 es la capacidad de omitir archivos ya optimizados, lo cual fue un gran problema para mí, ya que uso la versión de escritorio del software y no quería que el servidor JPEGmini volviera a optimizar las imágenes JPEG cargadas.

3) Manejo de archivos de imagen de WordPress

Cuando se carga una imagen en WordPress, los scripts de administración usarán GD o ImageMagick para procesar esas imágenes. De forma predeterminada, WordPress crea imágenes de tres tamaños, además de la imagen cargada (miniatura, tamaño mediano y tamaño grande), pero dependiendo de cuántas llamadas add_image_size puedan agregarse por el tema y los complementos, ¡puede haber muchas más! Debido a esto, la carga de una sola imagen podría generar un montón de archivos en el servidor, lo que permitiría que la carpeta Cargas creciera muy rápidamente. Y esas imágenes más pequeñas son creadas por GD o ImageMagick, por lo que los archivos de forma predeterminada no tendrán perfiles de color ICC ni datos EXIF, lo cual no es deseable en un sitio web de fotografía. Tampoco van a estar correctamente optimizados para el tamaño, ya que ni GD ni ImageMagick tienen un algoritmo inteligente como JPEGmini para poder comprimir correctamente las imágenes JPEG. De hecho, WordPress hace un trabajo bastante horrible al cambiar el tamaño de las imágenes, lo que a menudo da como resultado imágenes con colores deficientes (debido a la eliminación de perfiles ICC), imágenes suaves y turbias (debido a la fuerte compresión). Para evitar este problema en PL, solo he estado usando ImageMagick para optimizar imágenes, con opciones especiales. Solo eliminamos los datos EXIF ​​de las miniaturas y los comprimimos un poco más agresivamente para una experiencia de navegación rápida. Una vez en una publicación, ni los perfiles ICC ni los datos EXIF ​​se eliminan de las imágenes más grandes para que se vean lo mejor posible. De esta manera, no obligamos a nuestros lectores a hacer clic en una imagen para ver la "versión correcta": las imágenes se ven consistentes desde las vistas previas hasta los tamaños nativos cargados. WordPress hace un trabajo bastante horrible al cambiar el tamaño de las imágenes, lo que a menudo da como resultado imágenes con colores deficientes (debido a la eliminación de perfiles ICC), imágenes suaves y turbias (debido a la fuerte compresión). Para evitar este problema en PL, solo he estado usando ImageMagick para optimizar imágenes, con opciones especiales. Solo eliminamos los datos EXIF ​​de las miniaturas y los comprimimos un poco más agresivamente para una experiencia de navegación rápida. Una vez en una publicación, ni los perfiles ICC ni los datos EXIF ​​se eliminan de las imágenes más grandes para que se vean lo mejor posible. De esta manera, no obligamos a nuestros lectores a hacer clic en una imagen para ver la "versión correcta": las imágenes se ven consistentes desde las vistas previas hasta los tamaños nativos cargados. WordPress hace un trabajo bastante horrible al cambiar el tamaño de las imágenes, lo que a menudo da como resultado imágenes con colores deficientes (debido a la eliminación de perfiles ICC), imágenes suaves y turbias (debido a la fuerte compresión). Para evitar este problema en PL, solo he estado usando ImageMagick para optimizar imágenes, con opciones especiales. Solo eliminamos los datos EXIF ​​de las miniaturas y los comprimimos un poco más agresivamente para una experiencia de navegación rápida. Una vez en una publicación, ni los perfiles ICC ni los datos EXIF ​​se eliminan de las imágenes más grandes para que se vean lo mejor posible. De esta manera, no obligamos a nuestros lectores a hacer clic en una imagen para ver la "versión correcta": las imágenes se ven consistentes desde las vistas previas hasta los tamaños nativos cargados. Para evitar este problema en PL, solo he estado usando ImageMagick para optimizar imágenes, con opciones especiales. Solo eliminamos los datos EXIF ​​de las miniaturas y los comprimimos un poco más agresivamente para una experiencia de navegación rápida. Una vez en una publicación, ni los perfiles ICC ni los datos EXIF ​​se eliminan de las imágenes más grandes para que se vean lo mejor posible. De esta manera, no obligamos a nuestros lectores a hacer clic en una imagen para ver la "versión correcta": las imágenes se ven consistentes desde las vistas previas hasta los tamaños nativos cargados. Para evitar este problema en PL, solo he estado usando ImageMagick para optimizar imágenes, con opciones especiales. Solo eliminamos los datos EXIF ​​de las miniaturas y los comprimimos un poco más agresivamente para una experiencia de navegación rápida. Una vez en una publicación, ni los perfiles ICC ni los datos EXIF ​​se eliminan de las imágenes más grandes para que se vean lo mejor posible. De esta manera, no obligamos a nuestros lectores a hacer clic en una imagen para ver la "versión correcta": las imágenes se ven consistentes desde las vistas previas hasta los tamaños nativos cargados.

Por lo tanto, para aprovechar al máximo el servidor JPEGmini, es mejor ejecutar el ejecutable para cada proceso de cambio de tamaño, no solo para la única versión cargada, ya que desea que el motor optimice cada archivo, ya sea un miniatura, una versión mediana o grande del original. Básicamente, esto significa que JPEGmini debería interceptar todas las llamadas a image_resize.

4) Servidor JPEGmini e integración de WordPress

Desafortunadamente, JPEGmini no proporciona un complemento que se integre automáticamente en WordPress para hacerlo, así que tuve que encontrar una solución por mi cuenta. Comencé con el código base del complemento ImageMagick Engine (un complemento bastante desactualizado, pero aún funciona), luego agregué llamadas al ejecutable JPEGmini en la función ime_im_cli_resize (ejecuto una versión de línea de comando de ImageMagick en lugar de un módulo PHP). Si esta versión modificada del complemento es algo que le interesa, hágamelo saber en la sección de comentarios a continuación y le enviaré el archivo del complemento. No estoy seguro de si la gente de JPEGmini planea lanzar un complemento de WordPress, pero me encantaría contribuir con un código por una buena causa.

El código funciona y ha sido probado con JPEGmini 3.14. Tan pronto como se crea cada versión redimensionada, el código primero optimiza esas imágenes, luego optimiza y sobrescribe la imagen JPEG original.

5) Resultados de la prueba del servidor JPEGmini

Ha habido un montón de galimatías técnicas hasta ahora, así que vayamos al grano. ¿Cuánto espacio de disco pude recuperar y cuánto ahorré en costos de CDN? Para ejecutar el ejecutable JPEGmini de forma recursiva en cada carpeta, tuve que solicitar un script a los ingenieros de JPEGmini, que me proporcionaron muy rápidamente. El archivo proporcionado era una secuencia de comandos de Python llamada "jpegmini_recursive.py", que solo necesitaba dos comandos: uno para ingresar la carpeta de origen y otro para ingresar la carpeta de destino (modifiqué la secuencia de comandos un poco después de obtener la nueva versión de RPM que puede omitir automáticamente imágenes JPEG ya optimizadas). Después de hacer una copia de seguridad de todo, creé una carpeta llamada "uploads_jpegmini" y eso es lo que usé como carpeta de destino. Ejecuté el script y me tomó un tiempo revisar todos y cada uno de los archivos.

Dado que JPEGmini solo optimiza imágenes JPEG y no toca PNG, GIF u otras cargas de archivos como videos, tuve que asegurarme de copiar la carpeta resultante nuevamente en mi carpeta de cargas. Nuevamente, asegúrese de hacer una copia de seguridad completa de todo antes de dar este paso, ya que es irreversible. Antes de hacer eso, cambié recursivamente los permisos en la carpeta uploads_jpegmini ejecutando "chown -R Nobody:nobody /uploads_jpegmini". Luego, el siguiente comando fue "/bin/cp -Rpf uploads_jpegmini/* uploads/", que sobrescribió los archivos de imagen existentes con sus versiones optimizadas de JPEGmini.

Echemos un vistazo al antes y después. Así es como se veían mis carpetas antes de copiar todo el contenido:

du --max-depth=1 | sort -k2
1252    ./2006
5272    ./2007
23332   ./2008
154872  ./2009
819580  ./2010
599084  ./2011
2124952 ./2012
2176548 ./2013
4504720 ./2014
6164472 ./2015
3812759 ./2016
559012  ./2017
Total Size: 20,945,855

Aproximadamente 21 gigabytes de imágenes. Ahora echemos un vistazo a cómo se veía la carpeta después de que JPEGmini optimizara todas las imágenes:

du --max-depth=1 | sort -k2
1000    ./2006
2852    ./2007
15972   ./2008
127708  ./2009
647896  ./2010
461800  ./2011
1099676 ./2012
1252836 ./2013
3049696 ./2014
4378464 ./2015
2858628 ./2016
479416  ./2017
Total Size: 14,375,944

Vaya, ¡eso es solo 14,4 gigabytes ahora! Solo en el espacio del disco duro, pude recuperar más de 6,5 gigas de espacio, lo que se traduce en aproximadamente un 31 % de ahorro de espacio. Eso es básicamente un tercio de mi factura de CDN, que es una gran cantidad. Y tenga en cuenta que en los últimos dos años o más no ahorré tanto espacio como antes, ya que comencé a optimizar mis imágenes en mi escritorio con JPEGmini Pro antes de cargarlas, por lo que los números que ve son cargas de otros miembros del equipo que no están usando JPEGmini.

Aquí hay un informe resumido de muestra de JPEGmini para junio de 2012:

----------------------------------
INFORMACIÓN: informe resumido de la carpeta photographylife.com/wp-content/uploads/ 2012/06 [incluyendo subcarpetas]:
INFO: Número total de archivos: 372
INFO: Tamaño total de archivos de entrada: 42900 KB
INFO: Tamaño total de archivos de salida: 28480 KB
INFO: Relación de recompresión: 1.51X (34% de ahorro)
INFO: ----------------------------------

Las diferentes carpetas arrojaron números diferentes, pero en promedio fue entre 30 y 35 %, que es mucho, considerando que nuestro equipo tiene bastante conocimiento sobre cómo mantener pequeños tamaños de archivo durante el proceso de exportación (generalmente mantenemos nuestra configuración de exportación en el Nivel 10 en Photoshop , que es equivalente al 77-84% de "Calidad" de Lightroom, según nuestro artículo Niveles de compresión JPEG en Photoshop y Lightroom ).

5) Configuración de metadatos y calidad del servidor JPEGmini

Para los sitios que no necesariamente se preocupan por preservar imágenes JPEG de alta calidad con sus metadatos, JPEGmini puede optimizar las imágenes de manera mucho más agresiva. No quería que las imágenes JPEG se vieran peor que las que se cargaron originalmente, así que mantuve la configuración predeterminada de "qual=0", que conserva la mejor calidad. Otros sitios pueden optar por funcionar con calidad alta o media, lo que reducirá la huella de los archivos JPEG de forma mucho más agresiva. Además, también se pueden eliminar por completo todos los metadatos con el comando "rmt=1" y, si eso no es suficiente, incluso hay una opción para forzar la salida JPEG progresiva en cada imagen. Estoy seguro de que los sitios de redes sociales como Facebook utilizan mucho este tipo de herramientas, ya que las imágenes y los videos son una gran parte de sus facturas de alojamiento. Para obtener una lista de los comandos disponibles con el servidor JPEGmini, visiteesta página

6. Conclusión

Si bien el producto JPEGmini Server definitivamente no está dirigido a fotógrafos, el software es una herramienta muy versátil para aquellos que poseen sitios web grandes con muchas imágenes y tráfico. Como se puede ver en mi proyecto de implementación, JPEGmini Server pudo ahorrar más de 6,5 gigabytes de espacio, lo que se traduce en aproximadamente un 31 % de espacio y un ahorro de costos de CDN, que es mucho para una empresa de cualquier tamaño. Con un precio inicial de $ 199 por mes, JPEGmini Server no es barato para una pequeña empresa, pero para una empresa en crecimiento con una gran huella de alojamiento donde una sola instancia de servidor podría costar más que eso cada mes, el producto podría valer la pena. . Si es parte de una empresa de alojamiento, si posee un sitio web cargado con muchas imágenes como PL, o si sus costos de CDN se están volviendo escandalosos, es posible que desee comunicarse con la gente de JPEGmini y hablarles sobre cómo pueden ayudarlo. Para empezar, podrías probaresta página , donde puede ingresar su sitio web y ver cuánto puede esperar ahorrar en costos de CDN.

Si tiene alguna pregunta sobre cualquiera de los anteriores, no dude en enviarme un comentario a continuación.