Received: by 10.220.162.5 with SMTP id t5mr1068394vcx.3.1305188279594;
        Thu, 12 May 2011 01:17:59 -0700 (PDT)
X-BeenThere: google-appengine@googlegroups.com
Received: by 10.221.1.19 with SMTP id no19ls218204vcb.3.gmail; Thu, 12 May
 2011 01:17:36 -0700 (PDT)
Received: by 10.220.5.139 with SMTP id 11mr984325vcv.21.1305188256477;
        Thu, 12 May 2011 01:17:36 -0700 (PDT)
Date: Thu, 12 May 2011 01:17:35 -0700 (PDT)
From: peterk <peter.ke...@gmail.com>
Reply-To: google-appengine@googlegroups.com
To: google-appengine@googlegroups.com
Message-ID: <18590870.954.1305188255997.JavaMail.geo-discussion-forums@yqmi17>
In-Reply-To: <BANLkTimYCv_KyRiXimgm+cKwW-F0=1QxqA@mail.gmail.com>
Subject: Re: [google-appengine] What do you want to see answered in Greg's
 pricing FAQ?
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_952_29212320.1305188255996"

------=_Part_952_29212320.1305188255996
Content-Type: multipart/alternative; 
	boundary="----=_Part_953_3019747.1305188255996"

------=_Part_953_3019747.1305188255996
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

>> The smallest granularity will be 15 minutes, but part of the scheduler 
change is to ensure we don't start instances to serve 1 request.

This is useful to know so thank you for letting us know this. But it's 
disappointing to say the least. We're going from millisecond granularity 
with CPU-hours to chunks up to 15 minutes depending on how many requests you 
get out of a new instance. 

Anyway, in the FAQ, I'd like a transparent, honest answer about why the 
switch from CPU-hours to instance-hours (not a vague 'based on the value of 
the service', 'based on feedback'), and a comprehensive outline of the 
ramifications. 

Thanks,

-Peter

------=_Part_953_3019747.1305188255996
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

&gt;&gt;&nbsp;<span class=3D"Apple-style-span" style=3D"color: rgb(34, 34, =
34); ">The smallest granularity will be 15 minutes, but part of the schedul=
er change is to ensure we don't start instances to serve 1 request.</span><=
div><span class=3D"Apple-style-span" style=3D"color: rgb(34, 34, 34); "><br=
></span></div><div><span class=3D"Apple-style-span" style=3D"color: rgb(34,=
 34, 34); ">This is useful to know so thank you for letting us know this. B=
ut it's disappointing to say the least. We're going from millisecond granul=
arity with CPU-hours to chunks up to 15 minutes depending on how many reque=
sts you get out of a new instance.&nbsp;</span></div><div><span class=3D"Ap=
ple-style-span" style=3D"color: rgb(34, 34, 34); "><br></span></div><div><s=
pan class=3D"Apple-style-span" style=3D"color: rgb(34, 34, 34); ">Anyway, i=
n the FAQ, I'd like a transparent, honest answer about why the switch from =
CPU-hours to instance-hours (not a vague 'based on the value of the service=
', 'based on feedback'), and a comprehensive outline of the ramifications.&=
nbsp;</span></div><div><span class=3D"Apple-style-span" style=3D"color: rgb=
(34, 34, 34); "><br></span></div><div><span class=3D"Apple-style-span" styl=
e=3D"color: rgb(34, 34, 34); ">Thanks,</span></div><div><span class=3D"Appl=
e-style-span" style=3D"color: rgb(34, 34, 34); "><br></span></div><div><spa=
n class=3D"Apple-style-span" style=3D"color: rgb(34, 34, 34); ">-Peter</spa=
n></div>
------=_Part_953_3019747.1305188255996--

------=_Part_952_29212320.1305188255996--