----- Original Message -----

> From: Rob Weir <[email protected]>
> To: [email protected]
> Cc: 
> Sent: Tuesday, March 20, 2012 3:45 PM
> Subject: Re: Sourceforge and AOO 3.4 distribution
> 
> On Tue, Mar 20, 2012 at 3:22 PM, Joe Schaefer <[email protected]> 
> wrote:
>>  We're still exploring available options and collecting
>>  data imacat.  Right now an existing ooo mirror operator
>>  has reported to us that his average bandwidth consumption
>>  for ooo was ~100Mbps.  It would help us to know how many
>>  mirrors support the existing mirrorbrain service for ooo
>>  to get a guess as to what the impact would be for Apache
>>  mirrors, but we are anticipating similar bandwidth requirements
>>  for our mirrors given the available data.
>> 
>> 
>>  What we currently need are estimates related to peak downloads
>>  during the initial few days / weeks of a release.  Anyone
>>  with historical data on this needs to step forward and share
>>  it ASAP- 300K strikes me as an off-peak figure at this point.
>> 
> 
> I have not seen any actual log files with this info, but there are
> reported tidbits that might be useful, such as:
> 
> "OpenOffice.org 3.0 was downloaded 3 million times in its first week,
> with about 80% of the downloads by Windows users, an official with the
> group said in a blog post on Monday."
> 
> http://www.computerworld.com/s/article/9117575/OpenOffice.org_3.0_scores_strong_first_week
> 
> So per day that is 430,000, around 50% much more than the average we
> saw in February.  Not as much as I expected.

Thanks Rob.  Combined with http://mirrorbrain.org/users/ reporting "over
100 mirrors" for OpenOffice at ~100mbps, that means we really are averaging over
100 TB / day, and we can start to anticipate a need for 150-200TB
for sane handling of peak traffic.

> 
> What I don't know is when they enabled the update notifications
> feature then, if it even existed in 3.0.  I think that will have a big
> impact on download peaks.  In fact, we might even want to be clever,
> like have a CGI that sometimes says there is an update available, and
> sometimes does not, just to spread out the load more evenly.  For
> example, if we have our server respond "you have the latest" 90% of
> the time, then it will take several requests on average for the
> auto-update feature to prompt the user to download the update.  So we
> have some ability to throttle that demand, based on our CGI.

Sound suggestion.

Reply via email to