<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Cal Henderson (Flickr) &#8211; Scalable Web Architectures: Common Patterns and Approaches</title>
	<atom:link href="http://www.krisjordan.com/2008/09/16/cal-henderson-scalable-web-architectures-common-patterns-and-approaches/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.krisjordan.com/2008/09/16/cal-henderson-scalable-web-architectures-common-patterns-and-approaches/</link>
	<description>on Software, Frameworks, &#38; Stuff</description>
	<lastBuildDate>Sat, 29 Aug 2009 05:39:48 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Towards RESTful PHP - 5 Basic Tips - Basit - Live Your Life with Inspiration</title>
		<link>http://www.krisjordan.com/2008/09/16/cal-henderson-scalable-web-architectures-common-patterns-and-approaches/comment-page-1/#comment-8206</link>
		<dc:creator>Towards RESTful PHP - 5 Basic Tips - Basit - Live Your Life with Inspiration</dc:creator>
		<pubDate>Tue, 26 May 2009 18:48:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.krisjordan.com/?p=143#comment-8206</guid>
		<description>[...] A truly RESTful PHP application should be entirely stateless- all requests should contain enough information to be handled without additional server side state. In practice this means storing authentication information in a cookie with a timestamp and a checksum. Additional data can also be stored in a cookie. In the event you need more than a cookie’s worth of data fall back to storing it in a central database with the authentication still in the cookie. This is how Flickr approaches statelessness. [...]</description>
		<content:encoded><![CDATA[<p>[...] A truly RESTful PHP application should be entirely stateless- all requests should contain enough information to be handled without additional server side state. In practice this means storing authentication information in a cookie with a timestamp and a checksum. Additional data can also be stored in a cookie. In the event you need more than a cookie’s worth of data fall back to storing it in a central database with the authentication still in the cookie. This is how Flickr approaches statelessness. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marcyes / Cal Henderson (Flickr) - Scalable Web Architectures: Common Patterns and Approaches - notes by Kris Jordan</title>
		<link>http://www.krisjordan.com/2008/09/16/cal-henderson-scalable-web-architectures-common-patterns-and-approaches/comment-page-1/#comment-6934</link>
		<dc:creator>Marcyes / Cal Henderson (Flickr) - Scalable Web Architectures: Common Patterns and Approaches - notes by Kris Jordan</dc:creator>
		<pubDate>Fri, 08 May 2009 19:29:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.krisjordan.com/?p=143#comment-6934</guid>
		<description>[...]  Cal Henderson (Flickr) - Scalable Web Architectures: Common Patterns and Approaches - notes by Kris...  The whole article gets into a lot of details about how they scaled Flickr and well worth the read if you are into scaling web apps. Specifically I really like the db notes:Database is the hardest part to scale. If we can, best to avoid the issue altogether and just buy bigger hardware. Dual-quad opteron with 16GB RAM can get you a long way.What do you do when the hardware can’t keep up? We do a lot more reading than writing. Somewhere between 80/20 or 90/10 ratio of read/write. “Only a few people who like to caption pictures of kittens on the internet - but a whole lot of people who like to look at them.”Replication is the solution for the read write problem. Master-slave replication. Add more slaves, 1 master 3 slaves = 4 times the read power. Flickr is 6 reads for every write.&#160; Problem is what happens when we need to push more writes? As we need more writes this doesn’t scale well - have to add a lot more boxes.MySQL query cache has bad performance in most cases. MySQL query cache: for any read query stores a pointer to the result if you perform the exact same query. Any write flushes it, though. So if you do 10 reads for every 1 write you’re unlikely to get a hit before cache is invalidated. If you only write once an hour or day then this is a really good thing. Otherwise turn it off.   [via news.ycombinator.com ] [ business, entrepreneur, scaling, server, db ]   1978     Latest Updates from this link [...]</description>
		<content:encoded><![CDATA[<p>[...]  Cal Henderson (Flickr) &#8211; Scalable Web Architectures: Common Patterns and Approaches &#8211; notes by Kris&#8230;  The whole article gets into a lot of details about how they scaled Flickr and well worth the read if you are into scaling web apps. Specifically I really like the db notes:Database is the hardest part to scale. If we can, best to avoid the issue altogether and just buy bigger hardware. Dual-quad opteron with 16GB RAM can get you a long way.What do you do when the hardware can’t keep up? We do a lot more reading than writing. Somewhere between 80/20 or 90/10 ratio of read/write. “Only a few people who like to caption pictures of kittens on the internet &#8211; but a whole lot of people who like to look at them.”Replication is the solution for the read write problem. Master-slave replication. Add more slaves, 1 master 3 slaves = 4 times the read power. Flickr is 6 reads for every write.&#160; Problem is what happens when we need to push more writes? As we need more writes this doesn’t scale well &#8211; have to add a lot more boxes.MySQL query cache has bad performance in most cases. MySQL query cache: for any read query stores a pointer to the result if you perform the exact same query. Any write flushes it, though. So if you do 10 reads for every 1 write you’re unlikely to get a hit before cache is invalidated. If you only write once an hour or day then this is a really good thing. Otherwise turn it off.   [via news.ycombinator.com ] [ business, entrepreneur, scaling, server, db ]   1978     Latest Updates from this link [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: High Scalability (1) &#124; New York City Man - Alessandro Pistilli</title>
		<link>http://www.krisjordan.com/2008/09/16/cal-henderson-scalable-web-architectures-common-patterns-and-approaches/comment-page-1/#comment-2183</link>
		<dc:creator>High Scalability (1) &#124; New York City Man - Alessandro Pistilli</dc:creator>
		<pubDate>Sat, 21 Feb 2009 19:37:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.krisjordan.com/?p=143#comment-2183</guid>
		<description>[...] Cal Henderson (Flickr) - Scalable Web Architectures: Common Patterns and Approaches:http://www.krisjordan.com/2008/09/16/cal-henderson-scalable-web-architectures-common-patterns-and-ap...  [...]</description>
		<content:encoded><![CDATA[<p>[...] Cal Henderson (Flickr) &#8211; Scalable Web Architectures: Common Patterns and Approaches:http://www.krisjordan.com/2008/09/16/cal-henderson-scalable-web-architectures-common-patterns-and-ap&#8230;  [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: links for 2008-12-02</title>
		<link>http://www.krisjordan.com/2008/09/16/cal-henderson-scalable-web-architectures-common-patterns-and-approaches/comment-page-1/#comment-861</link>
		<dc:creator>links for 2008-12-02</dc:creator>
		<pubDate>Tue, 02 Dec 2008 21:02:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.krisjordan.com/?p=143#comment-861</guid>
		<description>[...] Cal Henderson (Flickr) - Scalable Web Architectures: Common Patterns and Approaches &#124; Kris Jordan (tags: scaling scalability php flickr architecture) [...]</description>
		<content:encoded><![CDATA[<p>[...] Cal Henderson (Flickr) &#8211; Scalable Web Architectures: Common Patterns and Approaches | Kris Jordan (tags: scaling scalability php flickr architecture) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Towards RESTful PHP - 5 Basic Tips &#124; Kris Jordan</title>
		<link>http://www.krisjordan.com/2008/09/16/cal-henderson-scalable-web-architectures-common-patterns-and-approaches/comment-page-1/#comment-855</link>
		<dc:creator>Towards RESTful PHP - 5 Basic Tips &#124; Kris Jordan</dc:creator>
		<pubDate>Tue, 02 Dec 2008 06:37:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.krisjordan.com/?p=143#comment-855</guid>
		<description>[...] A truly RESTful PHP application should be entirely stateless- all requests should contain enough information to be handled without additional server side state. In practice this means storing authentication information in a cookie with a timestamp and a checksum. Additional data can also be stored in a cookie. In the event you need more than a cookie&#8217;s worth of data fall back to storing it in a central database with the authentication still in the cookie. This is how Flickr approaches statelessness. [...]</description>
		<content:encoded><![CDATA[<p>[...] A truly RESTful PHP application should be entirely stateless- all requests should contain enough information to be handled without additional server side state. In practice this means storing authentication information in a cookie with a timestamp and a checksum. Additional data can also be stored in a cookie. In the event you need more than a cookie&#8217;s worth of data fall back to storing it in a central database with the authentication still in the cookie. This is how Flickr approaches statelessness. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kris</title>
		<link>http://www.krisjordan.com/2008/09/16/cal-henderson-scalable-web-architectures-common-patterns-and-approaches/comment-page-1/#comment-154</link>
		<dc:creator>Kris</dc:creator>
		<pubDate>Thu, 25 Sep 2008 18:40:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.krisjordan.com/?p=143#comment-154</guid>
		<description>130K is what I meant to record, thanks for the catch!</description>
		<content:encoded><![CDATA[<p>130K is what I meant to record, thanks for the catch!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris</title>
		<link>http://www.krisjordan.com/2008/09/16/cal-henderson-scalable-web-architectures-common-patterns-and-approaches/comment-page-1/#comment-138</link>
		<dc:creator>Chris</dc:creator>
		<pubDate>Mon, 22 Sep 2008 17:46:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.krisjordan.com/?p=143#comment-138</guid>
		<description>In the top of the article, did you mean 130K? or 13K?  

Thank you for posting all the write ups from the expo, it will save me a lot of work as I explain the sessions to my co workers.</description>
		<content:encoded><![CDATA[<p>In the top of the article, did you mean 130K? or 13K?  </p>
<p>Thank you for posting all the write ups from the expo, it will save me a lot of work as I explain the sessions to my co workers.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
