Re: [google-appengine] Re: Updated App Engine Pricing FAQ!
Oy, this is my fault for fanning the flames. I apologize for letting this topic catch fire in the wrong places. Before we go into more name calling: Vivek has been an App Engine developer for a while, almost from the beginning, while Jeff maintains one of the most popular Java libraries for GAE - Objectify - and trust me when I say that he *does* know what he is talking about. My statement called into question the assertion that PHP was what App Engine needed. While the long term, we-could-do-this-if-we-had-infinite-resources goal is certainly to support EVERY language conceivable to man on App Engine, this is probably something that Google will not do in the near term timeframe. More developers does not translate into a sustainable pricing strategy. Believe it or not, not everything gets cheaper just because you have more users. Some things actually get more expensive. Official support for PHP is one of these things. App Engine was an internal tool before it was an external one. We launched Python because we understand it. We launched Java because we understand it, and there is a huge userbase. Some Java users expected to be able to port their knowledge of Spring/JSF/Wicket/etc immediately over to App Engine without having to learn anything new. I think we set the expectations incorrectly here. The plan that is in place will be very close to what we launch with, because when we looked at different pricing plans, our analysis of previous usage trends and billing led us to believe that the one we have announced was the most balanced in terms of being developer friendly as well as sustainable. Unfortunately, we did understand that the changes would not work for some people. The most constructive discussion we can have right now is around how we can make this pricing work. What tools can we provide? What data do we not display? How should support work? And so forth. Throttler knobs, for instance, are an example of a feature where much of the requirements were sourced from constructive user feedback. Raising the priority of Python concurrency was another one. To answer the JDO question: have you tried comment #13? Seems to resolve the issue: http://code.google.com/p/googleappengine/issues/detail?id=4834#c13 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, Jun 30, 2011 at 3:11 AM, Branko Vukelic wrote: > On Wed, Jun 29, 2011 at 8:29 PM, Jeff Schnitzer > wrote: > > On Wed, Jun 29, 2011 at 11:14 AM, vivpuri wrote: > >> @Jeff i dont you have the development experience on AppEngine to even > >> take part on this discussion. Before suggesting, first go an check > >> what Quercus does and can enable you to do on AppEngine. > > > > This is the stupidest thing anyone has said to me in years. > > And more to come if you keep replying to him. :) > > -- > Branko Vukelić > bra...@herdhound.com > > Lead Developer > Herd Hound (tm) - Travel that doesn't bite > www.herdhound.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.
Re: [google-appengine] Re: Thread-safe Python Tips
I don't believe you'll need to do anything when we ship concurrent requests for Python, as long as you're not using global mutable state anywhere. It's unlikely your threads will ever need to talk to each other. 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, Jun 30, 2011 at 4:57 AM, jay wrote: > We are not going to have to go into that much detail for our apps > thought are we. > > Will we be able to take advantage of the multi-threading by simply > creating multiple request handlers. I imagined I would be changing a > few lines of code in my main function an that's about it. > > On Jun 29, 9:43 pm, Joshua Smith wrote: > > I would assume they are the same as the basic principles of thread safety > in any language: > > > > - Don't rely on global state, because multiple of your functions might be > running simultaneously > > > > This usually isn't very hard to achieve - just pass parameters instead of > modifying globals. The places where it can get tricky are where you really > *want* to use global state, such as for an in-memory cache. Usually the > language provides some primitives to ensure that only one thread at a time > is updating the cache. It appears that python gives you thread-safety for a > lot of cases: > > > > http://effbot.org/zone/thread-synchronization.htm > > > > On Jun 29, 2011, at 1:20 AM, Greg wrote: > > > > > > > > > > > > > > > > > Hi - > > > > > Could anyone familiar with threads explain the basic principals of > > > python thread-safety? > > > > > Cheers! > > > Greg. > > > > > -- > > > 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 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: What's the difference between static and cached requests in the dashboard?
Request handlers will be cached if you use the Cache-Control header. I would suggest the line refers to those requests + static requests. On Jun 30, 12:35 am, Waleed Abdulla wrote: > I noticed a big increase in requests today, and it looks like it's due to a > sharp increase in "cached requests" (see image). I know that dynamic > requests refer to those that reach a request handler, and static are those > that are delivered through the CDN. Does anyone know what "cached requests" > are? I couldn't find any documentation about it. Are they simply static > requests that return 304 (not modified)? > > Screen shot 2011-06-29 at 2.16.37 PM.png > 52KViewDownload -- 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] Attempt to delete entities in HR Datastore Admin is stuck
In the application kbdlessons2.appspot.com an attempt was made to delete all entities in a number of models at once. The process seems to be stuck with 24 activities completed but 15 still active for the last 20 hours and the Datastore Admin panel shows no change in the number of entities from before the deletes were started. Could someone from Google please terminate these activities so I can try again. -- 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] What's the difference between static and cached requests in the dashboard?
I noticed a big increase in requests today, and it looks like it's due to a sharp increase in "cached requests" (see image). I know that dynamic requests refer to those that reach a request handler, and static are those that are delivered through the CDN. Does anyone know what "cached requests" are? I couldn't find any documentation about it. Are they simply static requests that return 304 (not modified)? -- 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: Creating a login url without requiring email permissions
Actually, seems like emails are needed when logging in using a Google apps account. ie not a gmail address account. Not sure, its hard to debug here, I don't have access here to a lot of different account types to try. On Jun 28, 3:45 pm, jay wrote: > Nar, still using Google Accounts API. Federated logins are still > marked experimental and I don't like how we can't provide a user with > a log out link. > > The standard accounts started asking for email permissions a few > months ago. Probably more like 6 months ago, not sure when. > > On Jun 28, 2:37 pm, "Nick Johnson (Google)" > wrote: > > > > > > > > > Hi Jay, > > > No, there's currently no way to do this. I presume you're using OpenID > > logins, since Google logins don't explicitly prompt for this? If that's the > > case, you could choose to use a third-party OpenID library instead of the > > built-in support. > > > -Nick Johnson > > > On Tue, Jun 28, 2011 at 2:22 PM, jay wrote: > > > Hello all, > > > > I use standard Google authentication to manage my users. I don't > > > actually need my users email address, is it possible to have somebody > > > login with out sharing their email with me. > > > > In other words, the users would not need to give my site permission to > > > see their email. (An extra step in the log in process) > > > > At the moment if a user doesn't want to share their real email with me > > > the login simply fails and they have to create a fake Google account > > > to log into my service. > > > > Jay. > > > > -- > > > 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. > > > -- > > Nick Johnson, Developer Programs Engineer, App Engine -- 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: Thread-safe Python Tips
We are not going to have to go into that much detail for our apps thought are we. Will we be able to take advantage of the multi-threading by simply creating multiple request handlers. I imagined I would be changing a few lines of code in my main function an that's about it. On Jun 29, 9:43 pm, Joshua Smith wrote: > I would assume they are the same as the basic principles of thread safety in > any language: > > - Don't rely on global state, because multiple of your functions might be > running simultaneously > > This usually isn't very hard to achieve - just pass parameters instead of > modifying globals. The places where it can get tricky are where you really > *want* to use global state, such as for an in-memory cache. Usually the > language provides some primitives to ensure that only one thread at a time is > updating the cache. It appears that python gives you thread-safety for a lot > of cases: > > http://effbot.org/zone/thread-synchronization.htm > > On Jun 29, 2011, at 1:20 AM, Greg wrote: > > > > > > > > > Hi - > > > Could anyone familiar with threads explain the basic principals of > > python thread-safety? > > > Cheers! > > Greg. > > > -- > > 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 at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Re: Porting from Django 0.96 to 1.2
Thanks Joshua,
I have collected some more tips from my own experience here:
http://www.gae123.com/articles/dpwf/apa.html
http://www.gae123.com/articles/dpwf/djgae1x.html
In particular, for the use_library('django', '1.2'), the second
article might present a more productive (you only need to modify only
one file) and robust way.
PK
--
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: Updated App Engine Pricing FAQ!
On Wed, Jun 29, 2011 at 8:29 PM, Jeff Schnitzer wrote: > On Wed, Jun 29, 2011 at 11:14 AM, vivpuri wrote: >> @Jeff i dont you have the development experience on AppEngine to even >> take part on this discussion. Before suggesting, first go an check >> what Quercus does and can enable you to do on AppEngine. > > This is the stupidest thing anyone has said to me in years. And more to come if you keep replying to him. :) -- Branko Vukelić bra...@herdhound.com Lead Developer Herd Hound (tm) - Travel that doesn't bite www.herdhound.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.
[google-appengine] Exception to use of Key class by JDO (Can't Find Source)
The app engine manual extensively discusses the use of the Key class (import javax.jdo.annotations.Key) for datastore operations, and yet when I try to persistent data using Key, app engine throws the exception: Caused by: javax.jdo.JDOUserException: Field "com.sis.app.server.DataModelMember.key" is declared as a reference type (interface/Object) but no implementation classes of "javax.jdo.annotations.Key" have been found. Any idea what is happening here with this "no source code" exception; otherwise, I have to create and manage my own keys which is a lot more coding during queries and updates. Thx! -- 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: Updated App Engine Pricing FAQ!
Hi Jeff, please, don't feed the troll. Vanni -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/KXLVDdGZX0IJ. 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: DKIM support and gmail -- now it's urgent!
+1 on the Amazon SES suggestion. I would rather the App Engine team focus on other priorities than mail, imho. Just DKIM is only part of the solution needed for getting mail deliverability humming... Then Sendgrid, Mailgun or something when you have a bit more volume or want more stats etc. -- Adrian Scott, Ph.D. CEO, Founder CoderBuddy http://www.coderbuddy.com/ On Wed, Jun 29, 2011 at 9:55 AM, JH wrote: > I'll agree that sometimes it's hard to understand priorities, say for > instance XMPP in general, or yes, prospective search. > All that aside, I'd encourage everyone to check out using Amazon's SES > service to send email via GAE. Their REST api works well and I > actually get fewer urlfetch timeouts using it than I got mail.send > timeouts sending with GAE. Also, their deliver ability is great! I > began using it when many GAE emails were flagged as spam via Yahoo. > Since then I have had just about 100% of my mail make it to inboxes. > Also, many threads on this list seem to indicate that GAE is not > planning on fixing their mail issues, and actually encourage users to > use a 3rd party for mail. > > > On Jun 29, 11:26 am, Adam Sah wrote: > > folks-- gmail is now flagging all non-DKIM-signed email as possible > > phishing, which is destroying the value of the App Engine Email API. > > > > what's the ETA to add DKIM support? (and why is this lower priority > than, > > say, Prospective Search?) > > > > http://code.google.com/p/googleappengine/issues/detail?id=3161 > > > > adam > > -- > 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: Updated App Engine Pricing FAQ!
On Wed, Jun 29, 2011 at 11:14 AM, vivpuri wrote: > @Jeff i dont you have the development experience on AppEngine to even > take part on this discussion. Before suggesting, first go an check > what Quercus does and can enable you to do on AppEngine. This is the stupidest thing anyone has said to me in years. 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.
[google-appengine] Re: Updated App Engine Pricing FAQ!
@Jeff i dont you have the development experience on AppEngine to even take part on this discussion. Before suggesting, first go an check what Quercus does and can enable you to do on AppEngine. On Jun 29, 2:04 pm, Jeff Schnitzer wrote: > On Wed, Jun 29, 2011 at 5:50 AM, vivpuri wrote: > >> I understand that you are upset that your appengine bill might go up > >> 4X, but how do you jump from this to the conclusion that "Google > >> should support PHP"?? > > > Every application development platform needs developers. iOS, AWS, > > [...] > > Nothing in that rant had anything to do with billing. If you want to > start a separate thread for "want php" go ahead, or better yet star > the issue. Or even better yet just use Quercus. > > The obvious conclusion from these billing changes is not that GAE > needs developers, it's that GAE needs revenue. > > >> I think you assume too much. I interpret this as a temporary salve to > >> keep Python developers from feeling like second-class citizens until > >> multithreaded Python is available. > > > I am not assuming too much. It's simple math. Besides that, i have > > never seen a hosting company tell me that since PHP version x now has > > support for this new feature. If you implement it, its good, else we > > are going to change 4X for the server. > > You assume that because Python instances are now priced 1/2 Java > instances, that this is a) permanent and b) reflective of the cost of > a Python instance. It may just be a temporary salve to placate Python > developers until multithreading is available. > > I've been fairly critical of the billing changes on this list, but you > come across as a total wingnut. We have all (apparently) been living > on the largess of Google - which is nice of them, except they didn't > tell us about it. And the price signaling they were giving us was all > wrong. There's a fair bit of reason to be upset about the changes > (especially if you now need to redesign parts of your app), but you > can't argue that these changes aren't rational. What isn't rational > is how you are somehow trying to use this issue as a springboard for > PHP advocacy. > > 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.
[google-appengine] Question on searching Expando models
Hello All, I'm trying to figure out a clean way to make my Expando model's searchable. I will have many user-defined fields that will need to be more or less searchable. This means that I would have to "normalize" my data (such as lower case all fields) so that the search is case insensitive. My idea is to create a ComputedProperty: @db.ComputedProperty def quick_search(self): return [ "%s:%s" % (k,str(self.__getattr__(k)).lower()) for k in self.dynamic_properties()] if self.dynamic_properties() else None I will update that to better handle list types and such, but it gets the idea across. This way, I can just query that single property to search my models. I can do multiple inequality filters on more than one property this way too! I feel like this would be a great way to accomplish what I want, versus creating a "shadow" custom field for every user-defined field with the data normalized. With a setup like this, I wouldn't need all my dynamic properties to be indexed. Is there a way I can disable auto-indexing the dynamic properties? I don't need to sort by any field, just search. Is there a better approach to my problem? I don't know how well this would "scale" up with 1000 or more dynamic properties. Running a few test on app engine led me to some memory issues when displaying more than 100 entries with 1000 dynamic entries (near 300MB!). Also, with 1000 dynamic properties, 77 entries took 2610342cpu_ms 2570465api_cpu_ms, which is a LOT. I also had a question on how the indexes would work across namespaces. Say I have 100 users using my app, each user creates 50 unique dynamic properties in their respective namespace for this model. Does that mean when writing the model, it's considered to have 5000 indexes (one for each unique dynamic property)? Or will each namespace be treated differently? Disabling indexes on dynamic properties would definitely help me on this front. Thanks in advanced! -- 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: Updated App Engine Pricing FAQ!
On Wed, Jun 29, 2011 at 5:50 AM, vivpuri wrote: >> I understand that you are upset that your appengine bill might go up >> 4X, but how do you jump from this to the conclusion that "Google >> should support PHP"?? > > Every application development platform needs developers. iOS, AWS, > [...] Nothing in that rant had anything to do with billing. If you want to start a separate thread for "want php" go ahead, or better yet star the issue. Or even better yet just use Quercus. The obvious conclusion from these billing changes is not that GAE needs developers, it's that GAE needs revenue. >> I think you assume too much. I interpret this as a temporary salve to >> keep Python developers from feeling like second-class citizens until >> multithreaded Python is available. > > I am not assuming too much. It's simple math. Besides that, i have > never seen a hosting company tell me that since PHP version x now has > support for this new feature. If you implement it, its good, else we > are going to change 4X for the server. You assume that because Python instances are now priced 1/2 Java instances, that this is a) permanent and b) reflective of the cost of a Python instance. It may just be a temporary salve to placate Python developers until multithreading is available. I've been fairly critical of the billing changes on this list, but you come across as a total wingnut. We have all (apparently) been living on the largess of Google - which is nice of them, except they didn't tell us about it. And the price signaling they were giving us was all wrong. There's a fair bit of reason to be upset about the changes (especially if you now need to redesign parts of your app), but you can't argue that these changes aren't rational. What isn't rational is how you are somehow trying to use this issue as a springboard for PHP advocacy. 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.
[google-appengine] Re: BadRequestError: query not found (occurring in the middle of a for loop)
I'm having the same issue. Where are the google employees on this? -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/Wiagd-wSj9sJ. 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: DKIM support and gmail -- now it's urgent!
I'll agree that sometimes it's hard to understand priorities, say for instance XMPP in general, or yes, prospective search. All that aside, I'd encourage everyone to check out using Amazon's SES service to send email via GAE. Their REST api works well and I actually get fewer urlfetch timeouts using it than I got mail.send timeouts sending with GAE. Also, their deliver ability is great! I began using it when many GAE emails were flagged as spam via Yahoo. Since then I have had just about 100% of my mail make it to inboxes. Also, many threads on this list seem to indicate that GAE is not planning on fixing their mail issues, and actually encourage users to use a 3rd party for mail. On Jun 29, 11:26 am, Adam Sah wrote: > folks-- gmail is now flagging all non-DKIM-signed email as possible > phishing, which is destroying the value of the App Engine Email API. > > what's the ETA to add DKIM support? (and why is this lower priority than, > say, Prospective Search?) > > http://code.google.com/p/googleappengine/issues/detail?id=3161 > > adam -- 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
Hi I have a question about migration of existing apps into the new pricing structure... We have numerous (50+) apps running across 3 different apps for domains (appspot.com + 2 of our own). Although we have our own apps for domains, all apps have an *.appspot.com url. This came about as we started off using our own personal accounts to create apps, later we created apps from our company domain, and later still we got another domain under the trusted partner scheme (perennial problem of early adopters). My simple plan is to invite a user from our domain onto all apps and then take over billing under the current payment scheme. When the new payment scheme launches, and we convert our domain to the new professional tier pricing, will all these apps be elligible to switch over to the new pricing under our domain? Hope that was coherent... Thanks Grant -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/reatL1XPE9AJ. 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] DKIM support and gmail -- now it's urgent!
folks-- gmail is now flagging all non-DKIM-signed email as possible phishing, which is destroying the value of the App Engine Email API. what's the ETA to add DKIM support? (and why is this lower priority than, say, Prospective Search?) http://code.google.com/p/googleappengine/issues/detail?id=3161 adam -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/YnHMC6r26VYJ. 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: Updated App Engine Pricing FAQ!
I was wondering, what about if I use db.create_rpc(deadline=1) Will I be charged if the deadline is reached, and I get nothing from db.get(), or db.put() ? Thanks On Wed, Jun 29, 2011 at 11:02 AM, mscwd01 wrote: > Ikai (or any other Googler), before the new pricing begins and we are > charged on a per Instance basis could you please take a look at this > bug and fix it. > > http://code.google.com/p/googleappengine/issues/detail?id=4834 > > Needless, to say it's SUPER important it's fixed. I've had to set > thread-safe to false to stop JDO getObjectByID() throwing an > UnsupportedOperationException. > > Thanks > > On Jun 29, 4:13 am, "Ikai Lan (Google)" wrote: > > Vivek, > > > > I think you are confused about the economics of competing with $5 > PHP/MySQL > > VPSs. > > > > 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 Tue, Jun 28, 2011 at 8:22 PM, vivpuri wrote: > > > @VInuth, if you have 5-10 requests per second and as many urls, it > > > might be easy to calculate cost. But large applications with 100s of > > > instances with as many requests per second and urls getting loaded, > > > its hard to say where you will end up. > > > > > I agree on latency part. For instance, the urlfetch latency is really > > > dependent on the url being called. Besides that, such calls dont > > > necessarily mean high memory usage or CPU usage. As Waleed said > > > earlier, instance should be optimized to process requests when > > > urlfetch is waiting for the response. Charging for such instances is > > > very much an Amazon way of thinking, which was the only reason we > > > picked AppEngine over AWS. > > > > > On the whole, AppEngine team is looking for their hockey stick growth > > > in revenues and pageviews. Not sure if their internal metric of growth > > > was met, but going by this huge change they are making, they might be > > > lagging. And to fix that, we have this drastic change to deal with. In > > > my opinion, simpler change would have been supporting PHP and get tons > > > and tons of new developers for free. For all the AppEngine team bias > > > for PHP, PHP has the ability and volume to make and break a product > > > like AppEngine. As for success of AWS, i think it might be more to do > > > with the fact that you can grab a server and put PHP on it and get > > > going, which besides Amazon, each and every hosting company has > > > realized over the years except for Google. > > > > > On Jun 28, 8:02 am, Vinuth Madinur wrote: > > > > I think it is fairly easy to calculate what your costs will be based > > > purely > > > > on the latency of your requests and the number of requests you are > > > getting. > > > > The new scheduler will anyway not affect this and based on scheduler > > > knobs + > > > > front end instance resources, you can somewhat predict the no.of > > > instances > > > > you might require. > > > > > > My gripe is, the new pricing brings latency into focus, while the > > > developers > > > > have nothing but their app code to optimize it. The responsibility > for > > > > latency is both on the application as well as underlying > infrastructure. > > > > > > On Tue, Jun 28, 2011 at 5:04 PM, Albert > wrote: > > > > > I'm holding 2 workshops for Google AppEngine next month. I used to > > > > > look forward to encourage developers to use GAE as a development > > > > > platform, but due to this new pricing changes, I'm not that excited > > > > > anymore. It's not because I don't like GAE anymore. I believe that > the > > > > > GAE infrastructure offers a lot of value as an infrastructure. > > > > > However, I really think that the pricing changes announcement was > > > > > announced to early. The early announcement has caused a lot of > > > > > confusion over a long period of time even until now. The most basic > > > > > question that needs to be answered is "How much will our apps cost > to > > > > > run now?" Maybe sample apps and their corresponding prices will > help > > > > > us visualize if we should really worry about the upcoming changes. > > > > > > > Something like... > > > > > > > -- > > > > > Sample App 1 (datastore intensive app) > > > > > > > Average Response Time: 200ms > > > > > > > Average # of users per day: 100K > > > > > > > Cost / day: ??? > > > > > > > -- > > > > > > > Sample App 2 (Compute intensive app) > > > > > > > Average Response Time: 800ms > > > > > > > Average # of users per day: 100K > > > > > > > Cost / day: ??? > > > > > > > -- > > > > > > > and so on... > > > > > > > -- > > > > > > > At least I can get a kind of "official" idea of the costs of > running > > > > > apps under the new pricing scheme. > > > > > > > Thanks and enjoy! > > > > > > > Albert > > > > > > > On Jun 28, 1:23 am, vivpuri wrote: > > > > > > There is one more option - Application just has to sh
[google-appengine] Re: Where is the extra latency coming from?
There isn't any pending_ms. On Jun 27, 2:04 pm, Waleed Abdulla wrote: > Check to see if there is a "pending_ms" value in the logs. If so, then that > indicates that your request was put in a queue to wait for it's turn to run. > I had a long thread about a similar question a week or so ago (just search > for pending_ms in the archives to find it). > > Waleed > > > > > > > > On Mon, Jun 27, 2011 at 7:20 AM, Spines wrote: > > I'm using GAE/Java. I record the time it takes for my code to execute > > inside the code and output it to the logs as a debug message. The time it > > takes for my code to execute is usually just a fraction of the time that is > > shown on the logs as the total time to respond to a request. > > > For example, in my code, my debug message will say that my code took 58ms > > to run. But the log message will show: / 421ms 130cpu_ms 20api_cpu_ms, > > indicating that it took 421ms to return a response. This is typical of > > every request, this is not due to loading requests. Also, I am the only > > person accessing my app right now, so it's not because it's waiting for > > another request to finish processing first. > > > What causes this extra latency? Is there any way I can fix it? > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google App Engine" group. > > To view this discussion on the web visit > >https://groups.google.com/d/msg/google-appengine/-/y4Lka5msRooJ. > > 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: Updated App Engine Pricing FAQ!
Ikai (or any other Googler), before the new pricing begins and we are charged on a per Instance basis could you please take a look at this bug and fix it. http://code.google.com/p/googleappengine/issues/detail?id=4834 Needless, to say it's SUPER important it's fixed. I've had to set thread-safe to false to stop JDO getObjectByID() throwing an UnsupportedOperationException. Thanks On Jun 29, 4:13 am, "Ikai Lan (Google)" wrote: > Vivek, > > I think you are confused about the economics of competing with $5 PHP/MySQL > VPSs. > > 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 Tue, Jun 28, 2011 at 8:22 PM, vivpuri wrote: > > @VInuth, if you have 5-10 requests per second and as many urls, it > > might be easy to calculate cost. But large applications with 100s of > > instances with as many requests per second and urls getting loaded, > > its hard to say where you will end up. > > > I agree on latency part. For instance, the urlfetch latency is really > > dependent on the url being called. Besides that, such calls dont > > necessarily mean high memory usage or CPU usage. As Waleed said > > earlier, instance should be optimized to process requests when > > urlfetch is waiting for the response. Charging for such instances is > > very much an Amazon way of thinking, which was the only reason we > > picked AppEngine over AWS. > > > On the whole, AppEngine team is looking for their hockey stick growth > > in revenues and pageviews. Not sure if their internal metric of growth > > was met, but going by this huge change they are making, they might be > > lagging. And to fix that, we have this drastic change to deal with. In > > my opinion, simpler change would have been supporting PHP and get tons > > and tons of new developers for free. For all the AppEngine team bias > > for PHP, PHP has the ability and volume to make and break a product > > like AppEngine. As for success of AWS, i think it might be more to do > > with the fact that you can grab a server and put PHP on it and get > > going, which besides Amazon, each and every hosting company has > > realized over the years except for Google. > > > On Jun 28, 8:02 am, Vinuth Madinur wrote: > > > I think it is fairly easy to calculate what your costs will be based > > purely > > > on the latency of your requests and the number of requests you are > > getting. > > > The new scheduler will anyway not affect this and based on scheduler > > knobs + > > > front end instance resources, you can somewhat predict the no.of > > instances > > > you might require. > > > > My gripe is, the new pricing brings latency into focus, while the > > developers > > > have nothing but their app code to optimize it. The responsibility for > > > latency is both on the application as well as underlying infrastructure. > > > > On Tue, Jun 28, 2011 at 5:04 PM, Albert wrote: > > > > I'm holding 2 workshops for Google AppEngine next month. I used to > > > > look forward to encourage developers to use GAE as a development > > > > platform, but due to this new pricing changes, I'm not that excited > > > > anymore. It's not because I don't like GAE anymore. I believe that the > > > > GAE infrastructure offers a lot of value as an infrastructure. > > > > However, I really think that the pricing changes announcement was > > > > announced to early. The early announcement has caused a lot of > > > > confusion over a long period of time even until now. The most basic > > > > question that needs to be answered is "How much will our apps cost to > > > > run now?" Maybe sample apps and their corresponding prices will help > > > > us visualize if we should really worry about the upcoming changes. > > > > > Something like... > > > > > -- > > > > Sample App 1 (datastore intensive app) > > > > > Average Response Time: 200ms > > > > > Average # of users per day: 100K > > > > > Cost / day: ??? > > > > > -- > > > > > Sample App 2 (Compute intensive app) > > > > > Average Response Time: 800ms > > > > > Average # of users per day: 100K > > > > > Cost / day: ??? > > > > > -- > > > > > and so on... > > > > > -- > > > > > At least I can get a kind of "official" idea of the costs of running > > > > apps under the new pricing scheme. > > > > > Thanks and enjoy! > > > > > Albert > > > > > On Jun 28, 1:23 am, vivpuri wrote: > > > > > There is one more option - Application just has to shutdown since > > > > > there is no money to pay. If a bill of $2k per month suddenly becomes > > > > > $10k per month, there are not many who can pay that. Just for > > > > > comparison sake, in the US mortgage crisis, at the end of 5ARM a > > > > > sudden increase in 1% of interest rate(effectively $200-$500 dollars/ > > > > > month, depending on total amount) lead home owners to default and > > file > > > > > bankruptcy. > > > > > > On Jun 27, 12:50 pm, Branko Vukel
[google-appengine] Re: Updated App Engine Pricing FAQ!
> I understand that you are upset that your appengine bill might go up > 4X, but how do you jump from this to the conclusion that "Google > should support PHP"?? Every application development platform needs developers. iOS, AWS, Facebook, Win32, MacOS, And each platform provider comes up with a a strategy to acquire developers. Apple did that via steller products backed with millions of dollars of ad budgets. AWS revolutionized regular hosting company operations by adding ability to bring servers up and down at an instants notice. This attracted corporate users who could put java, and startups that could PHP. Msft got developers by tight bundling of products, where one feeds the other. What was the plan for AppEngine? None in my opinion. AppEngine put Python out first, which was clearly not developers choice at that time. And second one to come in was Java, where google thought they will get the enterprise customers and resulting big money. However, as everyone has discovered, corporates are not yet prepared for paradigm shift in programming that AppEngine offers and would very much prefer a server based model that EC2 offers. And besides that, no support desk to call 24X7 pretty much kills any corporate interest. As a result corporate customers are really locked out for AppEngine. As for Python, there are not many startups looking to take this path 'cause lack of developers is going to cause long term hiring issues. Going by numbers, if we look at the Bug Tracker for AppEngine - http://code.google.com/p/googleappengine/issues/list , number 1 request is "PHP Support is a must" with 3143 votes(approx 50% more votes than feature #2). In my opinion, Google should have never ignored developer opinion. Instead, AppEngine team should have recognized the demand and delivered the feature. And now 3 years down the line, AppEngine has added support for GO instead, which has pretty much no developers. As compared to that, if they had added support for PHP, there would have been thousands of more developers on the platform, generating more revenues for AppEngine, and the team not getting forced to make such drastic pricing changes. Besides that, from what is seems to me, someone with mindset of Google Apps or even Search Product is making decisions for AppEngine, where each developer is treated like a user. As a result strategy/thinking is that features can be flipped right before our eyes without being asked for opinion or any consideration for our efforts. Personally i have been here since the days when AppEngine didnt throw the DeadlineExceededError and you were left wondering for days why that HTTP 500 is showing, and days when i was not able to delete data for 2 months since no process existed, and times when i had to pay $6k for deleting 3TB of data, and days where there are thousands of datastore timeouts resulting in user loss(without getting any refund). With all this, I would really hope AppEngine gives more consideration to existing developers. > I think you assume too much. I interpret this as a temporary salve to > keep Python developers from feeling like second-class citizens until > multithreaded Python is available. I am not assuming too much. It's simple math. Besides that, i have never seen a hosting company tell me that since PHP version x now has support for this new feature. If you implement it, its good, else we are going to change 4X for the server. Also, writing new code to support threading is okay, but modifying half million lines of production code to support threading is suicide. On Jun 29, 4:29 am, Jeff Schnitzer wrote: > On Tue, Jun 28, 2011 at 8:34 PM, vivpuri wrote: > > > Thank you for the response. I am not really confused about anything. > > Everyone has different set of experiences and resulting opinions. > > Facebook was built on PHP, and definitely started from $5 PHP/MySQL. > > I understand that you are upset that your appengine bill might go up > 4X, but how do you jump from this to the conclusion that "Google > should support PHP"?? > > > Also, i am not able to understand the logic behind charging half for > > python instances since AppEngine does not support threading as of now. > > I am a python threading noob, but going by the offer that AppEngine > > team has thrown out, it seems threading can increase performance at > > most by 2x, which is the only way you can justify 1/2 price. I find it > > hard to believe. > > I think you assume too much. I interpret this as a temporary salve to > keep Python developers from feeling like second-class citizens until > multithreaded Python is available. > > 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.
[google-appengine] Re: Updated App Engine Pricing FAQ!
Greg, thank you for your answers. It would be great if you could clarify a few more things. 1) How do you define "instance available to serve a request" in concurrent environment? I suppose this means an instance that is currently serving less than X requests. What is that X? Will it be just a fixed number? Maybe based on current CPU load, memory usage etc. Please give us some details on this. 2) The new pricing calls for some additional controls in request serving priority. Here's an example: I might want the user requests to have maximum latency of 50ms, but I don't mind task queue requests having latency up to 5000ms or even more. Moreover, if there are requests from users and from task queue competing for instances (even if just for a second), it should be possible to make the user requests go first. Anyway, I hope you see that this is something that only matters with the new pricing. Did GAE team put any thought towards this and how feasible do you think it would be for you to add such controls? This would help a lot. 3) I don't think documentation or SLA says anything about the way users's instances are packed into machines -- is it done in a way that the instances guaranteed their share of memory even when they don't use it? 4) How many instances are there per-core on a machine? If there are a lot, the latency for apps can increase just due to OS scheduler having to juggle all those instances, and through no fault of the application author. Thank you, Sergey -- http://self.maluke.com/ -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/yySRUxpQg4gJ. 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] Thread-safe Python Tips
I would assume they are the same as the basic principles of thread safety in any language: - Don't rely on global state, because multiple of your functions might be running simultaneously This usually isn't very hard to achieve - just pass parameters instead of modifying globals. The places where it can get tricky are where you really *want* to use global state, such as for an in-memory cache. Usually the language provides some primitives to ensure that only one thread at a time is updating the cache. It appears that python gives you thread-safety for a lot of cases: http://effbot.org/zone/thread-synchronization.htm On Jun 29, 2011, at 1:20 AM, Greg wrote: > Hi - > > Could anyone familiar with threads explain the basic principals of > python thread-safety? > > Cheers! > Greg. > > -- > 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] Request for clarification using GAE and XMPP
On Tue, Jun 28, 2011 at 11:22 PM, Nikolay Sohryakov wrote: > application which consists of two parts: a web application running on GAE > plaform and a desktop application running on user's computer and use XMPP as > a communication tool between this 2 applications? I believe they meant two GAE apps that communicate with each other specifically to reduce the load that would be otherwise handled by a single application. In case the other app is a non-GAE app, I think the clause doesn't apply. For example, many people use non-GAE proxy for payment processing, and they were not booted for breaking TOS. -- Branko Vukelić bra...@herdhound.com Lead Developer Herd Hound (tm) - Travel that doesn't bite www.herdhound.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] Re: Updated App Engine Pricing FAQ!
On Tue, Jun 28, 2011 at 8:34 PM, vivpuri wrote: > > Thank you for the response. I am not really confused about anything. > Everyone has different set of experiences and resulting opinions. > Facebook was built on PHP, and definitely started from $5 PHP/MySQL. I understand that you are upset that your appengine bill might go up 4X, but how do you jump from this to the conclusion that "Google should support PHP"?? > Also, i am not able to understand the logic behind charging half for > python instances since AppEngine does not support threading as of now. > I am a python threading noob, but going by the offer that AppEngine > team has thrown out, it seems threading can increase performance at > most by 2x, which is the only way you can justify 1/2 price. I find it > hard to believe. I think you assume too much. I interpret this as a temporary salve to keep Python developers from feeling like second-class citizens until multithreaded Python is available. 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] Thread-safe Python Tips
Thread safe, means that two thing can be done with out the order mattering, and without any dependency on the other thread. Example: Find the sum of a column 1-1000 Single Thread: 1+2+3+4+998+999+1000 4 Threads: A= 1+2+3+4...248+249+250 B = 251+252+253+254...498+499+500 C = 501+502+503+504...748+749+750 D = 751+752+753+754...998+999+1000 Return A+B+C+D Not Thread Safe: Replace all entities with Value -1 with 0 Sum column Not Thread Safe: New A = Old A + 3 New B = New A + Old B Can be multithreaded for part of the operation: Fetch 4 URLs, Store returned data, do formula, display result. You can multithread the Fetch, and the store, but the Do formula and display result has to happen after. -Original Message- From: google-appengine@googlegroups.com [mailto:google-appengine@googlegroups.com] On Behalf Of Greg Sent: Tuesday, June 28, 2011 10:20 PM To: Google App Engine Subject: [google-appengine] Thread-safe Python Tips Hi - Could anyone familiar with threads explain the basic principals of python thread-safety? Cheers! Greg. -- 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.
