[google-appengine] Google removing posts that raised concerns on the new pricing model?

[Raymond C.]

I noticed some threads that we have expressed our disappointments on the new 
pricing model got deleted without any notice.  Not to mention the same 
happened to the blog post as some user have reported 
(http://googleappengine.blogspot.com/2011/05/year-ahead-for-google-app-engine.html?showComment=1305435738777#c6941028597373000966)

Truly disappointed on Google doing this.  

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Why an app can't be Master/Slave and High Replication hybrid?

[Tapir]

The implementation would be very easy.
And the this will bring large convenience to developers.
After all, both options have their own advantages.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: FAQ for out of preview pricing changes

[Ugorji]

I know it's typical for people to say that java apps usually take a long 
time to start. IMO, the overhead of the JVM in startup is usually in the 
milliseconds range. Jetty barebones starts up in the milliseconds range. My 
app consistently starts up in less than 1 second, and it does a fair amount:
- does ORM against the datastore entities leveraging reflection extensively 
(sort of what Objectify does), 
- leverages a custom Dependency Injection framework with objects bound to 
jvm, thread and request scopes leveraging Reflection extensively (sort of 
like what Guice does), 
- reads stuff from the datastore at startup to pre-cache some non-changing 
entities, 
- creates data structures which end up using about 5MB of heap 

The high startup time of an app is a consequence of the libraries and 
frameworks you choose, and not a consequence of the language used. Granted, 
many Java based apps which use some popular frameworks which were not 
optimized for startup time will pay a cost, but that's a choice of the 
developer, not an inherent platform problem. 

>From what Greg mentioned, the 15 minutes idle time does not seem to be 
negotiable from the scheduler's point of view i.e. if your instance does 
work for 1 minute, it *will* remain resident for another 15 minutes before 
the system takes it offline, adding to your cost. For my app which starts up 
in less than 1 second (which feels instantly to a user), having to pay an 
extra 1/4 instance hour when I am charged by the instance hour is ... high. 
I'm basically being charged for doing nothing, even when I didn't ask you to 
keep me up. 

As a compromise, we should be able to tell the scheduler how long to keep 
extra instances up, since we know our application. The scheduler can give a 
minimum, but I think that minimum for the second instance and up should be 1 
minute and not 15 minutes. 

Also, this 15 minutes idle time applies irrespective of the language runtime 
used ie python apps which startup in milliseconds to do some extra work for 
a few seconds now have to pay an extra 1/4 instance hour each time. 

This may be fair for dynamic backends, which are designed to do latent 
tasks, but not for front-ends which are supposed to do quick sub-second 
operations.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: FAQ for out of preview pricing changes

[Vinuth Madinur]

One thing the new pricing has done is make developers think about the
scheduler a lot. Is it desirable? Should developers be tinkering with
the scheduler at all?

On 5/21/11, Gregory D'alesandre  wrote:
> I know I haven't been responding in this thread a lot but I've been reading
> what everyone is saying and working with the team here to map out some of
> the details in light of this.  I'll post next week with another update on
> the additional aspects that are finalized enough to discuss.
>
> Thanks again for all of the feedback and thoughts on this,
>
> Greg D'Alesandre
> Senior Product Manager, Google App Engine
>
> On Fri, May 20, 2011 at 1:43 AM, Tim  wrote:
>
>> Here's a suggestion GAE guys - how about the $9 minimum is per ACCOUNT
>> rather than per APP.
>>
>> Me - I've only got the one app, but for people who say "I've got 8 apps,
>> any one of which might just break the quota any month, but only by 50c or
>> so" then this would ease their burden a bit - $9 a month they can probably
>> fund, whereas $70 a month sounds a bit steep. Of course, ifu they're using
>> $70 of resources a month, then they pay that, but it eases the problem of
>> small bursts on a bunch of rarely used apps, and it gets you a paying
>> customer (it also encourages me, as a small user, to develop a couple more
>> apps once I'm paying for the basic facility)
>>
>> Just a thought...
>>
>> --
>> T
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Google App Engine" group.
>> To post to this group, send email to google-appengine@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-appengine+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: FAQ for out of preview pricing changes

[Raymond C.]

Regarding the new backends feature, I think its not only expensive, but very 
inefficient.  With the same cost we could rent a decent machine which does 
unlimited thing and handle thousands of request per second with web server 
like Tornado.  AppEngine backend instance can only handle one request at a 
time (python/go).  You need each request to finish within 1ms to handle more 
than one thousand request per second.  With datastore operation, less than 
100ms (i.e. handle 10 requests per second) is already nearly impossible.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: High execution time

[Raymond C.]

My application got 10% error during the last 18 hours. All uses db.put and 
db.get

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

RE: RE: [google-appengine] Re: Static Files: Here is a real Problem. Can I solve it with GAE?

[Brandon Wirtz]

To the why Azure:   Other parts of the service are moving to that and they
want to have all their eggs in one basket.  Which as we have talked about
can be a good thing if you have lots of parts, and can be down if any one
fails.

 

Big Companies and this being the norm: It is routine, it doesn't mean that I
don't have to do the work to get paid, it just means that I don't have to
support the work if it never actually gets deployed.  I would make more
money if it was deployed, but if not, yes I get paid for the consulting, and
the writing, and they get the knowledge that the solution they are currently
fighting is being solved.  Sometimes the sense of progress is as important
as actual progress.

 

 

 

From: google-appengine@googlegroups.com
[mailto:google-appengine@googlegroups.com] On Behalf Of Rohan Chandiramani
Sent: Friday, May 20, 2011 4:13 PM
To: google-appengine@googlegroups.com
Subject: Re: RE: [google-appengine] Re: Static Files: Here is a real
Problem. Can I solve it with GAE?

 

@Brandon

 

You talk like this is how it usually goes with big projects in big
company's?
In any case, it sounds like a pretty sweet deal for you. 

-- 
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: RE: [google-appengine] Static Files: Here is a real Problem. Can I solve it with GAE?

[Brandon Donnelson]

Want to use my botnet? ... just kidding :)

Brandon

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: RE: [google-appengine] Re: Static Files: Here is a real Problem. Can I solve it with GAE?

[Rohan Chandiramani]

@Brandon

You talk like this is how it usually goes with big projects in big 
company's?
In any case, it sounds like a pretty sweet deal for you.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Redirection problems after enabling OpenID

[Eric Kolotyluk]

After enabling the OpenID Federated Authentication on my app, when I
go to my app (via Firefox) I get the following

The page isn't redirecting properly

Firefox has detected that the server is redirecting the request for
this address in a way that will never complete.

This problem can sometimes be caused by disabling or refusing to
accept cookies.

Chrome gives me more or less the same response, but way more verbose.

IE9 just chokes.

I've seen these kind of redirect problems before with Google Apps, and
after a while they just magically went away.

Should I just wait and try again another day, or just give up on
trying to get OpenID to work?

Cheers, Eric

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Doc File

[Brandon Donnelson]

I've used open office api's to do the job and they work good. They have a 
nice java lib. 

http://api.openoffice.org/

Brandon Donnelson
http://gwt-examples.googlecode.com

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: RE: [google-appengine] Re: Static Files: Here is a real Problem. Can I solve it with GAE?

[Brandon Donnelson]

Do you know why they are leaning towards Azure?

Brandon

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

RE: [google-appengine] Re: Static Files: Here is a real Problem. Can I solve it with GAE?

[Brandon Wirtz]

Truthfully.  The Client wants the answer to be azure.  So likely I'll build
the code, tell them why it won't work on Azure.  And they will pressure
Microsoft to build out the hardware to make it work on Azure.  By then a
different solution will have been reached because the Product team will have
had to work around the issue, and I'll get paid for code that never gets
run.

 

 

 

From: google-appengine@googlegroups.com
[mailto:google-appengine@googlegroups.com] On Behalf Of Brandon Donnelson
Sent: Friday, May 20, 2011 3:44 PM
To: google-appengine@googlegroups.com
Subject: [google-appengine] Re: Static Files: Here is a real Problem. Can I
solve it with GAE?

 

Which direction do you plan to go?

 

Brandon Donnelson

http://gwt-examples.googlecode.com

-- 
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Is MapReduce still a flexible solution on AppEngine under the new pricing model?

[nickmilon]

Very interesting question:
"Is MapReduce still a flexible solution on AppEngine under the new
pricing model ?"
My answer: probably not, new pricing model makes mapreduce operations
a no - no. Price will be prohibitive for such operation especially
ones that depend  on many instances to run a job fast, unless those
used to take hours rather than minutes to complete.
So I guess the team can drop the "reduce" part and query based
mapreduce things from roadmap, new model renders  those irrelevant for
most use cases.
Also drawing a "danger - high $$$" icon as a precaution next to copy/
delete model buttons on control panel would be a good idea.

Nick

On May 20, 3:56 pm, "Raymond C."  wrote:
> As I know MapReduce rely on a relative large number of instances (on top of
> the normal traffic) to perform the calculation efficiently in parallel.
>  Under the new pricing model each instance will cost you 15min idle time
> after the job is done.  Therefore 15min times n instances are wasted (cost
> you without using them).  If n=8 (for a relatively small and slow task),
> there will be an additional cost of $0.16 just for one MapReduce operation.
>  It will be very costly if you are doing sth like hourly job like reporting.
>  8 instances will cost you $115.2/month for hourly MapReduce task, which is
> *in additional* to the cost of the actual run time, just for MapReduce
> tasks.
>
> My question is, is it still a flexible mechanism on AppEngine?  Or we should
> rely on external service to do these kind of calculation? (complex but could
> be more cost effective?)

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Static Files: Here is a real Problem. Can I solve it with GAE?

[Brandon Donnelson]

Which direction do you plan to go?

Brandon Donnelson
http://gwt-examples.googlecode.com

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: RE: [google-appengine] Static Files: Here is a real Problem. Can I solve it with GAE?

[Jeff Schnitzer]

Whether the edge cache works or not, you can bet that Google will
eventually figure out how to stop you from effectively DOSing the
system without paying for it :-)

This is a really fun problem to solve though.

Jeff

On Fri, May 20, 2011 at 2:34 PM, Chris Farmiloe  wrote:
> I do know that the scheduler is certainly not instant. So serving it
> dynamically via instances doesn't sound the solution.
> From zero to thousands of QPS is going to take some time for the scheduler
> to realize what is happening (like longer than 10mins) how fast is the
> traffic really going spike?
> Having the edge proxies cache it is the only hope, but there is no control
> (or even guidelines) on how these work or if they might just start ignoring
> you if you are killing them.
> Sounds fun!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] High execution time

[Felippe Bueno]

What could be happening ?

I'm getting too high execution time, and a lot of errors.
I can see a lot of deadline execeed error.
I have not changed any thing today. It is happening in 2 different
applications:

[image: Requests/Second (24 hrs)]

[image: Requests/Second (24 hrs)]


CPU Seconds Used/Second:

[image: Requests/Second (24 hrs)]


[image: Requests/Second (24 hrs)]

Errors/Second:

[image: Requests/Second (24 hrs)]

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Cron deadlines

[Jeff Schnitzer]

No prob, done:

http://code.google.com/p/googleappengine/issues/detail?id=5085

Jeff

On Fri, May 20, 2011 at 8:11 AM, Johan Euphrosine  wrote:
> Yes since 1.4.0 is deadline for offline cron request has been raised
> to 10 minutes:
> http://googleappengine.blogspot.com/2010/12/happy-holidays-from-app-engine-team-140.html
>
> Could you fill a documentation bug on:
> http://code.google.com/p/googleappengine/issues/entry
>
> And report it back here ?
>
> Thanks in advance.
>
> On Fri, May 20, 2011 at 12:14 PM, Strom  wrote:
>> Cron scripts have 10 minute limits.
>>
>> On May 20, 10:45 am, Jeff Schnitzer  wrote:
>>> The documentation for Scheduled Tasks says "A URL invoked by cron is
>>> subject to the same limits and quotas as a normal HTTP request,
>>> including the request time limit."
>>>
>>> Is there a reason for scheduled tasks to have a 30s limit rather than
>>> the 10m limit for tasks?  Seems silly to create a cron handler just to
>>> kick off a task which calls a task handler...
>>>
>>> Or is the documentation old and crons actually have 10m limits?
>>>
>>> Thanks,
>>> Jeff
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Google App Engine" group.
>> To post to this group, send email to google-appengine@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> google-appengine+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/google-appengine?hl=en.
>>
>>
>
>
>
> --
> Johan Euphrosine (proppy)
> Developer Programs Engineer
> Google Developer Relations
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to 
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/google-appengine?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: FAQ for out of preview pricing changes

[Gregory D'alesandre]

I know I haven't been responding in this thread a lot but I've been reading
what everyone is saying and working with the team here to map out some of
the details in light of this.  I'll post next week with another update on
the additional aspects that are finalized enough to discuss.

Thanks again for all of the feedback and thoughts on this,

Greg D'Alesandre
Senior Product Manager, Google App Engine

On Fri, May 20, 2011 at 1:43 AM, Tim  wrote:

> Here's a suggestion GAE guys - how about the $9 minimum is per ACCOUNT
> rather than per APP.
>
> Me - I've only got the one app, but for people who say "I've got 8 apps,
> any one of which might just break the quota any month, but only by 50c or
> so" then this would ease their burden a bit - $9 a month they can probably
> fund, whereas $70 a month sounds a bit steep. Of course, if they're using
> $70 of resources a month, then they pay that, but it eases the problem of
> small bursts on a bunch of rarely used apps, and it gets you a paying
> customer (it also encourages me, as a small user, to develop a couple more
> apps once I'm paying for the basic facility)
>
> Just a thought...
>
> --
> T
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: RE: [google-appengine] Static Files: Here is a real Problem. Can I solve it with GAE?

[Chris Farmiloe]

I do know that the scheduler is certainly not instant. So serving it 
dynamically via instances doesn't sound the solution.

>From zero to thousands of QPS is going to take some time for the scheduler 
to realize what is happening (like longer than 10mins) how fast is the 
traffic really going spike? 

Having the edge proxies cache it is the only hope, but there is no control 
(or even guidelines) on how these work or if they might just start ignoring 
you if you are killing them.

Sounds fun!

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: FAQ for out of preview pricing changes

[Ikai Lan (Google)]

Go instances cannot currently handle more than one request at a time, though
within a request you can use goroutines. Concurrent requests is something
that is likely coming. We're not providing a roadmap at this time, but that
team does read the go mailing list, so make sure your thoughts are heard
there.

Ikai Lan
Developer Programs Engineer, Google App Engine
Blog: http://googleappengine.blogspot.com
Twitter: http://twitter.com/app_engine
Reddit: http://www.reddit.com/r/appengine



On Fri, May 20, 2011 at 1:59 PM, DennisP  wrote:

> It seems that the inefficient use of instances is the biggest price
> hit for anyone who scales beyond minimal levels...and that Go could
> help a lot, even without multithreading. I'm no Go expert but Erlang,
> for example, can handle a huge number of concurrent requests with a
> single OS thread, and Go seems to have similar capabilities.
>
> It'd be great to get some information from Google on this. Even before
> Go apps are able to take advantage of multiple cores, will they be
> able to handle concurrent requests on one instance, instead of letting
> processor sit idle while it waits for data to arrive from storage?
>
> If so, then perhaps a viable shortcut would be to build one virtual
> machine running Go for each core of the physical machine, instead of
> trying to build Go to use multiple OS threads.
>
> With Go's concurrency and speed, it should be possible to handle quite
> a lot of requests per instance.
>
> (The other common complaint is the minimum for small apps. Google
> might want to consider that a lot of those apps are startups that
> failed. Most startups fail. If failure is cheap enough for us to fail
> a lot, we'll be more likely to find something that succeeds and scales
> up.)
>
> On May 20, 12:51 am, Jeff Schnitzer  wrote:
> > I think you're missing out on the bigger picture, which is that:
> >
> > 1) High-level decisionmakers inside Google are reading this thread.
> >
> > 2) Early input has greater potential influence than later input,
> > especially after a ton of billing code has been written and the
> > "momentum" of a big ship like Google has been established.
> >
> > 3) We here, right now, we're the focus group.  There is no better time
> > to speak up about your concerns.  The chances of your fears
> > materializing are much higher if you don't ask about them.  "Wait and
> > see" is a recipe for disappointment (in life).
> >
> > We've already seen one major change (half-price Python) which is a
> > tacit acknowledgement that the single-threaded model may be a
> > significant problem.  My goal by "bellyaching" is not to haggle the
> > lowest possible price out of appengine, but to get a competitive,
> > sustainable, cost-effective platform that makes both Google's
> > accountants and my accountants (and my clients' accountants) happy.
> > There are two risks - one is that Google unsustainably underprices
> > appengine, the other is that Google unsustainably overprices
> > appengine.  If it turns out that because of low levels of concurrency
> > these two overlap, we *all* have very big problems.
> >
> > In my mind, the biggest risk to the success of GAE is an architectural
> > issue that you and I have no control over.  The new pricing model is
> > largely symptomatic of a deeper problem, and it won't do Google any
> > good if the sustainable price is so high that the market flees.  An
> > instance on GAE may cost the same per hour as an "instance" somewhere
> > else, but of that other instance can do 10X the work in the same hour,
> > the market will eventually figure out that GAE isn't a very good deal.
> >
> > By the way, I *do* run several VPS servers with non-GAE projects -
> > some of which predate my love affair with appengine.  It's a fixed
> > outlay, but has the advantage that I can stack additional projects on
> > it for nearly no marginal cost.  It won't cost me an additional $9/mo
> > to build another project on it.
> >
> > At any rate, I place a lot of trust in the people behind appengine -
> > every one I've met has been super smart, engaged, and genuinely
> > interested in building what I still think is the coolest thing on the
> > internet.  But they won't succeed in doing that without lots of
> > customer feedback, so bellyache (constructively) as loud as you can as
> > long as they're willing to listen...
> >
> > Jeff
> >
> >
> >
> >
> >
> >
> >
> > On Thu, May 19, 2011 at 8:16 PM, Greg  wrote:
> > > It seems to me that many people are losing sight of the fact that
> > > there will still be a free tier.
> >
> > > So our proverbial web developer can tinker around with her app for as
> > > long as she wants, at no cost. Once SHE decides to, she can avail
> > > herself of scalability and an SLA for $9 a month, which seems very
> > > reasonable to me.
> >
> > > If her app needs more resources and she can't afford $9 a month, then
> > > her app is not financially sustainable and will die. A shame, but it
> > > has to happen. Other

[google-appengine] Re: FAQ for out of preview pricing changes

[DennisP]

It seems that the inefficient use of instances is the biggest price
hit for anyone who scales beyond minimal levels...and that Go could
help a lot, even without multithreading. I'm no Go expert but Erlang,
for example, can handle a huge number of concurrent requests with a
single OS thread, and Go seems to have similar capabilities.

It'd be great to get some information from Google on this. Even before
Go apps are able to take advantage of multiple cores, will they be
able to handle concurrent requests on one instance, instead of letting
processor sit idle while it waits for data to arrive from storage?

If so, then perhaps a viable shortcut would be to build one virtual
machine running Go for each core of the physical machine, instead of
trying to build Go to use multiple OS threads.

With Go's concurrency and speed, it should be possible to handle quite
a lot of requests per instance.

(The other common complaint is the minimum for small apps. Google
might want to consider that a lot of those apps are startups that
failed. Most startups fail. If failure is cheap enough for us to fail
a lot, we'll be more likely to find something that succeeds and scales
up.)

On May 20, 12:51 am, Jeff Schnitzer  wrote:
> I think you're missing out on the bigger picture, which is that:
>
> 1) High-level decisionmakers inside Google are reading this thread.
>
> 2) Early input has greater potential influence than later input,
> especially after a ton of billing code has been written and the
> "momentum" of a big ship like Google has been established.
>
> 3) We here, right now, we're the focus group.  There is no better time
> to speak up about your concerns.  The chances of your fears
> materializing are much higher if you don't ask about them.  "Wait and
> see" is a recipe for disappointment (in life).
>
> We've already seen one major change (half-price Python) which is a
> tacit acknowledgement that the single-threaded model may be a
> significant problem.  My goal by "bellyaching" is not to haggle the
> lowest possible price out of appengine, but to get a competitive,
> sustainable, cost-effective platform that makes both Google's
> accountants and my accountants (and my clients' accountants) happy.
> There are two risks - one is that Google unsustainably underprices
> appengine, the other is that Google unsustainably overprices
> appengine.  If it turns out that because of low levels of concurrency
> these two overlap, we *all* have very big problems.
>
> In my mind, the biggest risk to the success of GAE is an architectural
> issue that you and I have no control over.  The new pricing model is
> largely symptomatic of a deeper problem, and it won't do Google any
> good if the sustainable price is so high that the market flees.  An
> instance on GAE may cost the same per hour as an "instance" somewhere
> else, but of that other instance can do 10X the work in the same hour,
> the market will eventually figure out that GAE isn't a very good deal.
>
> By the way, I *do* run several VPS servers with non-GAE projects -
> some of which predate my love affair with appengine.  It's a fixed
> outlay, but has the advantage that I can stack additional projects on
> it for nearly no marginal cost.  It won't cost me an additional $9/mo
> to build another project on it.
>
> At any rate, I place a lot of trust in the people behind appengine -
> every one I've met has been super smart, engaged, and genuinely
> interested in building what I still think is the coolest thing on the
> internet.  But they won't succeed in doing that without lots of
> customer feedback, so bellyache (constructively) as loud as you can as
> long as they're willing to listen...
>
> Jeff
>
>
>
>
>
>
>
> On Thu, May 19, 2011 at 8:16 PM, Greg  wrote:
> > It seems to me that many people are losing sight of the fact that
> > there will still be a free tier.
>
> > So our proverbial web developer can tinker around with her app for as
> > long as she wants, at no cost. Once SHE decides to, she can avail
> > herself of scalability and an SLA for $9 a month, which seems very
> > reasonable to me.
>
> > If her app needs more resources and she can't afford $9 a month, then
> > her app is not financially sustainable and will die. A shame, but it
> > has to happen. Otherwise hundreds of thousands of unsustainable apps
> > will consume infrastructure and support resources, and increase the
> > cost for everyone else.
>
> > To those still bellyaching over $9, maybe you should build your own
> > server. Invest probably $1000 for hardware, $50 a month for internet
> > connection, and however many hours it takes to manage the machine. And
> > you can host all the other people's apps for free - or is it only
> > Google who should give away app hosting for free?
>
> > Or of course you could switch to AWS. Don't forget you'll need two
> > instances in different regions for redundancy, and the cost of
> > bandwidth between them to synchronise, and you still need to put in
> > quit

[google-appengine] Re: FAQ for out of preview pricing changes

[Spines]

@Ugorji

Shutting down an instance after 1 minute of inactivity would be bad
for java apps which usually take 5+ seconds to start up.  The
scheduler will probably take into account a bunch of different
variables in determining how long to leave an instance running.

On May 20, 11:52 am, Ugorji  wrote:
> Hi Greg,
>
> Thanks for the detailed response. It removes a lot of the uncertainty,
> allowing us focus on actual concerns.
>
> My main concerns now are:
> - prohibitive cost of backend instance
> - 15 minutes idle time cost for frontend instances
> - details on what experimental entails, with respect to GO runtime
>
> *Prohibitive cost of backend instance*
> Backend Instances seem ridiculously and prohibitively high ($115/month for a
> resident 256MB/1.2GHz instance). Their prohibitive costs makes them very
> unattractive for a lot of users who could leverage this functionality,
> causing us to look elsewhere.
>
> In a way, it seems we're caught between a rock and a hard place. Backends
> are an excellent way to do long-running CPU-intensive actions, allowing us
> move away from the current practice of spawning chains of tasks which each
> complete in a set time, or using a map-reduce operation. However, the
> backends are so expensive that most people will not use them. Unfortunately,
> the current practice of using frontend instances and tasks/map-reduce is now
> expensive also because for each instance, we have to pay an extra 1/4
> instance hour tax beyond our usage.
>
> *15 minutes idle time cost for frontend instances*
> For backends, the 1/4 hour may make sense, since backends are typically used
> for long-running tasks.
>
> However, for frontends where requests should typically finish within a
> second, and loading time can be within a second, the 1/4 hour tax seems
> unfair. Since loading time and request time for frontends can be within a
> second, it doesn't make sense to keep idle instances up for 15 minutes.
> Something in the tune of 1 minute for instances beyond the first one is more
> ideal (ie if u have one instance handling requests, keep the 15 minutes idle
> time. For instances 2 and up, shut them down after 1 minute of inactivity).
>
> *details on what experimental entails, with respect to GO runtime*
> The other question I had was with GO support. The current SDK
> - does not support transactions, batch datastore operations, parallel
> requests, etc
> - depends on using the remote API to the python SDK which could limit the
> ability to do some functionality (e.g. integrated testing framework, etc)
> - has an API which sometimes feels like a proof-of-concept API, and not a
> fully designed uniform API set
> - Also, the Google Group for it seems like a ghost town, which suggests
> either low interest or some level of disappointment in the current SDK set
>
> It looks really "experimental" unlike the Java SDK which was experimental
> when released but was much more featureful and integrated. Can you define
> what experimental means with respect to GO runtime:
> - how long will it be supported for, in case Google decides to pull the plug
> for lack of demand
> - is there a roadmap for the features.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Map Reduce Google I/O 2011 Talk

[Sport Apps]

I'm confused by the disparity between what the speaker says is
available in the talk and the examples/documentation I find at
http://code.google.com/p/appengine-mapreduce/.

I downloaded the svn repository which does now appear to support both
the shuffle and reduce phases of mapreduce but there are no examples
or documentation on how to do this.  The talk is unfortunately more a
tutorial on mapreduce than a how-to of doing it on app engine.

I'm sure I could figure out how to configure mapreduce.yaml to shuffle
and reduce from the code but it would obviously be very helpful to
have bare bones documentation and examples up there. has anyone seen
any?

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

RE: [google-appengine] Static Files: Here is a real Problem. Can I solve it with GAE?

[Brandon Wirtz]

Yeah I'm trying to not give away enough that one of you smart people could
go talk to them... but Yes it is a single Telco running a service and to
them, the 100G because of multiple paths would be background noise, like
checking email or loading ads.

We've kind of wandered off topic.  I was really asking what is the most
anyone has seen GAE handle, and would the scheduler take this? Or melt? And
what would it cost me.

-Original Message-
From: google-appengine@googlegroups.com
[mailto:google-appengine@googlegroups.com] On Behalf Of Barry Hunter
Sent: Friday, May 20, 2011 12:04 PM
To: google-appengine@googlegroups.com
Subject: Re: [google-appengine] Static Files: Here is a real Problem. Can I
solve it with GAE?

One ISP?

Get that ISP to install caching nodes. If you want to burst 100 Gigabits
though their network, its in their interest to help manage it!



On 20 May 2011 18:53, Brandon Wirtz  wrote:
> Good Call... All of the traffic comes from one "ISP" they cache the 
> DNS, no round robin possible.  They should change this, but they were 
> worried about the impact on the rest of their traffic.
>
>
>
> -Original Message-
> From: google-appengine@googlegroups.com 
> [mailto:google-appengine@googlegroups.com] On Behalf Of Barry Hunter
> Sent: Friday, May 20, 2011 3:56 AM
> To: google-appengine@googlegroups.com
> Subject: Re: [google-appengine] Static Files: Here is a real Problem. 
> Can I solve it with GAE?
>
> Build a CDN of CDNs?
>
> Serve some via Google, some via Akamai, some via Edgecast, some via 
> Cloudfront, etc.
>
> Will need a funky DNS server that can do round robin DNS (with 
> cnames), but you probably already looking at fairly specialist DNS 
> (your DNS traffic must spike too)
>
>
>
> On 20 May 2011 10:15, Brandon Wirtz  wrote:
>> I like you.  The CDN Players want about 4x what they should .  The 
>> problem for anyone is that it screws with their Peak Valley balance.
>>
>> The Adult hosts do a lot of load balancing that doesn't have to be 
>> low latency, they didn't think they could hit the 1.5 seconds.
>>
>> It’s the difference between serving big files at high latency and 
>> small files at low latency.
>>
>> In theory... If I ran master slave the edge cache would just handle 
>> this and I'd only pay for the first request. Do you think Google will 
>> let me do that on the Free Quota?
>>
>> -Original Message-
>> From: google-appengine@googlegroups.com 
>> [mailto:google-appengine@googlegroups.com] On Behalf Of Jeff 
>> Schnitzer
>> Sent: Friday, May 20, 2011 1:38 AM
>> To: google-appengine@googlegroups.com
>> Subject: Re: [google-appengine] Static Files: Here is a real Problem.
>> Can I solve it with GAE?
>>
>> 2M * 10K * 8 / 1.5 = you're trying to burst to ~100 Gigabits?
>>
>> I can't imagine you'll get that served out of a GAE datacenter, but 
>> it surprises me that the big CDN players can't do it.  Even the 
>> smallish players in the pron biz sustain over 10 Gbps... but nobody 
>> is going to offer you 95% billing for a 1.5s burst, of course.
>>
>> Jeff
>>
>> On Fri, May 20, 2011 at 1:19 AM, Brandon Wirtz 
> wrote:
>>> I wasn’t planning to use Python, I was using it as an example of the 
>>> billing at the "high end"  It would be interesting to see if Java 
>>> can really get to that number.
>>>
>>> I use Instance memory in my existing solution, and agree it is fast...
>>> the real question is if in the time before I could get the file in 
>>> to instance memory.  Also there is just the whole would Google 
>>> always have spare capacity for this.
>>>
>>> Likely I am porting my code to Java, to see if I can get the 20 
>>> threads per instance you are talking about.  If so that would save 
>>> me A Lot between now and Python 2.7
>>>
>>>
>>>
>>> -Original Message-
>>> From: google-appengine@googlegroups.com 
>>> [mailto:google-appengine@googlegroups.com] On Behalf Of Stephen 
>>> Johnson
>>> Sent: Friday, May 20, 2011 12:52 AM
>>> To: google-appengine@googlegroups.com
>>> Subject: Re: [google-appengine] Static Files: Here is a real Problem.
>>> Can I solve it with GAE?
>>>
>>> As a theoretical exercise and not knowing for one second if this 
>>> would in anyway work, but...
>>> Don't use Python. Use Java. Store file in instance memory. Should be 
>>> able to serve it with latency of 25ms or even less. So 40 requests 
>>> per second for just one thread. Should be able to get at least 20 
>>> threads going per instance or more if new scheduler is good since 
>>> their will be zero cpu utilization. So you're looking at 2500 
>>> instances max plus or minus. I'd also prime the pump so to speak.
>>> When you know it's going to happen start hitting your instances from 
>>> several other places like perhaps AWS to start kicking up instances.
>>> You're paying for the
>>> 15 minutes anyway. Get as many instances pre-started as possible and 
>>> ready to go.
>>>
>>> On Fri, May 20, 2011 at 12:25 AM, Jeff Schnitzer 
>>> 
>>> wrote:
 ...and by S3 I mean 

Re: [google-appengine] Static Files: Here is a real Problem. Can I solve it with GAE?

[Barry Hunter]

One ISP?

Get that ISP to install caching nodes. If you want to burst 100
Gigabits though their network, its in their interest to help manage
it!



On 20 May 2011 18:53, Brandon Wirtz  wrote:
> Good Call... All of the traffic comes from one "ISP" they cache the DNS, no
> round robin possible.  They should change this, but they were worried about
> the impact on the rest of their traffic.
>
>
>
> -Original Message-
> From: google-appengine@googlegroups.com
> [mailto:google-appengine@googlegroups.com] On Behalf Of Barry Hunter
> Sent: Friday, May 20, 2011 3:56 AM
> To: google-appengine@googlegroups.com
> Subject: Re: [google-appengine] Static Files: Here is a real Problem. Can I
> solve it with GAE?
>
> Build a CDN of CDNs?
>
> Serve some via Google, some via Akamai, some via Edgecast, some via
> Cloudfront, etc.
>
> Will need a funky DNS server that can do round robin DNS (with cnames), but
> you probably already looking at fairly specialist DNS (your DNS traffic must
> spike too)
>
>
>
> On 20 May 2011 10:15, Brandon Wirtz  wrote:
>> I like you.  The CDN Players want about 4x what they should .  The
>> problem for anyone is that it screws with their Peak Valley balance.
>>
>> The Adult hosts do a lot of load balancing that doesn't have to be low
>> latency, they didn't think they could hit the 1.5 seconds.
>>
>> It’s the difference between serving big files at high latency and
>> small files at low latency.
>>
>> In theory... If I ran master slave the edge cache would just handle
>> this and I'd only pay for the first request. Do you think Google will
>> let me do that on the Free Quota?
>>
>> -Original Message-
>> From: google-appengine@googlegroups.com
>> [mailto:google-appengine@googlegroups.com] On Behalf Of Jeff Schnitzer
>> Sent: Friday, May 20, 2011 1:38 AM
>> To: google-appengine@googlegroups.com
>> Subject: Re: [google-appengine] Static Files: Here is a real Problem.
>> Can I solve it with GAE?
>>
>> 2M * 10K * 8 / 1.5 = you're trying to burst to ~100 Gigabits?
>>
>> I can't imagine you'll get that served out of a GAE datacenter, but it
>> surprises me that the big CDN players can't do it.  Even the smallish
>> players in the pron biz sustain over 10 Gbps... but nobody is going to
>> offer you 95% billing for a 1.5s burst, of course.
>>
>> Jeff
>>
>> On Fri, May 20, 2011 at 1:19 AM, Brandon Wirtz 
> wrote:
>>> I wasn’t planning to use Python, I was using it as an example of the
>>> billing at the "high end"  It would be interesting to see if Java can
>>> really get to that number.
>>>
>>> I use Instance memory in my existing solution, and agree it is fast...
>>> the real question is if in the time before I could get the file in to
>>> instance memory.  Also there is just the whole would Google always
>>> have spare capacity for this.
>>>
>>> Likely I am porting my code to Java, to see if I can get the 20
>>> threads per instance you are talking about.  If so that would save me
>>> A Lot between now and Python 2.7
>>>
>>>
>>>
>>> -Original Message-
>>> From: google-appengine@googlegroups.com
>>> [mailto:google-appengine@googlegroups.com] On Behalf Of Stephen
>>> Johnson
>>> Sent: Friday, May 20, 2011 12:52 AM
>>> To: google-appengine@googlegroups.com
>>> Subject: Re: [google-appengine] Static Files: Here is a real Problem.
>>> Can I solve it with GAE?
>>>
>>> As a theoretical exercise and not knowing for one second if this
>>> would in anyway work, but...
>>> Don't use Python. Use Java. Store file in instance memory. Should be
>>> able to serve it with latency of 25ms or even less. So 40 requests
>>> per second for just one thread. Should be able to get at least 20
>>> threads going per instance or more if new scheduler is good since
>>> their will be zero cpu utilization. So you're looking at 2500
>>> instances max plus or minus. I'd also prime the pump so to speak.
>>> When you know it's going to happen start hitting your instances from
>>> several other places like perhaps AWS to start kicking up instances.
>>> You're paying for the
>>> 15 minutes anyway. Get as many instances pre-started as possible and
>>> ready to go.
>>>
>>> On Fri, May 20, 2011 at 12:25 AM, Jeff Schnitzer
>>> 
>>> wrote:
 ...and by S3 I mean CloudFront...

 On Fri, May 20, 2011 at 12:19 AM, Jeff Schnitzer
 
>>> wrote:
> S3 couldn't handle this?
>
> Jeff
>
> On Thu, May 19, 2011 at 11:21 PM, Brandon Wirtz
> 
>>> wrote:
>> While I do a Lot of things on GAE, I do a lot of things not on GAE.
>> I have a Client they are a BIG client.  You may have their service
>> in
>>> your home.
>>
>> They need a solution that will serve a file between 3 and 15k in
>> size to 2M devices in about 1500ms.
>>
>>
>>
>> The file will only come in to existence 15 seconds before hand.
>>
>>
>>
>> Python, on Future price model, not looking so affordable. 100ms
>> per request, is 15 requests per “window” 2m/15 is 133k instances.

[google-appengine] Re: FAQ for out of preview pricing changes

[Ugorji]

Hi Greg,

Thanks for the detailed response. It removes a lot of the uncertainty, 
allowing us focus on actual concerns.

My main concerns now are:
- prohibitive cost of backend instance
- 15 minutes idle time cost for frontend instances
- details on what experimental entails, with respect to GO runtime

*Prohibitive cost of backend instance*
Backend Instances seem ridiculously and prohibitively high ($115/month for a 
resident 256MB/1.2GHz instance). Their prohibitive costs makes them very 
unattractive for a lot of users who could leverage this functionality, 
causing us to look elsewhere.

In a way, it seems we're caught between a rock and a hard place. Backends 
are an excellent way to do long-running CPU-intensive actions, allowing us 
move away from the current practice of spawning chains of tasks which each 
complete in a set time, or using a map-reduce operation. However, the 
backends are so expensive that most people will not use them. Unfortunately, 
the current practice of using frontend instances and tasks/map-reduce is now 
expensive also because for each instance, we have to pay an extra 1/4 
instance hour tax beyond our usage.

*15 minutes idle time cost for frontend instances*
For backends, the 1/4 hour may make sense, since backends are typically used 
for long-running tasks. 

However, for frontends where requests should typically finish within a 
second, and loading time can be within a second, the 1/4 hour tax seems 
unfair. Since loading time and request time for frontends can be within a 
second, it doesn't make sense to keep idle instances up for 15 minutes. 
Something in the tune of 1 minute for instances beyond the first one is more 
ideal (ie if u have one instance handling requests, keep the 15 minutes idle 
time. For instances 2 and up, shut them down after 1 minute of inactivity).

*details on what experimental entails, with respect to GO runtime*
The other question I had was with GO support. The current SDK
- does not support transactions, batch datastore operations, parallel 
requests, etc
- depends on using the remote API to the python SDK which could limit the 
ability to do some functionality (e.g. integrated testing framework, etc)
- has an API which sometimes feels like a proof-of-concept API, and not a 
fully designed uniform API set
- Also, the Google Group for it seems like a ghost town, which suggests 
either low interest or some level of disappointment in the current SDK set

It looks really "experimental" unlike the Java SDK which was experimental 
when released but was much more featureful and integrated. Can you define 
what experimental means with respect to GO runtime:
- how long will it be supported for, in case Google decides to pull the plug 
for lack of demand
- is there a roadmap for the features.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Any Good Mechanism for detecting Approaching and Over Quota?

[Brandon Wirtz]

I decided to purge some datastore from the admin, and went over my CPU quota
8 hours later.

 

Does anyone have any sample code for getting the current quota use
percentage, hours remaining in day, and sending an email to say "OMG The Sky
Is Falling, Send Google Money"?  

 

 

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

RE: [google-appengine] Static Files: Here is a real Problem. Can I solve it with GAE?

[Brandon Wirtz]

Good Call... All of the traffic comes from one "ISP" they cache the DNS, no
round robin possible.  They should change this, but they were worried about
the impact on the rest of their traffic.



-Original Message-
From: google-appengine@googlegroups.com
[mailto:google-appengine@googlegroups.com] On Behalf Of Barry Hunter
Sent: Friday, May 20, 2011 3:56 AM
To: google-appengine@googlegroups.com
Subject: Re: [google-appengine] Static Files: Here is a real Problem. Can I
solve it with GAE?

Build a CDN of CDNs?

Serve some via Google, some via Akamai, some via Edgecast, some via
Cloudfront, etc.

Will need a funky DNS server that can do round robin DNS (with cnames), but
you probably already looking at fairly specialist DNS (your DNS traffic must
spike too)



On 20 May 2011 10:15, Brandon Wirtz  wrote:
> I like you.  The CDN Players want about 4x what they should .  The 
> problem for anyone is that it screws with their Peak Valley balance.
>
> The Adult hosts do a lot of load balancing that doesn't have to be low 
> latency, they didn't think they could hit the 1.5 seconds.
>
> It’s the difference between serving big files at high latency and 
> small files at low latency.
>
> In theory... If I ran master slave the edge cache would just handle 
> this and I'd only pay for the first request. Do you think Google will 
> let me do that on the Free Quota?
>
> -Original Message-
> From: google-appengine@googlegroups.com 
> [mailto:google-appengine@googlegroups.com] On Behalf Of Jeff Schnitzer
> Sent: Friday, May 20, 2011 1:38 AM
> To: google-appengine@googlegroups.com
> Subject: Re: [google-appengine] Static Files: Here is a real Problem. 
> Can I solve it with GAE?
>
> 2M * 10K * 8 / 1.5 = you're trying to burst to ~100 Gigabits?
>
> I can't imagine you'll get that served out of a GAE datacenter, but it 
> surprises me that the big CDN players can't do it.  Even the smallish 
> players in the pron biz sustain over 10 Gbps... but nobody is going to 
> offer you 95% billing for a 1.5s burst, of course.
>
> Jeff
>
> On Fri, May 20, 2011 at 1:19 AM, Brandon Wirtz 
wrote:
>> I wasn’t planning to use Python, I was using it as an example of the 
>> billing at the "high end"  It would be interesting to see if Java can 
>> really get to that number.
>>
>> I use Instance memory in my existing solution, and agree it is fast...
>> the real question is if in the time before I could get the file in to 
>> instance memory.  Also there is just the whole would Google always 
>> have spare capacity for this.
>>
>> Likely I am porting my code to Java, to see if I can get the 20 
>> threads per instance you are talking about.  If so that would save me 
>> A Lot between now and Python 2.7
>>
>>
>>
>> -Original Message-
>> From: google-appengine@googlegroups.com 
>> [mailto:google-appengine@googlegroups.com] On Behalf Of Stephen 
>> Johnson
>> Sent: Friday, May 20, 2011 12:52 AM
>> To: google-appengine@googlegroups.com
>> Subject: Re: [google-appengine] Static Files: Here is a real Problem.
>> Can I solve it with GAE?
>>
>> As a theoretical exercise and not knowing for one second if this 
>> would in anyway work, but...
>> Don't use Python. Use Java. Store file in instance memory. Should be 
>> able to serve it with latency of 25ms or even less. So 40 requests 
>> per second for just one thread. Should be able to get at least 20 
>> threads going per instance or more if new scheduler is good since 
>> their will be zero cpu utilization. So you're looking at 2500 
>> instances max plus or minus. I'd also prime the pump so to speak. 
>> When you know it's going to happen start hitting your instances from 
>> several other places like perhaps AWS to start kicking up instances. 
>> You're paying for the
>> 15 minutes anyway. Get as many instances pre-started as possible and 
>> ready to go.
>>
>> On Fri, May 20, 2011 at 12:25 AM, Jeff Schnitzer 
>> 
>> wrote:
>>> ...and by S3 I mean CloudFront...
>>>
>>> On Fri, May 20, 2011 at 12:19 AM, Jeff Schnitzer 
>>> 
>> wrote:
 S3 couldn't handle this?

 Jeff

 On Thu, May 19, 2011 at 11:21 PM, Brandon Wirtz 
 
>> wrote:
> While I do a Lot of things on GAE, I do a lot of things not on GAE.
> I have a Client they are a BIG client.  You may have their service 
> in
>> your home.
>
> They need a solution that will serve a file between 3 and 15k in 
> size to 2M devices in about 1500ms.
>
>
>
> The file will only come in to existence 15 seconds before hand.
>
>
>
> Python, on Future price model, not looking so affordable. 100ms 
> per request, is 15 requests per “window” 2m/15 is 133k instances. 
> With a minimum bill of
> 15 minutes at 5 cents per hour… that’s 33k hours $1,666 per 
> occurrence before bandwidth. And assuming everyone lines up in a 
> nice line and the scheduler does the right thing.
>
>
>
> This will happen about 3 times a week.  (and the $2k p

Re: [google-appengine] CPU Billing not updating correctly

[Mauro Asprea]

Thanks Greg, I think I was confused with the billing history table. I
understand now that the date of the first column is the "event" date, the
date when the report was received. And the 2nd date in the "Usage Report
for..." label, is the effective date of report in question. So basically the
billing report have a 36hs of delay or so , am I right?

Thanks ;)

On Thu, May 19, 2011 at 6:26 PM, Gregory D'alesandre wrote:

> It looks like your CPU went down 2 days ago and you are showing a bill from
> 3 days ago (usage report for 2011-05-15), wait another day or two and you
> should see the drop, if not, let me know.
>
> Thanks!
>
> Greg D'Alesandre
> Senior Product Manager, Google App Engine
>
> On Thu, May 19, 2011 at 9:16 AM, Brandon Wirtz wrote:
>
>> Verify that none of your other Versions are getting traffic.  I have had a
>> few issues where in testing I somehow let the Google Bot know about another
>> version of the site and it got indexed and trafficked and was running up a
>> bill, (and was a pain to get that moved over to the primary version)
>>
>>
>>
>> I need to figure out an easy way to make sure the non-default versions get
>> a different robots.txt
>>
>>
>>
>> In any event  check all of your versions to make sure the CPU usage is
>> actually down. If it is, this is likely a spot where you should contact the
>> billing support via their online form.
>>
>>
>>
>>
>>
>> *From:* google-appengine@googlegroups.com [mailto:
>> google-appengine@googlegroups.com] *On Behalf Of *Mauro Asprea
>> *Sent:* Thursday, May 19, 2011 2:33 AM
>> *To:* google-appengine@googlegroups.com
>> *Subject:* [google-appengine] CPU Billing not updating correctly
>>
>>
>>
>> Hi, a few days ago I have optimized my code to reduce my billing and CPU
>> utilization. I did work as you can see in the graph attached. But the
>> billing seems to have not noticed it at all as you see in the billing
>> attached (with a view of the now charges and the 4 days ago charges). SO I
>> am still being billed like the days before the optimization.
>>
>>
>>
>> What's going on here? How can I fix this? My app_id is wishandbam
>>
>> --
>> Mauro Sebastián Asprea
>>
>> E-Mail: mauroasp...@gmail.com
>>
>> Mobile: +34 654297582
>> Skype: mauro.asprea
>>
>> http://www.wishandbam.com/
>>
>> Algunos hombres ven las cosas como son y se preguntan porque. Otros sueñan
>> cosas que nunca fueron y se preguntan por qué no?.
>> George Bernard Shaw
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google App Engine" group.
>> To post to this group, send email to google-appengine@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-appengine+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine?hl=en.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google App Engine" group.
>> To post to this group, send email to google-appengine@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-appengine+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine?hl=en.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>



-- 
Mauro Sebastián Asprea

E-Mail: mauroasp...@gmail.com
Mobile: +34 654297582
Skype: mauro.asprea
http://www.wishandbam.com/

Algunos hombres ven las cosas como son y se preguntan porque. Otros sueñan
cosas que nunca fueron y se preguntan por qué no?.
George Bernard Shaw

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Error in upload java web application error message This application does not exist (app_id=u'xxxxxxx')

[SOHRAB HOSSAIN]

I have just created an sample java webapplication intended for Google
Application Engine. The application runs correctly in my local machine
but using the eclipse plugin I failed to upload the project in the
Google Application Engine ended up with the following error


java.io.IOException: Error posting to URL:
https://appengine.google.com/api/appversion/create?app_id=japaneseguestbook&version=1&;
404 Not Found
This application does not exist (app_id=u'japaneseguestbook').

PLZ. help

NB. The gmail account I am using for application is new.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Problem with GetFileContent()

[Justin@Cloudlock]

I am trying to download the contents of a file from a google doc to
the blobstore using the app engine python api v3. To do this, I wanted
to grab the contents of the file, store them in memory, and then write
the contents directly to the blobstore using the files api. This works
perfectly fine for users on the same domain. However, when I try to
call GetFileContent using a client with a user who is authenticated
via 2-legged-oauth on a document owned by someone on another domain I
have problems. I have verified that the user has sharing privileges
(fails for both reading and writing) and yet the server is still
responding with a 401: Unauthorized error. Any reason why this would
be?

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] The phone number has been sent too many messages or has already been used to confirm an account

[jschlier]

Hi,
when I want to create a new application, I havo to type in a mobile
phone number for SMS confirmation. After doing this the error message
"The phone number has been sent too many messages or has already been
used to confirm an account" is shown.
I have only one mobile phone number. How can I solve this problem?

Regards,
Jürgen

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] 回覆：400 Bad Request Deleting a composite index failed: ApplicationError: 1

[Rod Chen]

I got the same problem today when I deploy my code to app engine first time 
:-(

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] CMS for GAE

[Johan Euphrosine]

What about starting from bloggart, it is pretty hackable, and recently
they added a Page system:
https://github.com/Arachnid/bloggart/commit/76d8f6cc4319cb89bef8fa761b1bfb2f9b9e1af8

I don't think there is ACL for Page yet, but it could be a nice contribution :)

On Thu, May 19, 2011 at 12:14 PM, Niklas Rosencrantz  wrote:
> Hi
> One of the disadvantages with GAE is that there is no CMS like Drupal och
> Joomla to easily deploy new large projects. Is there a CMS for GAE in the
> making? I found myself creating the basic functions of a CMS from scratch ie
> adding, viewing, editing and deleting articles in a categorized system that
> I supposse Joomla could have done if it were PHP. Do you know of any
> projects for GAE that is like a CMS with the basic functions for instance
> that only the user who created an article can edit it?
> Thanks
> Niklas R
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>



-- 
Johan Euphrosine (proppy)
Developer Programs Engineer
Google Developer Relations

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Cron deadlines

[Johan Euphrosine]

Yes since 1.4.0 is deadline for offline cron request has been raised
to 10 minutes:
http://googleappengine.blogspot.com/2010/12/happy-holidays-from-app-engine-team-140.html

Could you fill a documentation bug on:
http://code.google.com/p/googleappengine/issues/entry

And report it back here ?

Thanks in advance.

On Fri, May 20, 2011 at 12:14 PM, Strom  wrote:
> Cron scripts have 10 minute limits.
>
> On May 20, 10:45 am, Jeff Schnitzer  wrote:
>> The documentation for Scheduled Tasks says "A URL invoked by cron is
>> subject to the same limits and quotas as a normal HTTP request,
>> including the request time limit."
>>
>> Is there a reason for scheduled tasks to have a 30s limit rather than
>> the 10m limit for tasks?  Seems silly to create a cron handler just to
>> kick off a task which calls a task handler...
>>
>> Or is the documentation old and crons actually have 10m limits?
>>
>> Thanks,
>> Jeff
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to 
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/google-appengine?hl=en.
>
>



-- 
Johan Euphrosine (proppy)
Developer Programs Engineer
Google Developer Relations

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: RE: [google-appengine] Generating static html files

[Johan Euphrosine]

Yes, since 1.4.3 App Engine allows you to programmatically create
blobstore blobs:
http://code.google.com/appengine/docs/python/blobstore/overview.html#Writing_Files_to_the_Blobstore

On Fri, May 20, 2011 at 12:40 PM, Barry Hunter  wrote:
> Umm, how about the blobstore?
> http://code.google.com/appengine/docs/python/blobstore/overview.html
>
> On 20 May 2011 05:14, PF  wrote:
>> There is 1MB limit for memcache. I can imagine when I'd like to show
>> statistic chart for last year there could be the need for more amount of
>> data then 1MB so I cannot use memcache. Also for such 1 year statistic it is
>> pretty enough to be recalculated only once per week e.g. Putting data to
>> memcache for one week is not so ideal from my point of view.
>>
>> No other way then memcache? Or are my arguments above not relevant?
>>
>> Thx,
>> Peter
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google App Engine" group.
>> To post to this group, send email to google-appengine@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-appengine+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to 
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/google-appengine?hl=en.
>
>



-- 
Johan Euphrosine (proppy)
Developer Programs Engineer
Google Developer Relations

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Doc File

[Johan Euphrosine]

You should be able to call Google Documents List API from App Engine to
create Google Docs, amd then export it to  .doc files:
http://code.google.com/apis/documents/docs/developers_guide.html

On Fri, May 20, 2011 at 12:51 PM, Brandon Wirtz  wrote:

> .docx is a standard you could likely make a sample with word using a place
> holder that was Variable1 Variable2 etc.  and then use that as a django
> template.  Same for RTF.
>
>
>
> Straight .doc is not as easy.
>
>
>
>
>
> *From:* google-appengine@googlegroups.com [mailto:
> google-appengine@googlegroups.com] *On Behalf Of *Massimiliano
> *Sent:* Friday, May 20, 2011 12:24 AM
> *To:* google-appengine
> *Subject:* [google-appengine] Doc File
>
>
>
> Hi to all,
>
> I have been requested to develop an app to manage an address list.
>
> The app must be have two features, the first is that the app have to send
> email to selected address (and this is quite easy for me), the second is
> that the app must have a function to export a .doc file with
> personalized traditional mail to be sent in paper. One big file with all the
> emails.
>
>
>
> How can I generate a .doc or .rtf file?
>
>
>
> Thanks
>
>
>
> Max
>
>
> --
>
> [image: Description: Image removed by 
> sender.]
>
>
>
> www.themaxbuddies.com 
>
> [image: Description: Image removed by sender.]
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>



-- 
Johan Euphrosine (proppy)
Developer Programs Engineer
Google Developer Relations

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

<<~WRD001.jpg>>

Re: [google-appengine] Re: Is MapReduce still a flexible solution on AppEngine under the new pricing model?

[Stephen]

On Fri, May 20, 2011 at 3:11 PM, johnP  wrote:
>
> One more point.  We all expected prices to increase.  What was a
> surprise is for the incentive model to flip as much as it did.


I expected prices to decrease. After 3 years of Moore's Law, why would
it cost more?

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Is MapReduce still a flexible solution on AppEngine under the new pricing model?

[Stephen]

On Fri, May 20, 2011 at 2:11 PM, Barry Hunter  wrote:
>
> 2) If you doing a regular  job, then reserved instances would most
> likely save you money.


I don't think so. Although reserved instance hours cost less, you pay
for hours you don't use as well as those you do. Your average price
only approaches the reserved price if you use every single hour.

Reserved instance hours are a bad fit for bursty map-reduce type jobs.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Is MapReduce still a flexible solution on AppEngine under the new pricing model?

[Vinuth Madinur]

+1

Interesting suggestion on pricing as a sum of response times, which is what
a user should be worried about, not tinkering with the scheduler.


On Fri, May 20, 2011 at 7:41 PM, johnP  wrote:

>
> One more point.  We all expected prices to increase.  What was a
> surprise is for the incentive model to flip as much as it did.
>
> Maybe a compromise pricing model is not based on # of instances, but
> on sum of response times?  This would eliminate the customer paying
> for inefficiencies in the scheduler.  Would return the customer value
> proposition to exactly "Pay for what you use".  And would bill the
> same resource you are intending to bill.  Maybe it's a semantic
> difference, but one that would retain the attractiveness of
> Appengine's original, amazing, revolutionary customer promise.
>
> johnP
>
>
> On May 20, 6:56 am, johnP  wrote:
> > Wow.  So many fundamental design assumptions are being turned on their
> > heads with the new incentive model!!!
> >
> > It is unfortunate that Google failed to make the 100% granular cost
> > model work.  The promise that made Appengine attractive was: You build
> > an app (adhering to our limitations).  We will make it scale, and you
> > pay only for what you use.  This was a clear promise that only an
> > amazing company could provide.
> >
> > But as time went on, the promise has crumbled, brick by brick.
> >  - The limitations became more intolerable (No SSL, No Data backups,
> > Reliability and uptime, > 2,500 open issues in the bug tracker).
> >  - The 'build it and we will scale it' promise retracted to "build it
> > and we will scale IF your response time is lower than 800 ms (wasn't
> > 600ms also mentioned?)."
> >  - The 'pay for what you use' promise has become, 'Amazon charges this
> > way - we can too."
> >  - Finally, "Our database architecture was wrong.  Pay to migrate to
> > our new datastore, which has the advantage of being reliable."
> >
> > Google has been stating recently, "The new pricing makes it viable for
> > us to continue to provide Appengine."  But Appengine will exist into
> > the future only if it is profitable for Google *AND* if customers find
> > it valuable.
> >
> > It would be nice to see the Appengine value proposition restated.
> > Given the new incentive model, what makes Appengine amazing?
> >
> > Thanks for listening.
> >
> > On May 20, 5:56 am, "Raymond C."  wrote:
> >
> >
> >
> >
> >
> >
> >
> > > As I know MapReduce rely on a relative large number of instances (on
> top of
> > > the normal traffic) to perform the calculation efficiently in parallel.
> > >  Under the new pricing model each instance will cost you 15min idle
> time
> > > after the job is done.  Therefore 15min times n instances are wasted
> (cost
> > > you without using them).  If n=8 (for a relatively small and slow
> task),
> > > there will be an additional cost of $0.16 just for one MapReduce
> operation.
> > >  It will be very costly if you are doing sth like hourly job like
> reporting.
> > >  8 instances will cost you $115.2/month for hourly MapReduce task,
> which is
> > > *in additional* to the cost of the actual run time, just for MapReduce
> > > tasks.
> >
> > > My question is, is it still a flexible mechanism on AppEngine?  Or we
> should
> > > rely on external service to do these kind of calculation? (complex but
> could
> > > be more cost effective?)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Is MapReduce still a flexible solution on AppEngine under the new pricing model?

[johnP]

One more point.  We all expected prices to increase.  What was a
surprise is for the incentive model to flip as much as it did.

Maybe a compromise pricing model is not based on # of instances, but
on sum of response times?  This would eliminate the customer paying
for inefficiencies in the scheduler.  Would return the customer value
proposition to exactly "Pay for what you use".  And would bill the
same resource you are intending to bill.  Maybe it's a semantic
difference, but one that would retain the attractiveness of
Appengine's original, amazing, revolutionary customer promise.

johnP


On May 20, 6:56 am, johnP  wrote:
> Wow.  So many fundamental design assumptions are being turned on their
> heads with the new incentive model!!!
>
> It is unfortunate that Google failed to make the 100% granular cost
> model work.  The promise that made Appengine attractive was: You build
> an app (adhering to our limitations).  We will make it scale, and you
> pay only for what you use.  This was a clear promise that only an
> amazing company could provide.
>
> But as time went on, the promise has crumbled, brick by brick.
>  - The limitations became more intolerable (No SSL, No Data backups,
> Reliability and uptime, > 2,500 open issues in the bug tracker).
>  - The 'build it and we will scale it' promise retracted to "build it
> and we will scale IF your response time is lower than 800 ms (wasn't
> 600ms also mentioned?)."
>  - The 'pay for what you use' promise has become, 'Amazon charges this
> way - we can too."
>  - Finally, "Our database architecture was wrong.  Pay to migrate to
> our new datastore, which has the advantage of being reliable."
>
> Google has been stating recently, "The new pricing makes it viable for
> us to continue to provide Appengine."  But Appengine will exist into
> the future only if it is profitable for Google *AND* if customers find
> it valuable.
>
> It would be nice to see the Appengine value proposition restated.
> Given the new incentive model, what makes Appengine amazing?
>
> Thanks for listening.
>
> On May 20, 5:56 am, "Raymond C."  wrote:
>
>
>
>
>
>
>
> > As I know MapReduce rely on a relative large number of instances (on top of
> > the normal traffic) to perform the calculation efficiently in parallel.
> >  Under the new pricing model each instance will cost you 15min idle time
> > after the job is done.  Therefore 15min times n instances are wasted (cost
> > you without using them).  If n=8 (for a relatively small and slow task),
> > there will be an additional cost of $0.16 just for one MapReduce operation.
> >  It will be very costly if you are doing sth like hourly job like reporting.
> >  8 instances will cost you $115.2/month for hourly MapReduce task, which is
> > *in additional* to the cost of the actual run time, just for MapReduce
> > tasks.
>
> > My question is, is it still a flexible mechanism on AppEngine?  Or we should
> > rely on external service to do these kind of calculation? (complex but could
> > be more cost effective?)

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Is MapReduce still a flexible solution on AppEngine under the new pricing model?

[johnP]

Wow.  So many fundamental design assumptions are being turned on their
heads with the new incentive model!!!

It is unfortunate that Google failed to make the 100% granular cost
model work.  The promise that made Appengine attractive was: You build
an app (adhering to our limitations).  We will make it scale, and you
pay only for what you use.  This was a clear promise that only an
amazing company could provide.

But as time went on, the promise has crumbled, brick by brick.
 - The limitations became more intolerable (No SSL, No Data backups,
Reliability and uptime, > 2,500 open issues in the bug tracker).
 - The 'build it and we will scale it' promise retracted to "build it
and we will scale IF your response time is lower than 800 ms (wasn't
600ms also mentioned?)."
 - The 'pay for what you use' promise has become, 'Amazon charges this
way - we can too."
 - Finally, "Our database architecture was wrong.  Pay to migrate to
our new datastore, which has the advantage of being reliable."

Google has been stating recently, "The new pricing makes it viable for
us to continue to provide Appengine."  But Appengine will exist into
the future only if it is profitable for Google *AND* if customers find
it valuable.

It would be nice to see the Appengine value proposition restated.
Given the new incentive model, what makes Appengine amazing?

Thanks for listening.




On May 20, 5:56 am, "Raymond C."  wrote:
> As I know MapReduce rely on a relative large number of instances (on top of
> the normal traffic) to perform the calculation efficiently in parallel.
>  Under the new pricing model each instance will cost you 15min idle time
> after the job is done.  Therefore 15min times n instances are wasted (cost
> you without using them).  If n=8 (for a relatively small and slow task),
> there will be an additional cost of $0.16 just for one MapReduce operation.
>  It will be very costly if you are doing sth like hourly job like reporting.
>  8 instances will cost you $115.2/month for hourly MapReduce task, which is
> *in additional* to the cost of the actual run time, just for MapReduce
> tasks.
>
> My question is, is it still a flexible mechanism on AppEngine?  Or we should
> rely on external service to do these kind of calculation? (complex but could
> be more cost effective?)

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Is MapReduce still a flexible solution on AppEngine under the new pricing model?

[Barry Hunter]

There are two mitigating things here,

1) The scheduler and instance concurrency is set to improve - meaning
less instances anyway - to do the same workload.

2) If you doing a regular  job, then reserved instances would most
likely save you money.


(And another possible, with Backends, could perhaps use a more
powerful instance to zip though tasks even quicker)


(or the shorter answer - this is still all based on speculation of the
new system, don't make decisions yet)


On 20 May 2011 13:56, Raymond C.  wrote:
> As I know MapReduce rely on a relative large number of instances (on top of
> the normal traffic) to perform the calculation efficiently in parallel.
>  Under the new pricing model each instance will cost you 15min idle time
> after the job is done.  Therefore 15min times n instances are wasted (cost
> you without using them).  If n=8 (for a relatively small and slow task),
> there will be an additional cost of $0.16 just for one MapReduce operation.
>  It will be very costly if you are doing sth like hourly job like reporting.
>  8 instances will cost you $115.2/month for hourly MapReduce task, which
> is in additional to the cost of the actual run time, just for MapReduce
> tasks.
> My question is, is it still a flexible mechanism on AppEngine?  Or we should
> rely on external service to do these kind of calculation? (complex but could
> be more cost effective?)
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Static Files: Here is a real Problem. Can I solve it with GAE?

[Wendel]

Sounds like a challenge, do you need a partner in crime? :-)

Wendel

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Is MapReduce still a flexible solution on AppEngine under the new pricing model?

[Raymond C.]

As I know MapReduce rely on a relative large number of instances (on top of 
the normal traffic) to perform the calculation efficiently in parallel. 
 Under the new pricing model each instance will cost you 15min idle time 
after the job is done.  Therefore 15min times n instances are wasted (cost 
you without using them).  If n=8 (for a relatively small and slow task), 
there will be an additional cost of $0.16 just for one MapReduce operation. 
 It will be very costly if you are doing sth like hourly job like reporting. 
 8 instances will cost you $115.2/month for hourly MapReduce task, which is 
*in additional* to the cost of the actual run time, just for MapReduce 
tasks.

My question is, is it still a flexible mechanism on AppEngine?  Or we should 
rely on external service to do these kind of calculation? (complex but could 
be more cost effective?)


-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: FAQ for out of preview pricing changes

[Wendel]

Why not host these 10 small apps under one app Id.

Make a startpage with icons for each of your creations. It it easier for 
your users to select one, and in case if one of the apps goes big, then move 
it to its own domain. It is cheaper for you and for google.

Wendel

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: FAQ for out of preview pricing changes

[Sylvain]

Even if I think that the monthly fee should be removed (or be a lot
cheaper), a fee per ACCOUNT is much better.

If a dev has 10 "small app", it will cost : $9 * 12 * 10 = $1080 just
for the monthly fee.
Currently this dev paies only less than $50 (only for few GB for
example).


On 20 mai, 10:43, Tim  wrote:
> Here's a suggestion GAE guys - how about the $9 minimum is per ACCOUNT
> rather than per APP.
>
> Me - I've only got the one app, but for people who say "I've got 8 apps, any
> one of which might just break the quota any month, but only by 50c or so"
> then this would ease their burden a bit - $9 a month they can probably fund,
> whereas $70 a month sounds a bit steep. Of course, if they're using $70 of
> resources a month, then they pay that, but it eases the problem of small
> bursts on a bunch of rarely used apps, and it gets you a paying customer (it
> also encourages me, as a small user, to develop a couple more apps once I'm
> paying for the basic facility)
>
> Just a thought...
>
> --
> T

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: FAQ for out of preview pricing changes

[Ubaldo Huerta]

Please googlers, 

1- Everybody wants (and got used to) to be worry free of trafic spikes. 
Figure out a way to charge $.50 for $.50 worth of resource consumption, not 
9$ for .50$ worth of consumption, even if it means paying one off 
 "entrance" fee. i.e. $30 setup fee for 30$ worth of resources consumed 
across all apps in the account. Don't "destroy" the wonderful, game changing 
"internet operating system" you're building with short sighted pricing that 
discourages experimentation.

2- While we're at it, please reconsider the email recipient cap 500?

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Static Files: Here is a real Problem. Can I solve it with GAE?

[Barry Hunter]

Build a CDN of CDNs?

Serve some via Google, some via Akamai, some via Edgecast, some via
Cloudfront, etc.

Will need a funky DNS server that can do round robin DNS (with
cnames), but you probably already looking at fairly specialist DNS
(your DNS traffic must spike too)



On 20 May 2011 10:15, Brandon Wirtz  wrote:
> I like you.  The CDN Players want about 4x what they should .  The problem
> for anyone is that it screws with their Peak Valley balance.
>
> The Adult hosts do a lot of load balancing that doesn't have to be low
> latency, they didn't think they could hit the 1.5 seconds.
>
> It’s the difference between serving big files at high latency and small
> files at low latency.
>
> In theory... If I ran master slave the edge cache would just handle this and
> I'd only pay for the first request. Do you think Google will let me do that
> on the Free Quota?
>
> -Original Message-
> From: google-appengine@googlegroups.com
> [mailto:google-appengine@googlegroups.com] On Behalf Of Jeff Schnitzer
> Sent: Friday, May 20, 2011 1:38 AM
> To: google-appengine@googlegroups.com
> Subject: Re: [google-appengine] Static Files: Here is a real Problem. Can I
> solve it with GAE?
>
> 2M * 10K * 8 / 1.5 = you're trying to burst to ~100 Gigabits?
>
> I can't imagine you'll get that served out of a GAE datacenter, but it
> surprises me that the big CDN players can't do it.  Even the smallish
> players in the pron biz sustain over 10 Gbps... but nobody is going to offer
> you 95% billing for a 1.5s burst, of course.
>
> Jeff
>
> On Fri, May 20, 2011 at 1:19 AM, Brandon Wirtz  wrote:
>> I wasn’t planning to use Python, I was using it as an example of the
>> billing at the "high end"  It would be interesting to see if Java can
>> really get to that number.
>>
>> I use Instance memory in my existing solution, and agree it is fast...
>> the real question is if in the time before I could get the file in to
>> instance memory.  Also there is just the whole would Google always
>> have spare capacity for this.
>>
>> Likely I am porting my code to Java, to see if I can get the 20
>> threads per instance you are talking about.  If so that would save me
>> A Lot between now and Python 2.7
>>
>>
>>
>> -Original Message-
>> From: google-appengine@googlegroups.com
>> [mailto:google-appengine@googlegroups.com] On Behalf Of Stephen
>> Johnson
>> Sent: Friday, May 20, 2011 12:52 AM
>> To: google-appengine@googlegroups.com
>> Subject: Re: [google-appengine] Static Files: Here is a real Problem.
>> Can I solve it with GAE?
>>
>> As a theoretical exercise and not knowing for one second if this would
>> in anyway work, but...
>> Don't use Python. Use Java. Store file in instance memory. Should be
>> able to serve it with latency of 25ms or even less. So 40 requests per
>> second for just one thread. Should be able to get at least 20 threads
>> going per instance or more if new scheduler is good since their will
>> be zero cpu utilization. So you're looking at 2500 instances max plus
>> or minus. I'd also prime the pump so to speak. When you know it's
>> going to happen start hitting your instances from several other places
>> like perhaps AWS to start kicking up instances. You're paying for the
>> 15 minutes anyway. Get as many instances pre-started as possible and
>> ready to go.
>>
>> On Fri, May 20, 2011 at 12:25 AM, Jeff Schnitzer 
>> wrote:
>>> ...and by S3 I mean CloudFront...
>>>
>>> On Fri, May 20, 2011 at 12:19 AM, Jeff Schnitzer
>>> 
>> wrote:
 S3 couldn't handle this?

 Jeff

 On Thu, May 19, 2011 at 11:21 PM, Brandon Wirtz
 
>> wrote:
> While I do a Lot of things on GAE, I do a lot of things not on GAE.
> I have a Client they are a BIG client.  You may have their service
> in
>> your home.
>
> They need a solution that will serve a file between 3 and 15k in
> size to 2M devices in about 1500ms.
>
>
>
> The file will only come in to existence 15 seconds before hand.
>
>
>
> Python, on Future price model, not looking so affordable. 100ms per
> request, is 15 requests per “window” 2m/15 is 133k instances. With
> a minimum bill of
> 15 minutes at 5 cents per hour… that’s 33k hours $1,666 per
> occurrence before bandwidth. And assuming everyone lines up in a
> nice line and the scheduler does the right thing.
>
>
>
> This will happen about 3 times a week.  (and the $2k price is not
> outside the realm of possibility but I’d like to mark it up and I
> think they are thinking 1/6 that to get the price to $75k after
> mark
> up.)
>
>
>
> By the way Amazon Laughed at me.
>
> When I told Akamai I wanted 95th percentile billing they stopped
> laughing at me.
>
>
>
> What are the theoretical and real limits of Static files.  If I
> created a python application that published the file as static will
> Static Scale to 2M requests a second? Or 1.3

RE: [google-appengine] Doc File

[Brandon Wirtz]

.docx is a standard you could likely make a sample with word using a place
holder that was Variable1 Variable2 etc.  and then use that as a django
template.  Same for RTF.

 

Straight .doc is not as easy.

 

 

From: google-appengine@googlegroups.com
[mailto:google-appengine@googlegroups.com] On Behalf Of Massimiliano
Sent: Friday, May 20, 2011 12:24 AM
To: google-appengine
Subject: [google-appengine] Doc File

 

Hi to all,

I have been requested to develop an app to manage an address list.

The app must be have two features, the first is that the app have to send
email to selected address (and this is quite easy for me), the second is
that the app must have a function to export a .doc file with personalized
traditional mail to be sent in paper. One big file with all the emails.

 

How can I generate a .doc or .rtf file? 

 

Thanks

 

Max


-- 

  Description: Image removed by sender.

 

www.themaxbuddies.com  

Description: Image removed by sender.

 

-- 
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

<<~WRD001.jpg>>

[google-appengine] Re: FAQ for out of preview pricing changes

[Matija]

Are frontend instances paid per instance hour with or without 15 minutes 
charge for instance startup ?

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: RE: [google-appengine] Generating static html files

[Barry Hunter]

Umm, how about the blobstore?
http://code.google.com/appengine/docs/python/blobstore/overview.html

On 20 May 2011 05:14, PF  wrote:
> There is 1MB limit for memcache. I can imagine when I'd like to show
> statistic chart for last year there could be the need for more amount of
> data then 1MB so I cannot use memcache. Also for such 1 year statistic it is
> pretty enough to be recalculated only once per week e.g. Putting data to
> memcache for one week is not so ideal from my point of view.
>
> No other way then memcache? Or are my arguments above not relevant?
>
> Thx,
> Peter
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Cron deadlines

[Strom]

Cron scripts have 10 minute limits.

On May 20, 10:45 am, Jeff Schnitzer  wrote:
> The documentation for Scheduled Tasks says "A URL invoked by cron is
> subject to the same limits and quotas as a normal HTTP request,
> including the request time limit."
>
> Is there a reason for scheduled tasks to have a 30s limit rather than
> the 10m limit for tasks?  Seems silly to create a cron handler just to
> kick off a task which calls a task handler...
>
> Or is the documentation old and crons actually have 10m limits?
>
> Thanks,
> Jeff

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

RE: [google-appengine] Static Files: Here is a real Problem. Can I solve it with GAE?

[Brandon Wirtz]

I like you.  The CDN Players want about 4x what they should .  The problem
for anyone is that it screws with their Peak Valley balance.  

The Adult hosts do a lot of load balancing that doesn't have to be low
latency, they didn't think they could hit the 1.5 seconds.

It’s the difference between serving big files at high latency and small
files at low latency.  

In theory... If I ran master slave the edge cache would just handle this and
I'd only pay for the first request. Do you think Google will let me do that
on the Free Quota?

-Original Message-
From: google-appengine@googlegroups.com
[mailto:google-appengine@googlegroups.com] On Behalf Of Jeff Schnitzer
Sent: Friday, May 20, 2011 1:38 AM
To: google-appengine@googlegroups.com
Subject: Re: [google-appengine] Static Files: Here is a real Problem. Can I
solve it with GAE?

2M * 10K * 8 / 1.5 = you're trying to burst to ~100 Gigabits?

I can't imagine you'll get that served out of a GAE datacenter, but it
surprises me that the big CDN players can't do it.  Even the smallish
players in the pron biz sustain over 10 Gbps... but nobody is going to offer
you 95% billing for a 1.5s burst, of course.

Jeff

On Fri, May 20, 2011 at 1:19 AM, Brandon Wirtz  wrote:
> I wasn’t planning to use Python, I was using it as an example of the 
> billing at the "high end"  It would be interesting to see if Java can 
> really get to that number.
>
> I use Instance memory in my existing solution, and agree it is fast... 
> the real question is if in the time before I could get the file in to 
> instance memory.  Also there is just the whole would Google always 
> have spare capacity for this.
>
> Likely I am porting my code to Java, to see if I can get the 20 
> threads per instance you are talking about.  If so that would save me 
> A Lot between now and Python 2.7
>
>
>
> -Original Message-
> From: google-appengine@googlegroups.com 
> [mailto:google-appengine@googlegroups.com] On Behalf Of Stephen 
> Johnson
> Sent: Friday, May 20, 2011 12:52 AM
> To: google-appengine@googlegroups.com
> Subject: Re: [google-appengine] Static Files: Here is a real Problem. 
> Can I solve it with GAE?
>
> As a theoretical exercise and not knowing for one second if this would 
> in anyway work, but...
> Don't use Python. Use Java. Store file in instance memory. Should be 
> able to serve it with latency of 25ms or even less. So 40 requests per 
> second for just one thread. Should be able to get at least 20 threads 
> going per instance or more if new scheduler is good since their will 
> be zero cpu utilization. So you're looking at 2500 instances max plus 
> or minus. I'd also prime the pump so to speak. When you know it's 
> going to happen start hitting your instances from several other places 
> like perhaps AWS to start kicking up instances. You're paying for the
> 15 minutes anyway. Get as many instances pre-started as possible and 
> ready to go.
>
> On Fri, May 20, 2011 at 12:25 AM, Jeff Schnitzer 
> wrote:
>> ...and by S3 I mean CloudFront...
>>
>> On Fri, May 20, 2011 at 12:19 AM, Jeff Schnitzer 
>> 
> wrote:
>>> S3 couldn't handle this?
>>>
>>> Jeff
>>>
>>> On Thu, May 19, 2011 at 11:21 PM, Brandon Wirtz 
>>> 
> wrote:
 While I do a Lot of things on GAE, I do a lot of things not on GAE.
 I have a Client they are a BIG client.  You may have their service 
 in
> your home.

 They need a solution that will serve a file between 3 and 15k in 
 size to 2M devices in about 1500ms.



 The file will only come in to existence 15 seconds before hand.



 Python, on Future price model, not looking so affordable. 100ms per 
 request, is 15 requests per “window” 2m/15 is 133k instances. With 
 a minimum bill of
 15 minutes at 5 cents per hour… that’s 33k hours $1,666 per 
 occurrence before bandwidth. And assuming everyone lines up in a 
 nice line and the scheduler does the right thing.



 This will happen about 3 times a week.  (and the $2k price is not 
 outside the realm of possibility but I’d like to mark it up and I 
 think they are thinking 1/6 that to get the price to $75k after 
 mark
 up.)



 By the way Amazon Laughed at me.

 When I told Akamai I wanted 95th percentile billing they stopped 
 laughing at me.



 What are the theoretical and real limits of Static files.  If I 
 created a python application that published the file as static will 
 Static Scale to 2M requests a second? Or 1.3M would likely do me.



 Would Google kick me off the service for abusing the .12 cents a 
 gig in ways they never imagined?







 --
 You received this message because you are subscribed to the Google 
 Groups "Google App Engine" group.
 To post to this group, send email to google-appengine@googlegroups.com.
 To unsubscribe from this group, send email to

Re: [google-appengine] Re: FAQ for out of preview pricing changes

[Tim]

Here's a suggestion GAE guys - how about the $9 minimum is per ACCOUNT 
rather than per APP.

Me - I've only got the one app, but for people who say "I've got 8 apps, any 
one of which might just break the quota any month, but only by 50c or so" 
then this would ease their burden a bit - $9 a month they can probably fund, 
whereas $70 a month sounds a bit steep. Of course, if they're using $70 of 
resources a month, then they pay that, but it eases the problem of small 
bursts on a bunch of rarely used apps, and it gets you a paying customer (it 
also encourages me, as a small user, to develop a couple more apps once I'm 
paying for the basic facility)

Just a thought...

--
T

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Static Files: Here is a real Problem. Can I solve it with GAE?

[Jeff Schnitzer]

2M * 10K * 8 / 1.5 = you're trying to burst to ~100 Gigabits?

I can't imagine you'll get that served out of a GAE datacenter, but it
surprises me that the big CDN players can't do it.  Even the smallish
players in the pron biz sustain over 10 Gbps... but nobody is going to
offer you 95% billing for a 1.5s burst, of course.

Jeff

On Fri, May 20, 2011 at 1:19 AM, Brandon Wirtz  wrote:
> I wasn’t planning to use Python, I was using it as an example of the billing
> at the "high end"  It would be interesting to see if Java can really get to
> that number.
>
> I use Instance memory in my existing solution, and agree it is fast... the
> real question is if in the time before I could get the file in to instance
> memory.  Also there is just the whole would Google always have spare
> capacity for this.
>
> Likely I am porting my code to Java, to see if I can get the 20 threads per
> instance you are talking about.  If so that would save me A Lot between now
> and Python 2.7
>
>
>
> -Original Message-
> From: google-appengine@googlegroups.com
> [mailto:google-appengine@googlegroups.com] On Behalf Of Stephen Johnson
> Sent: Friday, May 20, 2011 12:52 AM
> To: google-appengine@googlegroups.com
> Subject: Re: [google-appengine] Static Files: Here is a real Problem. Can I
> solve it with GAE?
>
> As a theoretical exercise and not knowing for one second if this would in
> anyway work, but...
> Don't use Python. Use Java. Store file in instance memory. Should be able to
> serve it with latency of 25ms or even less. So 40 requests per second for
> just one thread. Should be able to get at least 20 threads going per
> instance or more if new scheduler is good since their will be zero cpu
> utilization. So you're looking at 2500 instances max plus or minus. I'd also
> prime the pump so to speak. When you know it's going to happen start hitting
> your instances from several other places like perhaps AWS to start kicking
> up instances. You're paying for the
> 15 minutes anyway. Get as many instances pre-started as possible and ready
> to go.
>
> On Fri, May 20, 2011 at 12:25 AM, Jeff Schnitzer 
> wrote:
>> ...and by S3 I mean CloudFront...
>>
>> On Fri, May 20, 2011 at 12:19 AM, Jeff Schnitzer 
> wrote:
>>> S3 couldn't handle this?
>>>
>>> Jeff
>>>
>>> On Thu, May 19, 2011 at 11:21 PM, Brandon Wirtz 
> wrote:
 While I do a Lot of things on GAE, I do a lot of things not on GAE.
 I have a Client they are a BIG client.  You may have their service in
> your home.

 They need a solution that will serve a file between 3 and 15k in
 size to 2M devices in about 1500ms.



 The file will only come in to existence 15 seconds before hand.



 Python, on Future price model, not looking so affordable. 100ms per
 request, is 15 requests per “window” 2m/15 is 133k instances. With a
 minimum bill of
 15 minutes at 5 cents per hour… that’s 33k hours $1,666 per
 occurrence before bandwidth. And assuming everyone lines up in a
 nice line and the scheduler does the right thing.



 This will happen about 3 times a week.  (and the $2k price is not
 outside the realm of possibility but I’d like to mark it up and I
 think they are thinking 1/6 that to get the price to $75k after mark
 up.)



 By the way Amazon Laughed at me.

 When I told Akamai I wanted 95th percentile billing they stopped
 laughing at me.



 What are the theoretical and real limits of Static files.  If I
 created a python application that published the file as static will
 Static Scale to 2M requests a second? Or 1.3M would likely do me.



 Would Google kick me off the service for abusing the .12 cents a gig
 in ways they never imagined?







 --
 You received this message because you are subscribed to the Google
 Groups "Google App Engine" group.
 To post to this group, send email to google-appengine@googlegroups.com.
 To unsubscribe from this group, send email to
 google-appengine+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/google-appengine?hl=en.

>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
>> To post to this group, send email to google-appengine@googlegroups.com.
>> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
>> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.googl

RE: [google-appengine] Static Files: Here is a real Problem. Can I solve it with GAE?

[Brandon Wirtz]

I wasn’t planning to use Python, I was using it as an example of the billing
at the "high end"  It would be interesting to see if Java can really get to
that number.

I use Instance memory in my existing solution, and agree it is fast... the
real question is if in the time before I could get the file in to instance
memory.  Also there is just the whole would Google always have spare
capacity for this.

Likely I am porting my code to Java, to see if I can get the 20 threads per
instance you are talking about.  If so that would save me A Lot between now
and Python 2.7



-Original Message-
From: google-appengine@googlegroups.com
[mailto:google-appengine@googlegroups.com] On Behalf Of Stephen Johnson
Sent: Friday, May 20, 2011 12:52 AM
To: google-appengine@googlegroups.com
Subject: Re: [google-appengine] Static Files: Here is a real Problem. Can I
solve it with GAE?

As a theoretical exercise and not knowing for one second if this would in
anyway work, but...
Don't use Python. Use Java. Store file in instance memory. Should be able to
serve it with latency of 25ms or even less. So 40 requests per second for
just one thread. Should be able to get at least 20 threads going per
instance or more if new scheduler is good since their will be zero cpu
utilization. So you're looking at 2500 instances max plus or minus. I'd also
prime the pump so to speak. When you know it's going to happen start hitting
your instances from several other places like perhaps AWS to start kicking
up instances. You're paying for the
15 minutes anyway. Get as many instances pre-started as possible and ready
to go.

On Fri, May 20, 2011 at 12:25 AM, Jeff Schnitzer 
wrote:
> ...and by S3 I mean CloudFront...
>
> On Fri, May 20, 2011 at 12:19 AM, Jeff Schnitzer 
wrote:
>> S3 couldn't handle this?
>>
>> Jeff
>>
>> On Thu, May 19, 2011 at 11:21 PM, Brandon Wirtz 
wrote:
>>> While I do a Lot of things on GAE, I do a lot of things not on GAE.  
>>> I have a Client they are a BIG client.  You may have their service in
your home.
>>>
>>> They need a solution that will serve a file between 3 and 15k in 
>>> size to 2M devices in about 1500ms.
>>>
>>>
>>>
>>> The file will only come in to existence 15 seconds before hand.
>>>
>>>
>>>
>>> Python, on Future price model, not looking so affordable. 100ms per 
>>> request, is 15 requests per “window” 2m/15 is 133k instances. With a 
>>> minimum bill of
>>> 15 minutes at 5 cents per hour… that’s 33k hours $1,666 per 
>>> occurrence before bandwidth. And assuming everyone lines up in a 
>>> nice line and the scheduler does the right thing.
>>>
>>>
>>>
>>> This will happen about 3 times a week.  (and the $2k price is not 
>>> outside the realm of possibility but I’d like to mark it up and I 
>>> think they are thinking 1/6 that to get the price to $75k after mark 
>>> up.)
>>>
>>>
>>>
>>> By the way Amazon Laughed at me.
>>>
>>> When I told Akamai I wanted 95th percentile billing they stopped 
>>> laughing at me.
>>>
>>>
>>>
>>> What are the theoretical and real limits of Static files.  If I 
>>> created a python application that published the file as static will 
>>> Static Scale to 2M requests a second? Or 1.3M would likely do me.
>>>
>>>
>>>
>>> Would Google kick me off the service for abusing the .12 cents a gig 
>>> in ways they never imagined?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google 
>>> Groups "Google App Engine" group.
>>> To post to this group, send email to google-appengine@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> google-appengine+unsubscr...@googlegroups.com.
>>> For more options, visit this group at 
>>> http://groups.google.com/group/google-appengine?hl=en.
>>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.
>
>

--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.


-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: CMS for GAE

[roberto.cr]

allbuttonspressed.com comes to mind. it's based off django nonrel and
works nice with appengine.
a friend of mine showed it to me.
it's nice, but not exactly what most people would want from a CMS.


but I really wouldn't recommend anyone making a CMS just because you
need it.
this kind of lone-ranger CMS always gets done basically for what the
person needs, and not what a flexible CMS is supposed to provide.
and with all the need for plugins to work off the box, I don't see a
quick Joomla or Wordpress port working...


the thing about app engine is that, as it's so new, there's not much
things developed for it.
and I predict it never will, unless python takes off as the main
language for web apps;
that would require other cloud services such as Cloud Foundry to want
this as well...


On 19 maio, 21:54, "Brandon Wirtz"  wrote:
> It's certainly the best choice out there, it is missing XML-RPC Posting,
> NewPost Pinging to notify Google and others of new content, and it doesn't
> have many templates for themes. (always hard because it chicken and eggs
> with content)
>
> When I looked at it didn't have good page caching so it was REALLY expensive
> to run.  I think I was looking at $1.75 CPM for hosting.  I could have
> re-written it to fix that. but out of the box it was rough.
>
> From: google-appengine@googlegroups.com
> [mailto:google-appengine@googlegroups.com] On Behalf Of Ikai Lan (Google)
> Sent: Thursday, May 19, 2011 5:26 PM
> To: Google App Engine
> Subject: Re: [google-appengine] CMS for GAE
>
> What about Vosao?
>
> http://www.vosao.org/
>
> Ikai Lan
> Developer Programs Engineer, Google App Engine
>
> Blog:http://googleappengine.blogspot.com
>
> Twitter:http://twitter.com/app_engine
>
> Reddit:http://www.reddit.com/r/appengine
>
> On Thu, May 19, 2011 at 9:10 AM, Brandon Wirtz  wrote:
>
> I looked at creating a CMS on AppEngine, and quickly discovered that the
> issue is that most users of a CMS want their plugins.  The hill to get over
> in terms  of install base is formidable when you consider that Java, and
> Python are not as commonly spoken languages as PHP, Ruby, and ASP.  That's
> whywww.LockerGnome.commoved to GAE via CDNinabox.com
>
> Rather than porting code it was far cheaper and easier to use GAE as an
> Accelerator than it was to create a CMS from Scratch.
>
> If you are going to build a CMS, from what our clients have asked for the
> top things they want that most CMS attempts are lacking:
>
> Post Via XMLRPC
>
> RSS by Tags, Author, Category
>
> XML Sitemaps
>
> Easy Conversion of themes from other CMS's to the CMS
>
> As such you may want to look at other Django templates for CMS's and try and
> be compatible with those, or mostly compatible with those, to make it easier
> for users to switch.
>
> From: google-appengine@googlegroups.com
> [mailto:google-appengine@googlegroups.com] On Behalf Of Niklas Rosencrantz
> Sent: Thursday, May 19, 2011 3:15 AM
> To: google-appengine@googlegroups.com
> Subject: [google-appengine] CMS for GAE
>
> Hi
> One of the disadvantages with GAE is that there is no CMS like Drupal och
> Joomla to easily deploy new large projects. Is there a CMS for GAE in the
> making? I found myself creating the basic functions of a CMS from scratch ie
> adding, viewing, editing and deleting articles in a categorized system that
> I supposse Joomla could have done if it were PHP. Do you know of any
> projects for GAE that is like a CMS with the basic functions for instance
> that only the user who created an article can edit it?
> Thanks
> Niklas R
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/google-appengine?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com
>  .
> For more options, visit this group 
> athttp://groups.google.com/group/google-appengine?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/google-appengine?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+uns

RE: [google-appengine] Static Files: Here is a real Problem. Can I solve it with GAE?

[Brandon Wirtz]

They laughed, and laughed.  Apparently they can't get enough stuff to the
edges fast enough, and when they get to the edges they aren't set up to
handle that kind of load.

"No one can do that, it's not possible. Not because it can't be done, but
because anyone who let you do it would go broke in the process."

-Brandon


-Original Message-
From: google-appengine@googlegroups.com
[mailto:google-appengine@googlegroups.com] On Behalf Of Jeff Schnitzer
Sent: Friday, May 20, 2011 12:19 AM
To: google-appengine@googlegroups.com
Subject: Re: [google-appengine] Static Files: Here is a real Problem. Can I
solve it with GAE?

S3 couldn't handle this?

Jeff

On Thu, May 19, 2011 at 11:21 PM, Brandon Wirtz  wrote:
> While I do a Lot of things on GAE, I do a lot of things not on GAE.  I 
> have a Client they are a BIG client.  You may have their service in your
home.
>
> They need a solution that will serve a file between 3 and 15k in size 
> to 2M devices in about 1500ms.
>
>
>
> The file will only come in to existence 15 seconds before hand.
>
>
>
> Python, on Future price model, not looking so affordable. 100ms per 
> request, is 15 requests per “window” 2m/15 is 133k instances. With a 
> minimum bill of
> 15 minutes at 5 cents per hour… that’s 33k hours $1,666 per occurrence 
> before bandwidth. And assuming everyone lines up in a nice line and 
> the scheduler does the right thing.
>
>
>
> This will happen about 3 times a week.  (and the $2k price is not 
> outside the realm of possibility but I’d like to mark it up and I 
> think they are thinking 1/6 that to get the price to $75k after mark 
> up.)
>
>
>
> By the way Amazon Laughed at me.
>
> When I told Akamai I wanted 95th percentile billing they stopped 
> laughing at me.
>
>
>
> What are the theoretical and real limits of Static files.  If I 
> created a python application that published the file as static will 
> Static Scale to 2M requests a second? Or 1.3M would likely do me.
>
>
>
> Would Google kick me off the service for abusing the .12 cents a gig 
> in ways they never imagined?
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google 
> Groups "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>

--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.


-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Static Files: Here is a real Problem. Can I solve it with GAE?

[Stephen Johnson]

As a theoretical exercise and not knowing for one second if this would
in anyway work, but...
Don't use Python. Use Java. Store file in instance memory. Should be
able to serve it with latency of 25ms or even less. So 40 requests per
second for just one thread. Should be able to get at least 20 threads
going per instance or more if new scheduler is good since their will
be zero cpu utilization. So you're looking at 2500 instances max plus
or minus. I'd also prime the pump so to speak. When you know it's
going to happen start hitting your instances from several other places
like perhaps AWS to start kicking up instances. You're paying for the
15 minutes anyway. Get as many instances pre-started as possible and
ready to go.

On Fri, May 20, 2011 at 12:25 AM, Jeff Schnitzer  wrote:
> ...and by S3 I mean CloudFront...
>
> On Fri, May 20, 2011 at 12:19 AM, Jeff Schnitzer  wrote:
>> S3 couldn't handle this?
>>
>> Jeff
>>
>> On Thu, May 19, 2011 at 11:21 PM, Brandon Wirtz  wrote:
>>> While I do a Lot of things on GAE, I do a lot of things not on GAE.  I have
>>> a Client they are a BIG client.  You may have their service in your home.
>>>
>>> They need a solution that will serve a file between 3 and 15k in size to 2M
>>> devices in about 1500ms.
>>>
>>>
>>>
>>> The file will only come in to existence 15 seconds before hand.
>>>
>>>
>>>
>>> Python, on Future price model, not looking so affordable. 100ms per request,
>>> is 15 requests per “window” 2m/15 is 133k instances. With a minimum bill of
>>> 15 minutes at 5 cents per hour… that’s 33k hours $1,666 per occurrence
>>> before bandwidth. And assuming everyone lines up in a nice line and the
>>> scheduler does the right thing.
>>>
>>>
>>>
>>> This will happen about 3 times a week.  (and the $2k price is not outside
>>> the realm of possibility but I’d like to mark it up and I think they are
>>> thinking 1/6 that to get the price to $75k after mark up.)
>>>
>>>
>>>
>>> By the way Amazon Laughed at me.
>>>
>>> When I told Akamai I wanted 95th percentile billing they stopped laughing at
>>> me.
>>>
>>>
>>>
>>> What are the theoretical and real limits of Static files.  If I created a
>>> python application that published the file as static will Static Scale to 2M
>>> requests a second? Or 1.3M would likely do me.
>>>
>>>
>>>
>>> Would Google kick me off the service for abusing the .12 cents a gig in ways
>>> they never imagined?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Google App Engine" group.
>>> To post to this group, send email to google-appengine@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> google-appengine+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/google-appengine?hl=en.
>>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to 
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/google-appengine?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Cron deadlines

[Jeff Schnitzer]

The documentation for Scheduled Tasks says "A URL invoked by cron is
subject to the same limits and quotas as a normal HTTP request,
including the request time limit."

Is there a reason for scheduled tasks to have a 30s limit rather than
the 10m limit for tasks?  Seems silly to create a cron handler just to
kick off a task which calls a task handler...

Or is the documentation old and crons actually have 10m limits?

Thanks,
Jeff

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Static Files: Here is a real Problem. Can I solve it with GAE?

[Jeff Schnitzer]

...and by S3 I mean CloudFront...

On Fri, May 20, 2011 at 12:19 AM, Jeff Schnitzer  wrote:
> S3 couldn't handle this?
>
> Jeff
>
> On Thu, May 19, 2011 at 11:21 PM, Brandon Wirtz  wrote:
>> While I do a Lot of things on GAE, I do a lot of things not on GAE.  I have
>> a Client they are a BIG client.  You may have their service in your home.
>>
>> They need a solution that will serve a file between 3 and 15k in size to 2M
>> devices in about 1500ms.
>>
>>
>>
>> The file will only come in to existence 15 seconds before hand.
>>
>>
>>
>> Python, on Future price model, not looking so affordable. 100ms per request,
>> is 15 requests per “window” 2m/15 is 133k instances. With a minimum bill of
>> 15 minutes at 5 cents per hour… that’s 33k hours $1,666 per occurrence
>> before bandwidth. And assuming everyone lines up in a nice line and the
>> scheduler does the right thing.
>>
>>
>>
>> This will happen about 3 times a week.  (and the $2k price is not outside
>> the realm of possibility but I’d like to mark it up and I think they are
>> thinking 1/6 that to get the price to $75k after mark up.)
>>
>>
>>
>> By the way Amazon Laughed at me.
>>
>> When I told Akamai I wanted 95th percentile billing they stopped laughing at
>> me.
>>
>>
>>
>> What are the theoretical and real limits of Static files.  If I created a
>> python application that published the file as static will Static Scale to 2M
>> requests a second? Or 1.3M would likely do me.
>>
>>
>>
>> Would Google kick me off the service for abusing the .12 cents a gig in ways
>> they never imagined?
>>
>>
>>
>>
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google App Engine" group.
>> To post to this group, send email to google-appengine@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-appengine+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine?hl=en.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Doc File

[Massimiliano]

Hi to all,
I have been requested to develop an app to manage an address list.
The app must be have two features, the first is that the app have to send
email to selected address (and this is quite easy for me), the second is
that the app must have a function to export a .doc file with
personalized traditional mail to be sent in paper. One big file with all the
emails.

How can I generate a .doc or .rtf file?

Thanks

Max

-- 


www.themaxbuddies.com 

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Static Files: Here is a real Problem. Can I solve it with GAE?

[Jeff Schnitzer]

S3 couldn't handle this?

Jeff

On Thu, May 19, 2011 at 11:21 PM, Brandon Wirtz  wrote:
> While I do a Lot of things on GAE, I do a lot of things not on GAE.  I have
> a Client they are a BIG client.  You may have their service in your home.
>
> They need a solution that will serve a file between 3 and 15k in size to 2M
> devices in about 1500ms.
>
>
>
> The file will only come in to existence 15 seconds before hand.
>
>
>
> Python, on Future price model, not looking so affordable. 100ms per request,
> is 15 requests per “window” 2m/15 is 133k instances. With a minimum bill of
> 15 minutes at 5 cents per hour… that’s 33k hours $1,666 per occurrence
> before bandwidth. And assuming everyone lines up in a nice line and the
> scheduler does the right thing.
>
>
>
> This will happen about 3 times a week.  (and the $2k price is not outside
> the realm of possibility but I’d like to mark it up and I think they are
> thinking 1/6 that to get the price to $75k after mark up.)
>
>
>
> By the way Amazon Laughed at me.
>
> When I told Akamai I wanted 95th percentile billing they stopped laughing at
> me.
>
>
>
> What are the theoretical and real limits of Static files.  If I created a
> python application that published the file as static will Static Scale to 2M
> requests a second? Or 1.3M would likely do me.
>
>
>
> Would Google kick me off the service for abusing the .12 cents a gig in ways
> they never imagined?
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: In Python how do you detect if a JPEG uses CMYK color space and how do you convert it to RGB?

[Alexander Maslov]

JPEG format on it's own has nothing to do with CMYK color space. JPEG was 
made with RGB nature of on screen images in mind. Usage of CMYK color space 
before compression stage in JPEG file is handled by some software product 
with their own color space conversion algorithms. If there is no standards, 
why Google should support it?  

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: FAQ for out of preview pricing changes

[Vinuth Madinur]

What is being asked for is an intermediate pricing, where there is no SLA,
but apps can slightly exceed their free quotas(to some degree) in terms of
instance hours, storage, etc., without a $9 minimum.


On Fri, May 20, 2011 at 8:46 AM, Greg  wrote:

> It seems to me that many people are losing sight of the fact that
> there will still be a free tier.
>
> So our proverbial web developer can tinker around with her app for as
> long as she wants, at no cost. Once SHE decides to, she can avail
> herself of scalability and an SLA for $9 a month, which seems very
> reasonable to me.
>
> If her app needs more resources and she can't afford $9 a month, then
> her app is not financially sustainable and will die. A shame, but it
> has to happen. Otherwise hundreds of thousands of unsustainable apps
> will consume infrastructure and support resources, and increase the
> cost for everyone else.
>
> To those still bellyaching over $9, maybe you should build your own
> server. Invest probably $1000 for hardware, $50 a month for internet
> connection, and however many hours it takes to manage the machine. And
> you can host all the other people's apps for free - or is it only
> Google who should give away app hosting for free?
>
> Or of course you could switch to AWS. Don't forget you'll need two
> instances in different regions for redundancy, and the cost of
> bandwidth between them to synchronise, and you still need to put in
> quite a lot of time managing it all... does $9 seem reasonable now?
>
> There is still a lot of dust in the air - we don't know how the new
> scheduler will work, and it may be that Python 2.7 and multiple
> threads suddenly makes everything ten times cheaper. We really don't
> know what the new costs will be until we get comparison billing. But
> after all is said and done, I'm still glad I built my apps on
> Appengine, and I'm glad Google are making it more commercially
> sustainable.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.