From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ea0-f171.google.com (mail-ea0-f171.google.com [209.85.215.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5D68F21F164 for ; Mon, 19 Nov 2012 05:13:56 -0800 (PST) Received: by mail-ea0-f171.google.com with SMTP id n10so783017eaa.16 for ; Mon, 19 Nov 2012 05:13:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Bw6Ed9a9bDYa5nr7NG9ZapoYBwNcFhd0Y7AV2N4cvcs=; b=R4jsGCO7PX46ovpi4RFmbzcq5JFvCG44xT1iAqSkEwtN3wGsrLBsR8kcpSWfnve2i+ gGn/0C4dFDz3Rn3yOrEv56CLevIpw9o0rcnPgCHluRa5TfgLiryjNo4760OckDV/wvpO qZXtKEd3MUOhwwHem6tPmFpsOg1+ykwXzaUajc2LNwGdQVL3b6E+CcirUsvIsdJb5+HT RPspKgyj0qhEulCSJJacXa/odfNkDOOAL7gcfKwuokFNTMrYTfZBe/j4bVG8xNwNgdXw aEbsc2ucvWNyrCX5yAvS9DghjESKUcx/LzisKeQIv87Hnq0Pv5+g8jNvG3dQSsQMYHlo Uspw== Received: by 10.14.209.201 with SMTP id s49mr24103607eeo.7.1353330834159; Mon, 19 Nov 2012 05:13:54 -0800 (PST) Received: from bass.home.chromatix.fi (xdsl-83-150-84-172.nebulazone.fi. [83.150.84.172]) by mx.google.com with ESMTPS id s1sm24098129eem.9.2012.11.19.05.13.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Nov 2012 05:13:53 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: <50AA26FA.2000300@net.t-labs.tu-berlin.de> Date: Mon, 19 Nov 2012 15:13:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50AA26FA.2000300@net.t-labs.tu-berlin.de> To: Oliver Hohlfeld X-Mailer: Apple Mail (2.1085) Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] bufferbloat and the web service providers X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 13:13:57 -0000 On 19 Nov, 2012, at 2:32 pm, Oliver Hohlfeld wrote: >> (...) because the real problem was >> bufferbloat - and then work together to move forward, on an >> engineering, rather than political basis. > (...) >> I have long hoped to get these services aware >> that they needed to help fix bufferbloat if they wanted their cloud >> based businesses to work better. >=20 > Is there any evidence that they do suffer from bufferbloat? And if > so, how many of their customers are affected? 0.001%? 0.1%? 10%? > So, what is the economical extend of the problem for these services > providers? I see many websites whose bottleneck is the database containing their = content, not the physical uplink. They can easily be identified by the = way they serve up database connection errors when under unusually heavy = load. For example, http://www.robertsspaceindustries.com/ about 12 = hours ago, as they pushed through about $1M of pledges within 24 hours. = The Raspberry Pi site deliberately switched to a lightweight static page = for their launch event back in February, thereby staying up while two = major suppliers' sites (both operating very heavy e-commerce designs) = crashed hard under the load. Databases get used by a lot of websites these days, either as part of a = forum or e-commerce backend (entirely reasonable) or for serving up = standard but frequently updated content - where "frequently updated" = means several times a day, rather than several times a second. In this = latter case, it would make far more sense to periodically bake the = content into static pages that can be served without hitting the = database. This in turn would free up DB capacity for things that really = need it, such as the forum and e-commerce transactions. Only *then* does bufferbloat start to be relevant. Even so, I am also constantly amazed by the lack of performance of most = databases under a heavy read-mostly load. A lot of it could doubtless = be solved by tuning, but very few organisations seem to have the = competence to do this. A lot of it probably has to do with using = general-purpose databases for unsuitable purposes - sure, you can store = 19KB of text in a varchar field, and a quarter-megabyte image too, but = that doesn't mean you should do s in a high-performance application. There are, of course, many databases that are highly optimised, out of = the box, for storing large text and image data on a read-mostly basis, = even employing extensive caching to avoid unnecessary disk access. They = are commonly known as "filesystems". :-) - Jonathan Morton