<?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: Auto-Rebooting Talos Boxen Saves The World</title>
	<atom:link href="http://alice.nodelman.net/blog/post/auto-rebooting-talos-boxen-saves-the-world/feed/" rel="self" type="application/rss+xml" />
	<link>http://alice.nodelman.net/blog/post/auto-rebooting-talos-boxen-saves-the-world/</link>
	<description>infrequent updates and long delays</description>
	<pubDate>Sun, 05 Feb 2012 08:45:42 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: alice</title>
		<link>http://alice.nodelman.net/blog/post/auto-rebooting-talos-boxen-saves-the-world/comment-page-1/#comment-4564</link>
		<dc:creator>alice</dc:creator>
		<pubDate>Wed, 07 Jan 2009 00:57:06 +0000</pubDate>
		<guid isPermaLink="false">http://alice.nodelman.net/blog/?p=28#comment-4564</guid>
		<description>It's unreasonable to attempt to track possible performance regressions based upon a side-effect of the initial Talos system set up.  If we are interested in tracking how the browser behaves on a system that has been up for a long time, or re-using the same profile again and again, or some other long running metric then we should design a system to test it that is consistent and repeatable.  As it was, we couldn't say how long a machine had been up or how many browsers it had tested (and if any of those browsers were regressed and did something weird to the system, all the worse) - essentially it gave us no information about the sort of thing that you are interested in.

I think that we need a robust and varied approach to performance.  We need to design different types of tests to cover different things that we are interested in.  Attempted to fit everything under the Talos umbrella just isn't the best route to that end.</description>
		<content:encoded><![CDATA[<p>It&#8217;s unreasonable to attempt to track possible performance regressions based upon a side-effect of the initial Talos system set up.  If we are interested in tracking how the browser behaves on a system that has been up for a long time, or re-using the same profile again and again, or some other long running metric then we should design a system to test it that is consistent and repeatable.  As it was, we couldn&#8217;t say how long a machine had been up or how many browsers it had tested (and if any of those browsers were regressed and did something weird to the system, all the worse) - essentially it gave us no information about the sort of thing that you are interested in.</p>
<p>I think that we need a robust and varied approach to performance.  We need to design different types of tests to cover different things that we are interested in.  Attempted to fit everything under the Talos umbrella just isn&#8217;t the best route to that end.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Håkan</title>
		<link>http://alice.nodelman.net/blog/post/auto-rebooting-talos-boxen-saves-the-world/comment-page-1/#comment-4560</link>
		<dc:creator>Håkan</dc:creator>
		<pubDate>Tue, 06 Jan 2009 08:10:07 +0000</pubDate>
		<guid isPermaLink="false">http://alice.nodelman.net/blog/?p=28#comment-4560</guid>
		<description>Isn't there a risk that there will be a class of performance bug that will now never show up on the radar? Can we be sure that e.g. the "auto rising" of memory after a period of continued use is not our problem?</description>
		<content:encoded><![CDATA[<p>Isn&#8217;t there a risk that there will be a class of performance bug that will now never show up on the radar? Can we be sure that e.g. the &#8220;auto rising&#8221; of memory after a period of continued use is not our problem?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

