<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.1" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Improving Dynamic Images [Theoretically]</title>
	<link>http://blog.charcoalphile.com/2008/03/20/improving-dynamic-images-theoretically/</link>
	<description>On Databases, Recovery, Tech</description>
	<pubDate>Mon, 06 Sep 2010 10:59:24 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.1</generator>

	<item>
		<title>By: admin</title>
		<link>http://blog.charcoalphile.com/2008/03/20/improving-dynamic-images-theoretically/#comment-244</link>
		<author>admin</author>
		<pubDate>Fri, 21 Mar 2008 20:41:50 +0000</pubDate>
		<guid>http://blog.charcoalphile.com/2008/03/20/improving-dynamic-images-theoretically/#comment-244</guid>
		<description>Good observation.

I have been considering using Python to handle this. Basically letting it grab files from the database, write it locally, then use the req.sendfile() method to deliver them. Or maybe having the backend write the image to an area, above the htdocs directory. The sendfile() method is much faster than the PHP way of doing it, BTW.

One of my concerns about letting regular users upload images to a server, is if someone finds a hole in the code, they could potentially upload a PHP script to the server, and exploit it from there.

And yeah, I realize Apache is far better at handling this, and I use it in most cases, but when you have users uploading their own Avatars that need to be scaled and cropped to various sizes, you have to have to process them is some kind of dynamic language, and keep track of the images in the database.
</description>
		<content:encoded><![CDATA[<p>Good observation.</p>
<p>I have been considering using Python to handle this. Basically letting it grab files from the database, write it locally, then use the req.sendfile() method to deliver them. Or maybe having the backend write the image to an area, above the htdocs directory. The sendfile() method is much faster than the PHP way of doing it, BTW.</p>
<p>One of my concerns about letting regular users upload images to a server, is if someone finds a hole in the code, they could potentially upload a PHP script to the server, and exploit it from there.</p>
<p>And yeah, I realize Apache is far better at handling this, and I use it in most cases, but when you have users uploading their own Avatars that need to be scaled and cropped to various sizes, you have to have to process them is some kind of dynamic language, and keep track of the images in the database.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ian Eure</title>
		<link>http://blog.charcoalphile.com/2008/03/20/improving-dynamic-images-theoretically/#comment-243</link>
		<author>Ian Eure</author>
		<pubDate>Fri, 21 Mar 2008 20:30:30 +0000</pubDate>
		<guid>http://blog.charcoalphile.com/2008/03/20/improving-dynamic-images-theoretically/#comment-243</guid>
		<description>The problem with JIT in this case is that when you deploy in a high-traffic environment with a cold cache, you end up with race conditions, duplicated work, and a database stampede.

So, say it takes .3s to do your transformation and cache your data. At 500 requests/second, that means the first 160 of those requests happen with a cold cache, which causes a rush on your DB (160 reads of the original data), a CPU spike as those 160 are transformed, and writing the same data to cache 160 times over. You can use a mutex to block until the first transform is complete, but those carry their own set of problems (what if your code crashes before releasing the lock?). They also don't help you once you need to scale beyond one webserver.

The solution, in my opinion, is to recognize that Apache is far better at serving static content than PHP will ever be. Your best bet is really to front-load the operation, performing whatever scaling you need on the data when it gets uploaded, and writing it to disk. Then you can just link to those files and let Apache take care of the rest.

Clearly, this works for unchanging data, such as thumbnails, overlays, and the like. If you're generating truly dynamic images (say, text of the current user's name overlaid on an image), that front-loading isn't going to work. But for most operations (scaling, optimizing, matting, cropping), it's the way to go.</description>
		<content:encoded><![CDATA[<p>The problem with JIT in this case is that when you deploy in a high-traffic environment with a cold cache, you end up with race conditions, duplicated work, and a database stampede.</p>
<p>So, say it takes .3s to do your transformation and cache your data. At 500 requests/second, that means the first 160 of those requests happen with a cold cache, which causes a rush on your DB (160 reads of the original data), a CPU spike as those 160 are transformed, and writing the same data to cache 160 times over. You can use a mutex to block until the first transform is complete, but those carry their own set of problems (what if your code crashes before releasing the lock?). They also don&#8217;t help you once you need to scale beyond one webserver.</p>
<p>The solution, in my opinion, is to recognize that Apache is far better at serving static content than PHP will ever be. Your best bet is really to front-load the operation, performing whatever scaling you need on the data when it gets uploaded, and writing it to disk. Then you can just link to those files and let Apache take care of the rest.</p>
<p>Clearly, this works for unchanging data, such as thumbnails, overlays, and the like. If you&#8217;re generating truly dynamic images (say, text of the current user&#8217;s name overlaid on an image), that front-loading isn&#8217;t going to work. But for most operations (scaling, optimizing, matting, cropping), it&#8217;s the way to go.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
