<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>David Collier-Brown on O&apos;Reilly Broadcast</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/" />
<link rel="self" type="application/atom+xml" href="http://broadcast.oreilly.com/atom.xml" />
<id>tag:broadcast.oreilly.com,2008-08-07://53</id>
<updated>2009-08-24T13:56:39Z</updated>

<generator uri="http://www.sixapart.com/movabletype/">Movable Type Pro 4.21-en</generator>

<entry>
<title>My Canadian Copyright Consultation submission</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/08/my-canadian-copyright-consulta.html" />
<id>tag:broadcast.oreilly.com,2009://53.37803</id>

<published>2009-08-24T13:56:39Z</published>
<updated>2009-08-24T13:56:39Z</updated>

<summary>The Parliament of Canada recently started a public consultation on what changes should be made to Canadian copyright law, after loud public condemnation of a set of proposals a few years ago. Having made more instead of less, because &quot;Using Samba&quot; was available electronically, it behooved me to tell Parliament about my recent experience in the trade-offs in copyright law and in particular to the relevance of digital rights management schemes to publishing.</summary>
<author>
<name>David Collier-Brown</name>

</author>

<category term="canada" label="canada" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="copyright" label="copyright" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="drm" label="drm" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
The Parliament of Canada recently started a public consultation on what changes should be made to Canadian copyright law, after loud public condemnation of a set of proposals a few years ago. Having made more instead of less, because &quot;Using Samba&quot; was available electronically, it behooved me to tell Parliament about my recent experience in the trade-offs in copyright law and in particular to the relevance of digital rights management schemes to publishing.
</content>
</entry>

<entry>
<title>An Interesting Time-Sliced Cloud</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/08/an-interesting-time-sliced-clo.html" />
<id>tag:broadcast.oreilly.com,2009://53.37797</id>

<published>2009-08-23T17:39:11Z</published>
<updated>2009-08-23T17:39:11Z</updated>

<summary>In this month&apos;s IEEE Computer, there&apos;s an interesting article about using a Cloud in a non-business critical environment, mixed academic and high-performance computing. In their cloud, a professor can book a set of machines for a particular time each week for a lab, or a student can book a particular configuration of machine to do their homework. Time not booked goes into the general HPC pool, and is used for non-instructional computing.  A commercial entity could use the same tactic: allow people to book time from a set of machines, but pre-book the whole of the machine or machines for the more business-critical quarter- and year-end processing.</summary>
<author>
<name>David Collier-Brown</name>

</author>

<category term="capacityplanning" label="capacity planning" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="cloudcomputing" label="cloud computing" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
In this month&apos;s IEEE Computer, there&apos;s an interesting article about using a Cloud in a non-business critical environment, mixed academic and high-performance computing. In their cloud, a professor can book a set of machines for a particular time each week for a lab, or a student can book a particular configuration of machine to do their homework. Time not booked goes into the general HPC pool, and is used for non-instructional computing.  A commercial entity could use the same tactic: allow people to book time from a set of machines, but pre-book the whole of the machine or machines for the more business-critical quarter- and year-end processing.
</content>
</entry>

<entry>
<title>Do You Need Capacity Planning for Cloud Computing?</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/07/do-you-need-capacity-planning.html" />
<id>tag:broadcast.oreilly.com,2009://53.37488</id>

<published>2009-07-12T14:50:55Z</published>
<updated>2009-07-12T14:50:55Z</updated>

<summary>On first glance, a properly-done cloud computing agreement sounds like it should save a customer company the work of doing any capacity planning at all. You can let the cloud supplier do all the work. However, even the best cloud service is more expensive than running your own small data center, so it doesn&apos;t make sense to have everything in the cloud, always.
What cloud or utility computing does allow is for you, the customer, to radically simplify capacity and financial planning, and only provide enough resources for the load that you&apos;re sure to get, letting the cloud carry all the spikes and year-end rushes.
</summary>
<author>
<name>David Collier-Brown</name>

</author>


<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
On first glance, a properly-done cloud computing agreement sounds like it should save a customer company the work of doing any capacity planning at all. You can let the cloud supplier do all the work. However, even the best cloud service is more expensive than running your own small data center, so it doesn&apos;t make sense to have everything in the cloud, always.
What cloud or utility computing does allow is for you, the customer, to radically simplify capacity and financial planning, and only provide enough resources for the load that you&apos;re sure to get, letting the cloud carry all the spikes and year-end rushes.

</content>
</entry>

<entry>
<title>Manage Your Performance with Cgroups and Projects</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/06/manage-your-performance-with-cgroups-and-projects.html" />
<id>tag:broadcast.oreilly.com,2009://53.37323</id>

<published>2009-06-29T13:46:47Z</published>
<updated>2009-06-29T13:46:47Z</updated>

<summary>Imagine for a moment that you&apos;re a capacity planner for a successful LAMP-based web site, and management has just &quot;gifted&quot; you with a new reporting program. You now have to somehow shoehorn it onto the server without hurting the performance of the existing programs.
Insoluble problem? Not a bit! 
All you need is a resource manager like cgroups, the resource manager for Linux containers. 
</summary>
<author>
<name>David Collier-Brown</name>

</author>


<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
Imagine for a moment that you&apos;re a capacity planner for a successful LAMP-based web site, and management has just &quot;gifted&quot; you with a new reporting program. You now have to somehow shoehorn it onto the server without hurting the performance of the existing programs.
Insoluble problem? Not a bit! 
All you need is a resource manager like cgroups, the resource manager for Linux containers. 

</content>
</entry>

<entry>
<title>Why &quot;Twice Service Time&quot;?</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/06/why-twice-service-time.html" />
<id>tag:broadcast.oreilly.com,2009://53.37240</id>

<published>2009-06-19T13:02:39Z</published>
<updated>2009-06-19T13:02:39Z</updated>

<summary>A colleague asked me why I said to use a ratio of response time to service time of 2:1 in 
Sizing to Fail. Was it just magic, or was there any science behind it?

It turns out to be a range, found by observation, rather like the number of things you can keep in your mind at once: &quot;five, plus or minus two&quot;.</summary>
<author>
<name>David Collier-Brown</name>

</author>


<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
A colleague asked me why I said to use a ratio of response time to service time of 2:1 in 
Sizing to Fail. Was it just magic, or was there any science behind it?

It turns out to be a range, found by observation, rather like the number of things you can keep in your mind at once: &quot;five, plus or minus two&quot;.
</content>
</entry>

<entry>
<title>Sizing to Fail</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/05/sizing-to-fail.html" />
<id>tag:broadcast.oreilly.com,2009://53.36384</id>

<published>2009-05-30T20:07:40Z</published>
<updated>2009-05-30T20:07:40Z</updated>

<summary>Out of your management asks you for a sizing estimate for the program in production, with 1500 users.  You&apos;ve only ever tested with 100 simulated users in JMeter, you don&apos;t have a machine big enough to test 1500 users on, and management need the answer by the end of today.  

Stop. Don&apos;t run screaming from the building, however horrible this sounds. You can&apos;t tell management what will work, but you can tell them how large a system they&apos;ll need to avoid guaranteed failure, which may suffice.</summary>
<author>
<name>David Collier-Brown</name>

</author>


<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
Out of your management asks you for a sizing estimate for the program in production, with 1500 users.  You&apos;ve only ever tested with 100 simulated users in JMeter, you don&apos;t have a machine big enough to test 1500 users on, and management need the answer by the end of today.  

Stop. Don&apos;t run screaming from the building, however horrible this sounds. You can&apos;t tell management what will work, but you can tell them how large a system they&apos;ll need to avoid guaranteed failure, which may suffice.
</content>
</entry>

</feed> 