Cambiar el tamaño de la imagen PHP sobre la marcha vs almacenar imágenes redimensionadas

Question

Estoy construyendo un sitio para compartir imágenes y me gustaría saber las ventajas y desventajas de cambiar el tamaño de las imágenes sobre la marcha con PHP y tener las imágenes redimensionadas.

¿Qué es más rápido?

¿Qué es más confiable?

¿Cuán grande es la brecha entre los dos métodos en velocidad y rendimiento?

Tenga en cuenta que de cualquier forma las imágenes pasan por un script PHP para estadísticas como vistas o si se permite hotlinking etc ... así que no será como un enlace directo para imágenes si opto por almacenar las imágenes de cambio de tamaño.

Agradeceré sus comentarios o cualquier enlace útil sobre el tema.

Answer 1

Esto suena como una optimización prematura. ¿Sabe cuántos usuarios tendrá su sitio/qué cantidad de cómputo tendrá su servidor? Vaya con la opción más simple (mantenimiento), es decir, cambie el tamaño sobre la marcha, hasta que el rendimiento sea un problema, luego descubra qué hacer.

Podría ser una idea implementar algún tipo de almacenamiento en caché del lado del servidor de sus imágenes redimensionadas, si es probable que se golpeen repetidamente, pero no creo que esto deba extenderse en cuanto a la representación previa explícita.

Answer 2

El redimensionamiento dinámico puede ser un procedimiento costoso (según el tiempo) dependiendo del tamaño inicial de las imágenes. Lo he hecho en sistemas de producción, pero cuando tengo la opción, estoy muy a favor del almacenamiento en caché en el disco. Después de todo, el espacio en disco es barato, y el tiempo de carga lo es todo en la Web. Incluso si almacena en la memoria caché miniaturas en un tamaño específico y realiza cambios de tamaño dinámicos en cualquier otro lugar, puede reducir en gran medida los tiempos de carga para las listas de imágenes estilo galería.

Answer 3

Le recomiendo encarecidamente que almacene en caché sus imágenes, y NO cambie el tamaño sobre la marcha.

cambiar el tamaño de las imágenes consume mucha CPU y consume mucha memoria para su servidor.

Si tiene una galería de imágenes que se escalará sobre la marcha, la página cargará las imágenes lentamente, digamos algo así como 3-10 segundos, depende del tamaño del archivo original.

Al redimensionar, se necesitan aproximadamente 3 bytes por píxel de su memoria. Entonces, si tiene que cambiar el tamaño de una imagen de 1000x1000, se necesitarán aproximadamente 3 MB de memoria. Si una de sus páginas web tiene muchas de estas imágenes de cambio de tamaño en la marcha, digamos 20, se necesitarán aproximadamente 60 MB de RAM de su servidor. Quizás no, ya que la mayoría de los clientes solo solicita 4 imágenes en el momento, pero 12 MB sigue siendo mucho para una carga de página. Solo escalaría sobre la marcha si la imagen de origen es menos de 100x100 px.

TIP: Una gran lib para escalar y el ahorro de los pulgares es PhpThumb

Answer 4

Se trata de cuestiones absolutamente incomparables.

Cambiar el tamaño de las imágenes sobre la marcha, de hecho, es como ejecutar un ataque DoS en su propio servidor. Cambiar el tamaño de una imagen habitual requiere más CPU y RAM que servir una solicitud habitual para el script php. Eso YA tiene un gran impacto en el rendimiento. Sin embargo, se muestra una miniatura habitual no solo, sino en números. Entonces, al mostrar solo una página de galería, está creando docenas de procesos de carga pesada, aumentando la carga del servidor por un factor de diez o más.

Prueba rápida y sucia para demostrar mis palabras: Vamos a tratar de cambiar el tamaño relativamente pequeño, de 1,3 megapíxeles imagen

$ /usr/bin/time --format="%MK mem %Es CPU time" /usr/bin/convert angry_birds_1280x800.jpg -resize 100x100 thumb.jpg 
10324K mem 0:00.10s CPU time 

Nos tomó 0,1s, así, mostrar vistas previas de imágenes 10 se comen una segundo entero de tu tiempo de CPU. Si bien la página de la galería PHP correctamente escrita tomará alrededor de 0,01s. Por lo tanto, con su cambio de tamaño sobre la marcha, está aumentando la carga del servidor por un factor de 100.

Lo mismo con la memoria. ¡Cada proceso de cambio de tamaño comerá no menos de 10M de memoria (para cambiar el tamaño de un archivo de imagen de 100k!) Con una suma total de 100M. Mientras que el límite de memoria habitual para el script PHP es simplemente 8M y rara vez se alcanza.

Éstos son los números de la vida real.

Una cosa un tanto divertida relacionada con este problema:
Exactamente el mismo usuario PHP que fácilmente tirar 1000000s de ciclos de CPU al mismo tiempo siendo increíble celosa de sobra 1 o 2! No es una forma de hablar, aquí hay un ejemplo de lo que estoy hablando:
A similar question de alguien, cuya gran preocupación al mismo tiempo en algo tan insignificante como speed difference between Constants, Variables or Variable Arrays. Y que recientemente run into allowed memory size exhausted problem, como si tal desastre no fuera suficiente.

Hay un montón de preguntas y respuestas en este sitio, debatiendo la diferencia de velocidad en nanosegundos de cualquier operación, respondida con dignidad inagotable, ejecutando pruebas de millones de iteraciones para mostrar una diferencia absolutamente insignificante entre operaciones de varios ciclos de CPU cada una.

Y al mismo tiempo hay preguntas como esta: con respecto a la diferencia enorme e incomparable en términos de rendimiento entre dos enfoques, que se asemeja al autor.

Ese es el problema con el usuario promedio de PHP y este sitio.
Lo primero simplemente no tiene medida para contar cosas reales desde las microscópicas.
Sin embargo, estos últimos no tienen ningún mecanismo para la verificación de la cordura de las preguntas; todos respondieron con igual entusiasmo, incluso si dos preguntas contradigan entre sí (y ambas con sentido común).