<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>WebDeveloperss.com &#187; real time</title>
	<atom:link href="http://www.webdeveloperss.com/blog/tag/real-time/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.webdeveloperss.com/blog</link>
	<description>Hand-Picked Best Of The Web Developer Blogs</description>
	<lastBuildDate>Sun, 19 Jun 2011 23:01:59 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Strategy: Don&#8217;t Use Polling for Real-time Feeds</title>
		<link>http://www.webdeveloperss.com/blog/2010/01/strategy-dont-use-polling-for-real-time-feeds/</link>
		<comments>http://www.webdeveloperss.com/blog/2010/01/strategy-dont-use-polling-for-real-time-feeds/#comments</comments>
		<pubDate>Mon, 11 Jan 2010 18:48:59 +0000</pubDate>
		<dc:creator>Todd Hoff</dc:creator>
				<category><![CDATA[Feeder]]></category>
		<category><![CDATA[google]]></category>
		<category><![CDATA[real time]]></category>
		<category><![CDATA[Strategy]]></category>

		<guid isPermaLink="false"></guid>
		<description><![CDATA[<p>Ivan Zuzak wrote a fascinating article on <a rel="bookmark" href="http://izuzak.wordpress.com/2010/01/11/real-time-feed-processing-and-filtering/">Real-time feed processing and filtering</a> using Google App Engine to build <a href="http://code.google.com/p/feed-buster/">Feed-buster</a>, a service that<em> inserts MediaRSS tags into feeds that don't have them</em>. He talks about using polling and <a href="http://go2.wordpress.com/?id=725X1342&#38;site=izuzak.wordpress.com&#38;url=http%3A%2F%2Fcode.google.com%2Fp%2Fpubsubhubbub%2F">PubSubHubBub</a> (real-time) to process FriendFeed feeds. Ivan is trying to devise a separate filtering service where:<strong> </strong></p>
<ol>
<li><strong>filtering services should be applied as close to the publisher</strong> as possible so notifications that nobody wants don’t waste network resource. </li>
<li><strong>processing services should be applied as close to the subscriber </strong>so that the original update may be transported through the network as a single notification for as long as possible.</li>
</ol>
<p>Besides being a generally interesting article, Ivan makes an insightful observation on the nature of using polling services in combination with metered Infrastructure/Platform services:</p>
<blockquote>
<p>Polling is bad because AppEngine applications have a <a href="http://code.google.com/appengine/docs/quotas.html">fixed free daily quota</a> for consumed resources, when the number of feeds the service processed increased -<strong> the daily quota was exhausted before the end of the day</strong> because FF polls the service for each feed every 45 minutes.</p>
</blockquote>
<div>This fits directly in with the ideas in<a href="http://highscalability.com/blog/2009/3/6/cloud-programming-directly-feeds-cost-allocation-back-into-s.html"> Cloud Programming Directly Feeds Cost Allocation Back into Software Design.</a> My general preference is to poll a distributed queue for work items. It's robust and allows your system to control it's own resource usage by determining when to poll. Otherwise you can easily be overwhelmed by fast pushers. Here the overwhelming is going the other way. Your budget is being overwhelmed by the polling requests. And the more you try approximate real-time with frequent polling requests the more your budget is busted.</div>
<div></div>
<div></div>
<div>It's a cool example of how costs, algorithm, and platform choices all feed into and shape product architectures.</div>
<p> </p>]]></description>
			<content:encoded><![CDATA[<p><span style="background-color:yellow">Link To Full Story:</span> <a href="http://highscalability.com/blog/2010/1/11/strategy-dont-use-polling-for-real-time-feeds.html" target="blank">High Scalability </a></p>

<p>Ivan Zuzak wrote a fascinating article on <a rel="bookmark" href="http://izuzak.wordpress.com/2010/01/11/real-time-feed-processing-and-filtering/">Real-time feed processing and filtering</a> using Google App Engine to build <a href="http://code.google.com/p/feed-buster/">Feed-buster</a>, a service that<em> inserts MediaRSS tags into feeds that don't have them</em>. He talks about using polling and <a href="http://go2.wordpress.com/?id=725X1342&amp;site=izuzak.wordpress.com&amp;url=http%3A%2F%2Fcode.google.com%2Fp%2Fpubsubhubbub%2F">PubSubHubBub</a> (real-time) to process FriendFeed feeds. Ivan is trying to devise a separate filtering service where:<strong> </strong></p>
<ol>
<li><strong>filtering services should be applied as close to the publisher</strong> as possible so notifications that nobody wants don’t waste network resource. </li>
<li><strong>processing services should be applied as close to the subscriber </strong>so that the original update may be transported through the network as a single notification for as long as possible.</li>
</ol>
<p>Besides being a generally interesting article, Ivan makes an insightful observation on the nature of using polling services in combination with metered Infrastructure/Platform services:</p>
<blockquote>
<p>Polling is bad because AppEngine applications have a <a href="http://code.google.com/appengine/docs/quotas.html">fixed free daily quota</a> for consumed resources, when the number of feeds the service processed increased -<strong> the daily quota was exhausted before the end of the day</strong> because FF polls the service for each feed every 45 minutes.</p>
</blockquote>
<div>This fits directly in with the ideas in<a href="http://highscalability.com/blog/2009/3/6/cloud-programming-directly-feeds-cost-allocation-back-into-s.html"> Cloud Programming Directly Feeds Cost Allocation Back into Software Design.</a> My general preference is to poll a distributed queue for work items. It's robust and allows your system to control it's own resource usage by determining when to poll. Otherwise you can easily be overwhelmed by fast pushers. Here the overwhelming is going the other way. Your budget is being overwhelmed by the polling requests. And the more you try approximate real-time with frequent polling requests the more your budget is busted.</div>
<div></div>
<div></div>
<div>It's a cool example of how costs, algorithm, and platform choices all feed into and shape product architectures.</div>
<p> </p>]]></content:encoded>
			<wfw:commentRss>http://www.webdeveloperss.com/blog/2010/01/strategy-dont-use-polling-for-real-time-feeds/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>

