Re: [google-appengine] Do F1 F2 F4 Google App Engine frontend instances really cost more
Thanks Barry. So I think you're saying that the instance hours are charged even when the CPU is not busy and F2 costs twice as much as F1 even when the server is idle between requests or when waiting for database, right? Strangely we are experimenting with switching between F1 / F2 / F4 and seeing *virtually no difference* in performance of a server benchmark (pure CPU - a big for loop). Could it be that the F1/F2/F4 switch does not take effect immediately? Or could it be that when the server is not loaded F1 will perform the same as F4? Thanks -- 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/-/JWWgK2CfWFkJ. 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: Startup time exceeded...on F4?!
Ok, but what of Jeff's suggestion would impact performance negatively at your scale? I assume the GAE team would ensure they don't harm your case while trying to improve the few-instances case. On Wednesday, July 18, 2012 6:55:36 AM UTC+2, Brandon Wirtz wrote: > > Jeff, > > Check the archive there are several check out lane analogies that I have > posted. > > I agree that the Queue is sub optimal, but it is more sub optimal the > smaller you are. When you get to 50 instances it is amazing how well the > load balancing works. On the climb up to peak new instances spin up on > requests rather than causing cascading failures or dramatic spin ups. And > on > the way down instances de-utilized and end of life gracefully. > > Using your grocery store analogy, imagine that you are optimizing for a > guarantee that you will be checked out with in 30 seconds of entering the > queue. The ideal scenario is that when you get to a spot where you know > you > are 15 seconds from being checked out, and it takes 15 seconds to "open a > new lane" you want to send users to go stand in line while the register > opens. > > Your goal is to never have to pay on that guarantee, not to serve the > highest percentage in the least time. When this is your ideal QoS the > current load balancing does really well. It does better if it has 10 > registers and can open 2 at a time, rather than when it has 1 register and > needs to decide if it is going to double capacity. > > -Brandon > > > -- 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/-/USujDDZsQ94J. 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: Startup time exceeded...on F4?!
I don't buy this. Even if the checkout queue is 15s deep and it takes 15s to bring a cashier online, there's still no value in sending Bob to wait by the register. For one thing, it doesn't actually reduce Bob's wait time by a material amount (he can move to the register in a few milliseconds). For another thing, we're only *speculating* that the register will be open in 15s - sometimes it's 30s or 45s because the cashier is hungover and keeps dropping the keys. Sure, it's a lot easier to balance a 50-instance problem because a load that size will have a lot more inertia and be less spiky. But I still want to know how what percentage of your user-facing requests are hitting cold starts, and how many idle instances you need to keep it from happening. I have an e-commerce site. It doesn't get a lot of traffic but each request is very important - people are digging out their credit cards and buying things. It's *never* ok for a 20s pause to interrupt this process; people don't like giving money to sites that seem broken. Jeff On Tue, Jul 17, 2012 at 9:55 PM, Drake wrote: > Jeff, > > Check the archive there are several check out lane analogies that I have > posted. > > I agree that the Queue is sub optimal, but it is more sub optimal the > smaller you are. When you get to 50 instances it is amazing how well the > load balancing works. On the climb up to peak new instances spin up on > requests rather than causing cascading failures or dramatic spin ups. And on > the way down instances de-utilized and end of life gracefully. > > Using your grocery store analogy, imagine that you are optimizing for a > guarantee that you will be checked out with in 30 seconds of entering the > queue. The ideal scenario is that when you get to a spot where you know you > are 15 seconds from being checked out, and it takes 15 seconds to "open a > new lane" you want to send users to go stand in line while the register > opens. > > Your goal is to never have to pay on that guarantee, not to serve the > highest percentage in the least time. When this is your ideal QoS the > current load balancing does really well. It does better if it has 10 > registers and can open 2 at a time, rather than when it has 1 register and > needs to decide if it is going to double capacity. > > -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. > -- 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] Callbacks don't work with version 1.7/Java
I just updated from 1.6.4 to 1.7 AppEngine/Java. Callbacks like @PrePut don't work anymore. Tested on local dev-server and on app-engine. Going back to 1.6.4 it works fine again. Does anybody else experienced this? Did something change in 1.7? Cheers Mos -- 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] https://appengine.google.com/ --> Getting "An unexpected failure has occurred" + cannot deploy new version of app
Hi, Am I the only one impacted ? While accessing https://appengine.google.com/, I am getting "An unexpected failure has occurred". Also, I cannot deploy a new version of my app, getting the message : "503 Service Unavailable Try Again (503) An unexpected failure has occurred. Please try again." -- 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/-/XRQevIUDx3sJ. 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: Startup time exceeded...on F4?!
Use warm up requests. Also optimize your code to load faster. I have an app that is HUGE it loads in about 8s. On an F4. It doesn't fit in an F2. Check that you really need all your libraries. Check that any of the large blocks of data you have in code files are in database/memcache. If you need use a Cron to put them back in memcache every 10 minutes. If you have multiple people using the same code base, make your app multi-tenant so that you have fewer spin ups and more instances to serve requests. If you are storing init variables in datastore make sure you put them in mem cache so you can get them faster. Marshal or Pickle init variables. Use inline imports for functions that are rarely called. Strip unused class/functions from Libraries and frameworks. -- 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] Declare model's properties from a list of strings.
Greetings, class SocialNodeSubscription(model.Model): starting_date=model.DateProperty(auto_now=True) user = model.KeyProperty() def __init__(self, *args, **kwargs): permissions=["post","read","reply","admin"] for i in permissions: exec "can_%s=model.BooleanProperty(default=True)" % i super(SocialNodeSubscription, self).__init__(*args, **kwargs) this is my model. What i'm trying to do is to define a list of properties for my permissions called "can_post", "can_read" and so on. My problem is that it simply does nothing. When i try to put a new instance in the datastore, it gives no problem but it simply ignores those fields. Here is another version that behaves the same def __init__(self, *args, **kwargs): permissions=["post","read","reply","admin"] for i in permissions: self_properties['can_'+i]=model.BooleanProperty(default=True) super(SocialNodeSubscription, self).__init__(*args, **kwargs) How can i fix this so that the system can use those properties? -- 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/-/c9EdV1yU1fMJ. 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: Do F1 F2 F4 Google App Engine frontend instances really cost more
I've also been trying to do some benchmark tests on F1/F2/F4 instance class, and i am seeing very little performance difference. the server tasks take the same time ... also sometimes F1 outperforms F4, i wonder why is that?! i was wondering what exactly is the relationship between the instance class and the number of instances, how do i control the settings that guarante the highest performance and the lowest? any ideas? On Tuesday, July 17, 2012 5:05:18 PM UTC+3, Marc Hacker wrote: > > If F2 costs double as much as F1 per CPU hour but takes half the time to > complete tasks shouldn't the total cost be about the same? > > Thanks > -- 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/-/nJ0cU9rGIoEJ. 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] https://appengine.google.com/ --> Getting "An unexpected failure has occurred" + cannot deploy new version of app
Hi, I have 4 applications online, all good. I have just made a deploy right now, no errors. cheers. On Wed, Jul 18, 2012 at 2:57 PM, hugues2 wrote: > Hi, > > Am I the only one impacted ? While accessing https://appengine.google.com/, > I am getting "An unexpected failure has occurred". > > Also, I cannot deploy a new version of my app, getting the message : > > "503 Service Unavailable > > > Try Again (503) > > An unexpected failure has occurred. Please try again." > > -- > 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/-/XRQevIUDx3sJ. > 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] SSL support
So happy to see SSL support finally here, but a bit disappointed. VIP seems the way to go, but at $99 per month, it is cost prohibitive for some of our apps. So, I am asking for feedback from others who have implemented SNI. From my understanding, there are still many visitors with older browsers who will not be able to use it. Is that correct? Looking at recent stats, we have 16% of our visitors with IE 6 or 7. And an astounding 43% with XP or previous versions of Windows. Not to mention those with Safari/Win, or older Android OS. What will these visitors see when they try to access an SNI-SSL page? Any problems/issues encountered with SNI implementations? Older browsers? International visitors? Frankly, at $108/year PLUS the certificate, even SNI-SSL is expensive. But $1200/year, plus cert, for VIP is not feasible for smaller apps. (IMO, $108/year should cover virtual IP). Sticking with our appspot URLs for SSL until this is ready for prime time. We are not willing to abandon even a small single-digit percentage of our users. Also, I recently was told that some search engines use the IP address in page ranking. Shared IPs are penalized. Had not heard that before, and not sure that is accurate, as a majority of sites are on shared-IPs. Your feedback greatly appreciated. -- 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/-/jhmjuPp_Z8gJ. 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] SSL support
Ssl cost ten times the monthly minimum for hosting. There is no reason, apart from greed, it has to be so expensive. If there is, please enlighten me. -- 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/-/9hxZMeLv4FYJ. 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] SSL for custom domain app engine performance issues
Hi, *Domain Name*: www.phaseindustries.com CNAME to ghs.googlehosted.com. *Users Affected*: all visiting the SNI endpoint *Problem Description*: I am using SSL certificate on SNI - so my domain is being served from ::79 (.121) IP and not ::8d (.141) which I get when using my corresponding *.appspot.com domain - and I am getting a 300-400ms performance hit through this. Since I am paying for the SSL endpoint, I wondered if this delay was expected? *Steps to Reproduce*: Using Chrome, visit the site over the SNI address (.121) and use the network developer tool to measure latency from request to response. Then visit on the *.appspot.com (.141) endpoint and notice that there is virtually no latency. Any chance of getting an answer if this is a known issue, potentially something to do with the SSL cert lookup when accessing an apps domain through the ::79 (.121)? Does not make any difference whether accessing over IPv6 or IPv4 but providing v6 since that's my primary access point. Cheers Will -- 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/-/iPuqYb9HPj4J. 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] mapping Google Apps to Appengine error 1000
If I want to add mapping to Google Apps I get this error: We are unable to process your request at this time. Please try again later. (Error #1000) -- 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/-/azMrg0f_BO8J. 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: Startup time exceeded...on F4?!
We ARE using warmup requests, that's is the while point of this thread. I dont believe that you (or anyone) has sufficiently explained how sending user requests to cold instances is ever better than warming it up first.. Said request can ALWAYS be pulled right off the pending queue and sent to the instance as soon as it is ready. On Wednesday, July 18, 2012 2:27:45 PM UTC-4, Brandon Wirtz wrote: > Use warm up requests. > > Also optimize your code to load faster. I have an app that is HUGE it > loads in about 8s. On an F4. It doesn't fit in an F2. Check that you > really > need all your libraries. Check that any of the large blocks of data you have > in code files are in database/memcache. If you need use a Cron to put them > back in memcache every 10 minutes. > > If you have multiple people using the same code base, make your app > multi-tenant so that you have fewer spin ups and more instances to serve > requests. > > If you are storing init variables in datastore make sure you put them in mem > cache so you can get them faster. Marshal or Pickle init variables. > > Use inline imports for functions that are rarely called. > > Strip unused class/functions from Libraries and frameworks. -- 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/-/-AzInxgwLCAJ. 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: Startup time exceeded...on F4?!
On Wed, Jul 18, 2012 at 11:27 AM, Drake wrote:
> Use warm up requests.
...except that thanks to a recent change, warmup requests don't
prevent users from seeing cold starts anymore. In a burst of traffic,
GAE will happily route requests to cold instances even if an active
instance would have become available 1s later.
> Also optimize your code to load faster. I have an app that is HUGE it
> loads in about 8s. On an F4. It doesn't fit in an F2. Check that you really
> need all your libraries. Check that any of the large blocks of data you have
> in code files are in database/memcache. If you need use a Cron to put them
> back in memcache every 10 minutes.
Believe me, I've gone down this route.
8s is still unacceptable. That's well beyond "user clicks reload
because they think site is broken". And you aren't accounting for
sick periods when latency goes 2-3X that; how do your users feel about
a 24s wait?
I have optimized my codebase about as much as I consider reasonable.
I don't eager load data, I've turned off any kind of classpath
scanning. I've deliberately used GAE-friendly libraries. Hell, I
even wrote one myself. When GAE is behaving, my startup time is
20-30s, and could go down to 10-15s if I wanted to quadruple my bill
with F4s (I don't). The next step is more or less tantamount to
"give up on Java", or at least programming in something that looks
like modern Java:
* In order to persist POJOs, the classes must be introspected at
startup. The alternative is to use only the low-level api; that does
not scale to a complicated project.
* Nearly every modern Java webapp framework uses annotations to
define a sitemap. That means loading and introspecting all those
annotated classes before serving the first request. The alternative
is to find some early-2000s-era relic based on XML files like Struts1
or WebWork (or this blast from the past: http://mav.sf.net). I'm not
even sure it would help; the first thing most of these do is read the
XML and load the related classes.
* I could probably squeeze a few more seconds out of startup if I
dropped Guice and AOP. This would involve rewriting my app more or
less from scratch. Aside from my fixed investment, I refuse to go
back to programming without tools like these. It's the difference
between:
@Transact(TxnType.REQUIRED)
void doSomeWork() {
...do work
}
and littering my code with crap like this:
Transaction txn = datastore.beginTransaction();
try {
...do work
txn.commit();
} finally {
if (txn.isActive()) {
txn.rollback();
}
}
Actually, these are not comparable, because the AOP-based example is
smart about inheriting a pre-existing transaction context, or starting
one if necessary. A truly equivalent second example would include a
ton more boilerplate.
Without techniques like AOP and DI, Java programming becomes miserable
busywork. We picked GAE as a platform because without having to do
the work of an ops staff, we can write code and develop features much
faster. If I am stuck working at half-speed with crappy tools, then
GAE has a negative value proposition - we'd be faster even with the
ops load, and paying a fraction of GAE's price to boot.
So yeah, I don't expect to see my startup times get much better than
what they are today... and if I double my codebase next year, it could
get worse.
Realistically, I do not expect Google will ever be able to squeeze
Java application starts into reasonable timeframes (ie,
http://www.useit.com/alertbox/response-times.html). It's just not
realistic given the nature of classloading and the security
precautions that must be built around it. That kind of JVM
engineering is rocket science, and in the last three years it hasn't
materialized (although, to Google's credit, incremental progress has
been made).
This is why I'm thinking about lateral solutions. Honestly I don't
really care how long it takes my app to start as long as 1) users
never see cold starts and 2) I can expand capacity to meet increased
load. From the outside, it really feels like all the pieces have been
implemented, they just are misconfigured right now.
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: Startup time exceeded...on F4?!
On Jul 18, 2:38 pm, Michael Hermus wrote: > I dont believe that you (or anyone) has sufficiently explained how sending > user requests to cold instances is ever better than warming it up first.. > Said request can ALWAYS be pulled right off the pending queue and sent to the > instance as soon as it is ready. Let me take a shot at this. Brandon Wirtz touched on it before, when he said "I agree that the Queue is sub optimal, but it is more sub optimal the smaller you are. When you get to 50 instances it is amazing how well the load balancing works. " Suppose you have a massive store (we'll call it MegaWalmart). MegaWalmart has 100 staffed checkout lanes. Suppose all of these lanes have a single queue of people lined up, and a supervisor which sends customers to open checkout lanes (roughly analogous to your preferred way of handling GAE request queuing). That one line would be huge, would block traffic around the store, etc. It's far better, from MegaWalmart's POV, to have multiple check out lines, one line per each lane. Now suppose you have another checkout lane open up. (remember, now we have one line per lane) That's an additional 1% capacity. Now if the checkout clerk is drunk/hungover/whatever, that additional lane will take extra time to open, annoying the customers lined up in that lane. >From MegaWalmart's POV, who cares? Less than 1% of your customers were inconveniced. 99% of people still had a decent time checking out. Let's apply this to the scheduler. Suppose there was one single queue of requests. At Google-scale, that queue of requests could easily exceed millions of entries, possibly billions. And God help you if the machine hosting the queue gets a hiccup, or an outright failure. Don't you agree that, at least at Google-scale, requests should immediately be shunted to instance-level queues? Even if a single instance takes forever, or fails, we don't have to care: such a failure would only affect 0.01% of users. This leads me to my final point: My understanding, from reading the documentation and blog/news posts about GAE, is that the the core of GAE is ripped pretty much directly from production Google services. The problem with this is, the scheduler is intended to work at very high scale, not at low scale. And frankly, this makes sense when you consider a lot of the finer points of the GAE ecosystem. So, to fix this: GAE needs to have a good relook at scheduler code, and rewrite it so that it has two different rules for apps at less than 50 instances, and more than 50 instances. Additionally, perhaps the GAE should look at making the scheduler smarter; perhaps it could measure the startup time of instances, and in the future, not send requests to cold instances until that startup time has elapsed. Personal thoughts: I have admined a corporate GAE app that has exceeded 100 instances, and I use GAE for personal apps that use, at max, 3-4 instances. When you use GAE at these two extremes, you really get an understanding of how GAE scales. For instance, a personal anecdote: for my low end apps, I occasionally notice that GAE starts up a new idle instance. I'm not charged for it, it doesn't do any work, but it is counted in the "current instances" counter. My guess is that, during non-peak times, the GAE scheduler will load into memory additional instances of low end apps, to try and be ready for quick scaling. So I believe the GAE team tries to handle low-end instances, but it does need more work. TLDR: the scheduler needs more work, and MegaWalmart is the same thing as Google's scheduler. -- 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: SSL support
I share your sentiment about the SSL support 100%... it's great to finally
have it but the reality is the ecosystem just isn't ready for SNI yet.
There are still too many browsers that don't support SNI including the
Kindle Fire and every other pre-Ice Cream Sandwich Android device (of which
there are many). To be honest I expect Google to be a better steward of
the Internet. Proper SSL support should be encouraged and offered as an
inherent part any professional web development platform. SSL should NOT be
treated as a major feature upgrade where cost becomes a deciding factor for
adoption. By favoring SNI Google is compromising the integrity of the
browser experience anytime the overwhelming majority of Android users
browse to a secure App Engine site.
The non-SNI supporting browsers I've tested generate big ol' certificate
warnings and strongly encourage users NOT to continue browsing to the site.
Users generally have a choice to continue or not but the warnings sound
quite ominous and make it seem like your illegitimate site is pretending to
be someone else's legitimate site ("the certificate this site is using was
issued for another web address"). Unfortunately, adopting SNI right now
just pollutes the browsing experience and makes your site seem shady.
With Internet Explorer if the user clicks through the certificate warning
and continues to you site, the URL input bar stays highlighted with a red
background and an intimidating "certificate error" message is displayed to
the right of the URL.
I'm all for Google profiting from App Engine but it seems like there are
enough other opportunities for that since they monitor and charge for just
about everything else. I'm still hoping there's enough "don't be evil"
within Google that they decide to favor a seamless browsing experience over
a pay-for-proper-security profit grab. Perhaps in another 3-5 years the
ecosystem will be more accommodating of SNI but unfortunately that day
isn't here yet.
On Wednesday, July 18, 2012 3:02:20 PM UTC-4, GAEfan wrote:
>
> So happy to see SSL support finally here, but a bit disappointed. VIP
> seems the way to go, but at $99 per month, it is cost prohibitive for some
> of our apps. So, I am asking for feedback from others who have implemented
> SNI. From my understanding, there are still many visitors with older
> browsers who will not be able to use it. Is that correct?
>
> Looking at recent stats, we have 16% of our visitors with IE 6 or 7. And
> an astounding 43% with XP or previous versions of Windows. Not to mention
> those with Safari/Win, or older Android OS. What will these visitors see
> when they try to access an SNI-SSL page?
>
> Any problems/issues encountered with SNI implementations? Older browsers?
> International visitors? Frankly, at $108/year PLUS the certificate, even
> SNI-SSL is expensive. But $1200/year, plus cert, for VIP is not feasible
> for smaller apps. (IMO, $108/year should cover virtual IP). Sticking with
> our appspot URLs for SSL until this is ready for prime time. We are not
> willing to abandon even a small single-digit percentage of our users.
>
> Also, I recently was told that some search engines use the IP address in
> page ranking. Shared IPs are penalized. Had not heard that before, and
> not sure that is accurate, as a majority of sites are on shared-IPs.
>
> Your feedback greatly appreciated.
>
>
>
--
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/-/HUXzIEE43doJ.
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: Startup time exceeded...on F4?!
I certainly appreciate the attempted explanation. Correct me if I am wrong, but what you said amounts to this: Google has to route requests to cold start instances because otherwise, for > large scale apps, the pending queue might get way too big, not to mention > it could blow up sometime. > If that is true, I suppose I would be quite surprised, for the following reasons: a) Google's entire infrastructure is designed for EVERYTHING to scale massively and still work well. b) By waiting for instances to warm up first, I don't think you would really increase the maximum depth of the pending queue by a whole lot. In fact, the larger your app (i.e. the more instances you have active), the less impact it would have relative to the alternative. c) I don't think the pending queue is 'hosted' on a single machine; I am pretty sure it relies on a resilient queue infrastructure designed to tolerate failures and scale well. On Wednesday, July 18, 2012 5:07:04 PM UTC-4, hyperflame wrote: > > On Jul 18, 2:38 pm, Michael Hermus wrote: > > I dont believe that you (or anyone) has sufficiently explained how > sending user requests to cold instances is ever better than warming it up > first.. Said request can ALWAYS be pulled right off the pending queue and > sent to the instance as soon as it is ready. > > Let me take a shot at this. Brandon Wirtz touched on it before, when > he said "I agree that the Queue is sub optimal, but it is more sub > optimal the smaller you are. When you get to 50 instances it is > amazing how well the load balancing works. " > > Suppose you have a massive store (we'll call it MegaWalmart). > MegaWalmart has 100 staffed checkout lanes. Suppose all of these lanes > have a single queue of people lined up, and a supervisor which sends > customers to open checkout lanes (roughly analogous to your preferred > way of handling GAE request queuing). That one line would be huge, > would block traffic around the store, etc. It's far better, from > MegaWalmart's POV, to have multiple check out lines, one line per each > lane. > > Now suppose you have another checkout lane open up. (remember, now we > have one line per lane) That's an additional 1% capacity. Now if the > checkout clerk is drunk/hungover/whatever, that additional lane will > take extra time to open, annoying the customers lined up in that lane. > From MegaWalmart's POV, who cares? Less than 1% of your customers were > inconveniced. 99% of people still had a decent time checking out. > > Let's apply this to the scheduler. Suppose there was one single queue > of requests. At Google-scale, that queue of requests could easily > exceed millions of entries, possibly billions. And God help you if the > machine hosting the queue gets a hiccup, or an outright failure. Don't > you agree that, at least at Google-scale, requests should immediately > be shunted to instance-level queues? Even if a single instance takes > forever, or fails, we don't have to care: such a failure would only > affect 0.01% of users. > > This leads me to my final point: My understanding, from reading the > documentation and blog/news posts about GAE, is that the the core of > GAE is ripped pretty much directly from production Google services. > The problem with this is, the scheduler is intended to work at very > high scale, not at low scale. And frankly, this makes sense when you > consider a lot of the finer points of the GAE ecosystem. > > So, to fix this: GAE needs to have a good relook at scheduler code, > and rewrite it so that it has two different rules for apps at less > than 50 instances, and more than 50 instances. Additionally, perhaps > the GAE should look at making the scheduler smarter; perhaps it could > measure the startup time of instances, and in the future, not send > requests to cold instances until that startup time has elapsed. > > Personal thoughts: I have admined a corporate GAE app that has > exceeded 100 instances, and I use GAE for personal apps that use, at > max, 3-4 instances. When you use GAE at these two extremes, you really > get an understanding of how GAE scales. For instance, a personal > anecdote: for my low end apps, I occasionally notice that GAE starts > up a new idle instance. I'm not charged for it, it doesn't do any > work, but it is counted in the "current instances" counter. My guess > is that, during non-peak times, the GAE scheduler will load into > memory additional instances of low end apps, to try and be ready for > quick scaling. So I believe the GAE team tries to handle low-end > instances, but it does need more work. > > TLDR: the scheduler needs more work, and MegaWalmart is the same thing > as Google's scheduler. -- 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/-/FVPDaFE41akJ. To post to this group, se
[google-appengine] Re: Startup time exceeded...on F4?!
Really, looking forward to see reply from Googler(s) regarding this. On Thursday, July 19, 2012 12:11:27 AM UTC+2, Michael Hermus wrote: > > I certainly appreciate the attempted explanation. Correct me if I am > wrong, but what you said amounts to this: > > Google has to route requests to cold start instances because otherwise, >> for large scale apps, the pending queue might get way too big, not to >> mention it could blow up sometime. >> > > If that is true, I suppose I would be quite surprised, for the following > reasons: > > a) Google's entire infrastructure is designed for EVERYTHING to scale > massively and still work well. > b) By waiting for instances to warm up first, I don't think you would > really increase the maximum depth of the pending queue by a whole lot. In > fact, the larger your app (i.e. the more instances you have active), the > less impact it would have relative to the alternative. > c) I don't think the pending queue is 'hosted' on a single machine; I am > pretty sure it relies on a resilient queue infrastructure designed to > tolerate failures and scale well. > > > On Wednesday, July 18, 2012 5:07:04 PM UTC-4, hyperflame wrote: >> >> On Jul 18, 2:38 pm, Michael Hermus wrote: >> > I dont believe that you (or anyone) has sufficiently explained how >> sending user requests to cold instances is ever better than warming it up >> first.. Said request can ALWAYS be pulled right off the pending queue and >> sent to the instance as soon as it is ready. >> >> Let me take a shot at this. Brandon Wirtz touched on it before, when >> he said "I agree that the Queue is sub optimal, but it is more sub >> optimal the smaller you are. When you get to 50 instances it is >> amazing how well the load balancing works. " >> >> Suppose you have a massive store (we'll call it MegaWalmart). >> MegaWalmart has 100 staffed checkout lanes. Suppose all of these lanes >> have a single queue of people lined up, and a supervisor which sends >> customers to open checkout lanes (roughly analogous to your preferred >> way of handling GAE request queuing). That one line would be huge, >> would block traffic around the store, etc. It's far better, from >> MegaWalmart's POV, to have multiple check out lines, one line per each >> lane. >> >> Now suppose you have another checkout lane open up. (remember, now we >> have one line per lane) That's an additional 1% capacity. Now if the >> checkout clerk is drunk/hungover/whatever, that additional lane will >> take extra time to open, annoying the customers lined up in that lane. >> From MegaWalmart's POV, who cares? Less than 1% of your customers were >> inconveniced. 99% of people still had a decent time checking out. >> >> Let's apply this to the scheduler. Suppose there was one single queue >> of requests. At Google-scale, that queue of requests could easily >> exceed millions of entries, possibly billions. And God help you if the >> machine hosting the queue gets a hiccup, or an outright failure. Don't >> you agree that, at least at Google-scale, requests should immediately >> be shunted to instance-level queues? Even if a single instance takes >> forever, or fails, we don't have to care: such a failure would only >> affect 0.01% of users. >> >> This leads me to my final point: My understanding, from reading the >> documentation and blog/news posts about GAE, is that the the core of >> GAE is ripped pretty much directly from production Google services. >> The problem with this is, the scheduler is intended to work at very >> high scale, not at low scale. And frankly, this makes sense when you >> consider a lot of the finer points of the GAE ecosystem. >> >> So, to fix this: GAE needs to have a good relook at scheduler code, >> and rewrite it so that it has two different rules for apps at less >> than 50 instances, and more than 50 instances. Additionally, perhaps >> the GAE should look at making the scheduler smarter; perhaps it could >> measure the startup time of instances, and in the future, not send >> requests to cold instances until that startup time has elapsed. >> >> Personal thoughts: I have admined a corporate GAE app that has >> exceeded 100 instances, and I use GAE for personal apps that use, at >> max, 3-4 instances. When you use GAE at these two extremes, you really >> get an understanding of how GAE scales. For instance, a personal >> anecdote: for my low end apps, I occasionally notice that GAE starts >> up a new idle instance. I'm not charged for it, it doesn't do any >> work, but it is counted in the "current instances" counter. My guess >> is that, during non-peak times, the GAE scheduler will load into >> memory additional instances of low end apps, to try and be ready for >> quick scaling. So I believe the GAE team tries to handle low-end >> instances, but it does need more work. >> >> TLDR: the scheduler needs more work, and MegaWalmart is the same thing >> as Google's schedul
[google-appengine] Re: Startup time exceeded...on F4?!
On Jul 18, 5:11 pm, Michael Hermus wrote: > If that is true, I suppose I would be quite surprised, for the following > reasons: > > a) Google's entire infrastructure is designed for EVERYTHING to scale > massively and still work well. "Massively" being the key word there. Every Google service is massive. Even abandoned or low use Google services (i.e. Wave, Buzz) are going to use the equivalent of a minimum 10,000 F4 instances. The GAE scheduler does inefficient scheduling at less than 50 instances. It works wonderfully once you hit scale at 100+ machines(correct me if I'm wrong, but most of the people seeing problems here are probably less than 50 instances). > b) By waiting for instances to warm up first, I don't think you would > really increase the maximum depth of the pending queue by a whole lot. I would have to disagree with you on this. My experience with big websites tells me that requests can very quickly pile up if you're not handling them expeditiously. > c) I don't think the pending queue is 'hosted' on a single machine; I am > pretty sure it relies on a resilient queue infrastructure designed to > tolerate failures and scale well. My analogy, like all analogies, breaks down if you apply it literally. Even if you (hypothetically) built a datacenter with 100,000 machines solely dedicated to hosting a single request queue, that datacenter can still go down (earthquake, power, hurricane, etc). Far better to simply dump requests into instance level queues and be done with it. Just to be clear, I am agreeing with you in that the GAE scheduler needs work; it is currently optimizing for high-scale apps, and not apps that are using double-digit or lower instances. -- 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: SSL support
> site seem shady. With Internet Explorer if the user clicks through the > certificate warning and continues to you site, the URL input bar stays > highlighted with a red background and an intimidating "certificate error" > message is displayed to the right of the URL. > IE8 doesn't work at all for us with SNI: "Internet Explorer cannot display the webpage" Talking about costs, something like Page Speed is terribly expensive, and also Cloud Storage, an extra bill... -- 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/-/c2M8xhINiLcJ. 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: Startup time exceeded...on F4?!
On Wed, Jul 18, 2012 at 3:55 PM, hyperflame wrote: > > "Massively" being the key word there. Every Google service is massive. > Even abandoned or low use Google services (i.e. Wave, Buzz) are going > to use the equivalent of a minimum 10,000 F4 instances. The GAE > scheduler does inefficient scheduling at less than 50 instances. It > works wonderfully once you hit scale at 100+ machines(correct me if > I'm wrong, but most of the people seeing problems here are probably > less than 50 instances). This is an interesting discussion. How many apps do you think are on GAE that run 100+ instances? 1000+? While these are certainly going to be the "important" apps for Google, I suspect they are fairly few in number. With a couple exceptions, the owners are very quiet on this list. I wonder also how many of them are on multithreaded runtimes, and of those, how many of them are on Java runtimes. >> b) By waiting for instances to warm up first, I don't think you would >> really increase the maximum depth of the pending queue by a whole lot. > > I would have to disagree with you on this. My experience with big > websites tells me that requests can very quickly pile up if you're not > handling them expeditiously. I think we're looking at this wrong. The question is not "should there be more than a single queue"; I certainly agree that we certainly don't want one loadbalancer falling over and taking down a thousand pending requests. The important question is "should requests go to a queue that is locked to a single (unstarted) instance", which is a different question. It's certainly possible to have multiple queues with the ability to route requests to active instances. At Google scale there must certainly already be multiple queues; obviously one computer cannot route the zillions of requests per second that www.google.com gets. Continuing the MegaWalmart example, you don't need to have one big line routed around the store; you can have a number of lines each of which route among banks of cashiers. Presumably GAE has some sort of equivalent construct. "Less than 1% of your customers were inconveniced. 99% of people still had a decent time checking out." is not very comforting. If 1% of Google searches took 8+ seconds to respond, the Googleplex alarms would deafen people as far away as Oakland. > Just to be clear, I am agreeing with you in that the GAE scheduler > needs work; it is currently optimizing for high-scale apps, and not > apps that are using double-digit or lower instances. I fear that GAE is optimized for single-threaded Python2.5 apps which take 2s to spin up, an environment that is becoming less relevant as time goes on. Given an app that takes 20+ seconds to start, would a high-traffic app work any better than a low-traffic app? 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] Re: SSL support
http://blorn.com/post/20185054195/ssl-for-your-domain-on-google-app-engine
It still works and it's still $20/mo. Yes, it's unencrypted between
CF and Google. Assuming you aren't taking credit cards directly, is
that a problem?
Jeff
On Wed, Jul 18, 2012 at 2:39 PM, Doug Anderson wrote:
> I share your sentiment about the SSL support 100%... it's great to finally
> have it but the reality is the ecosystem just isn't ready for SNI yet.
> There are still too many browsers that don't support SNI including the
> Kindle Fire and every other pre-Ice Cream Sandwich Android device (of which
> there are many). To be honest I expect Google to be a better steward of
> the Internet. Proper SSL support should be encouraged and offered as an
> inherent part any professional web development platform. SSL should NOT be
> treated as a major feature upgrade where cost becomes a deciding factor for
> adoption. By favoring SNI Google is compromising the integrity of the
> browser experience anytime the overwhelming majority of Android users browse
> to a secure App Engine site.
>
> The non-SNI supporting browsers I've tested generate big ol' certificate
> warnings and strongly encourage users NOT to continue browsing to the site.
> Users generally have a choice to continue or not but the warnings sound
> quite ominous and make it seem like your illegitimate site is pretending to
> be someone else's legitimate site ("the certificate this site is using was
> issued for another web address"). Unfortunately, adopting SNI right now
> just pollutes the browsing experience and makes your site seem shady. With
> Internet Explorer if the user clicks through the certificate warning and
> continues to you site, the URL input bar stays highlighted with a red
> background and an intimidating "certificate error" message is displayed to
> the right of the URL.
>
> I'm all for Google profiting from App Engine but it seems like there are
> enough other opportunities for that since they monitor and charge for just
> about everything else. I'm still hoping there's enough "don't be evil"
> within Google that they decide to favor a seamless browsing experience over
> a pay-for-proper-security profit grab. Perhaps in another 3-5 years the
> ecosystem will be more accommodating of SNI but unfortunately that day isn't
> here yet.
>
>
> On Wednesday, July 18, 2012 3:02:20 PM UTC-4, GAEfan wrote:
>>
>> So happy to see SSL support finally here, but a bit disappointed. VIP
>> seems the way to go, but at $99 per month, it is cost prohibitive for some
>> of our apps. So, I am asking for feedback from others who have implemented
>> SNI. From my understanding, there are still many visitors with older
>> browsers who will not be able to use it. Is that correct?
>>
>> Looking at recent stats, we have 16% of our visitors with IE 6 or 7. And
>> an astounding 43% with XP or previous versions of Windows. Not to mention
>> those with Safari/Win, or older Android OS. What will these visitors see
>> when they try to access an SNI-SSL page?
>>
>> Any problems/issues encountered with SNI implementations? Older browsers?
>> International visitors? Frankly, at $108/year PLUS the certificate, even
>> SNI-SSL is expensive. But $1200/year, plus cert, for VIP is not feasible
>> for smaller apps. (IMO, $108/year should cover virtual IP). Sticking with
>> our appspot URLs for SSL until this is ready for prime time. We are not
>> willing to abandon even a small single-digit percentage of our users.
>>
>> Also, I recently was told that some search engines use the IP address in
>> page ranking. Shared IPs are penalized. Had not heard that before, and not
>> sure that is accurate, as a majority of sites are on shared-IPs.
>>
>> Your feedback greatly appreciated.
>>
>>
> --
> 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/-/HUXzIEE43doJ.
>
> 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: Startup time exceeded...on F4?!
On Jul 18, 7:01 pm, Jeff Schnitzer wrote: > This is an interesting discussion. How many apps do you think are on > GAE that run 100+ instances? 1000+? While these are certainly going > to be the "important" apps for Google, I suspect they are fairly few > in number. With a couple exceptions, the owners are very quiet on > this list. As I noted before, I have admined a 100+ instance GAE app, and know a few companies that have or currently do run at that scale. To be completely honest, many of those (that I know personally) have migrated to AWS or similar cloud firms. 8 cents per F1 instance hour is a budget breaker; AWS is much cheaper and (this is far more important to managers) has a track record of periodically lowering prices. Also, you might be surprised at who reads this list. I have seen firsthand several executives and corporate strategists read this list, or get forwarded excerpts by their engineers. They might be "very quiet" but they are watching (cue Jaws the movie music... ) > "Less than 1% of your customers were inconveniced. 99% of people still > had a decent time checking out." is not very comforting. If 1% of > Google searches took 8+ seconds to respond, the Googleplex alarms > would deafen people as far away as Oakland. Just as a purely practical issue, I routinely experience long load times for certain Google services. Search is always fast, but Gmail can take some time to load on my iPad: when i go to gmail.com, the url box will bounce between several different urls before loading, at least 6-8 seconds. Is there an "alarm" form that I can fill out? :-) > I fear that GAE is optimized for single-threaded Python2.5 apps which > take 2s to spin up, an environment that is becoming less relevant as > time goes on. Given an app that takes 20+ seconds to start, would a > high-traffic app work any better than a low-traffic app? My experience is in Java, so I have no reference to single threaded Python 2.5 apps. With that said, the main problem is the scheduler. Essentially, the GAE people have to rewrite the scheduler to reflect the following rules: 1. For apps that use 50+ instances, use the current rules for scheduling. 2. For apps that are fewer than 50 instances, change to the following rules: 2A: Record the startup times for the past 20 instance startups. 2B: Instances that are started up do not receive requests until the average of the startup times + 20% has elapsed. 2C: In nonpeak hours, idle instances are free or heavily discounted 2D: During times when GAE is experiencing high latency, the scheduler is more aggressive in spooling up more instances. Idle instances spooled up during this time are cheaper (30% discount seems fair...) -- 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: SSL support
Hi all,
I am the Product Manager on App Engine responsible for SSL.
There seems to be a little bit of confusion about how VIPs can be used. A
single VIP can be used for a number of applications via the use of a
wildcard or multi-domain/SAN certificate. Multiple domain (domain.com and
domain.net) support can be achieved by adding the additional domain as an
alias of your primary domain and using a multi-domain/SAN certificate.
Regarding the concerns about browser support for SNI, SNI is supported by
most modern browsers with a few exceptions, notably Internet Explorer and
Safari on Windows XP as well as Android 2.2 and below. Please note that
this is not all browsers on Windows XP simply IE and Safari, Chrome and
Firefox will work on XP without issue.
I would also like to clarify what happens when a user with a browser that
does not support SNI visits an App Engine application being served over
SNI. If the page is being served over HTTP there will be no issues. If the
site is being served over HTTPS the browser will be unable to connect.
This is a decision we made to stop users being presented with security
warnings which may give them a negative impression of the site. We
recommend warning users who visit your application (over HTTP) using a
browser that does not support SNI to install a browser which does support
SNI (such as Chrome or Firefox) .
I hope this addresses some of the questions raised in this thread.
Cheers,
Cayden Meyer
Product Manager, Google App Engine
On 19 July 2012 10:07, Jeff Schnitzer wrote:
> http://blorn.com/post/20185054195/ssl-for-your-domain-on-google-app-engine
>
> It still works and it's still $20/mo. Yes, it's unencrypted between
> CF and Google. Assuming you aren't taking credit cards directly, is
> that a problem?
>
> Jeff
>
> On Wed, Jul 18, 2012 at 2:39 PM, Doug Anderson
> wrote:
> > I share your sentiment about the SSL support 100%... it's great to
> finally
> > have it but the reality is the ecosystem just isn't ready for SNI yet.
> > There are still too many browsers that don't support SNI including the
> > Kindle Fire and every other pre-Ice Cream Sandwich Android device (of
> which
> > there are many). To be honest I expect Google to be a better steward of
> > the Internet. Proper SSL support should be encouraged and offered as an
> > inherent part any professional web development platform. SSL should NOT
> be
> > treated as a major feature upgrade where cost becomes a deciding factor
> for
> > adoption. By favoring SNI Google is compromising the integrity of the
> > browser experience anytime the overwhelming majority of Android users
> browse
> > to a secure App Engine site.
> >
> > The non-SNI supporting browsers I've tested generate big ol' certificate
> > warnings and strongly encourage users NOT to continue browsing to the
> site.
> > Users generally have a choice to continue or not but the warnings sound
> > quite ominous and make it seem like your illegitimate site is pretending
> to
> > be someone else's legitimate site ("the certificate this site is using
> was
> > issued for another web address"). Unfortunately, adopting SNI right now
> > just pollutes the browsing experience and makes your site seem shady.
> With
> > Internet Explorer if the user clicks through the certificate warning and
> > continues to you site, the URL input bar stays highlighted with a red
> > background and an intimidating "certificate error" message is displayed
> to
> > the right of the URL.
> >
> > I'm all for Google profiting from App Engine but it seems like there are
> > enough other opportunities for that since they monitor and charge for
> just
> > about everything else. I'm still hoping there's enough "don't be evil"
> > within Google that they decide to favor a seamless browsing experience
> over
> > a pay-for-proper-security profit grab. Perhaps in another 3-5 years the
> > ecosystem will be more accommodating of SNI but unfortunately that day
> isn't
> > here yet.
> >
> >
> > On Wednesday, July 18, 2012 3:02:20 PM UTC-4, GAEfan wrote:
> >>
> >> So happy to see SSL support finally here, but a bit disappointed. VIP
> >> seems the way to go, but at $99 per month, it is cost prohibitive for
> some
> >> of our apps. So, I am asking for feedback from others who have
> implemented
> >> SNI. From my understanding, there are still many visitors with older
> >> browsers who will not be able to use it. Is that correct?
> >>
> >> Looking at recent stats, we have 16% of our visitors with IE 6 or 7.
> And
> >> an astounding 43% with XP or previous versions of Windows. Not to
> mention
> >> those with Safari/Win, or older Android OS. What will these visitors
> see
> >> when they try to access an SNI-SSL page?
> >>
> >> Any problems/issues encountered with SNI implementations? Older
> browsers?
> >> International visitors? Frankly, at $108/year PLUS the certificate,
> even
> >> SNI-SSL is expensive. But $1200/year, plus cert, for VIP is not
> feasible
> >
Re: [google-appengine] Re: SSL support
Hi Cayden,
thanks for your input, but I have to ask, in what way does preventing a
browser from connecting to a site not give the visitor a negative
impression of that site? Is it better that the visitor thinks the site is
not available at all?
I think you may be downplaying the number of incompatible browsers in use
today. Ignoring XP, Google's Nexus One got Android 2.2 just 2 years ago, a
common contract period for mobiles.. so how many pre-2.2 Android phones
have been sold since then?
Just to clarify.. your suggested solution, if using SNI to provide a secure
website and wanting to somewhat support non-SNI browsers would be:
- never publicise secure urls
for each connection:
- detect the browser and decide whether or not the browser supports SNI (a
mostly accurate guess based on a list of browsers in your code)
- either redirect to the secure url, warn the user and tell them to
install a new browser, or just serve up the unsecured content.
cheers,
J
On Thu, Jul 19, 2012 at 1:18 PM, Cayden Meyer wrote:
> Hi all,
>
> I am the Product Manager on App Engine responsible for SSL.
>
> There seems to be a little bit of confusion about how VIPs can be used. A
> single VIP can be used for a number of applications via the use of a
> wildcard or multi-domain/SAN certificate. Multiple domain (domain.com and
> domain.net) support can be achieved by adding the additional domain as an
> alias of your primary domain and using a multi-domain/SAN certificate.
>
> Regarding the concerns about browser support for SNI, SNI is supported by
> most modern browsers with a few exceptions, notably Internet Explorer and
> Safari on Windows XP as well as Android 2.2 and below. Please note that
> this is not all browsers on Windows XP simply IE and Safari, Chrome and
> Firefox will work on XP without issue.
>
> I would also like to clarify what happens when a user with a browser that
> does not support SNI visits an App Engine application being served over
> SNI. If the page is being served over HTTP there will be no issues. If the
> site is being served over HTTPS the browser will be unable to connect.
> This is a decision we made to stop users being presented with security
> warnings which may give them a negative impression of the site. We
> recommend warning users who visit your application (over HTTP) using a
> browser that does not support SNI to install a browser which does support
> SNI (such as Chrome or Firefox) .
>
> I hope this addresses some of the questions raised in this thread.
>
> Cheers,
>
> Cayden Meyer
> Product Manager, Google App Engine
>
>
>
> On 19 July 2012 10:07, Jeff Schnitzer wrote:
>
>> http://blorn.com/post/20185054195/ssl-for-your-domain-on-google-app-engine
>>
>> It still works and it's still $20/mo. Yes, it's unencrypted between
>> CF and Google. Assuming you aren't taking credit cards directly, is
>> that a problem?
>>
>> Jeff
>>
>> On Wed, Jul 18, 2012 at 2:39 PM, Doug Anderson
>> wrote:
>> > I share your sentiment about the SSL support 100%... it's great to
>> finally
>> > have it but the reality is the ecosystem just isn't ready for SNI yet.
>> > There are still too many browsers that don't support SNI including the
>> > Kindle Fire and every other pre-Ice Cream Sandwich Android device (of
>> which
>> > there are many). To be honest I expect Google to be a better steward
>> of
>> > the Internet. Proper SSL support should be encouraged and offered as an
>> > inherent part any professional web development platform. SSL should
>> NOT be
>> > treated as a major feature upgrade where cost becomes a deciding factor
>> for
>> > adoption. By favoring SNI Google is compromising the integrity of the
>> > browser experience anytime the overwhelming majority of Android users
>> browse
>> > to a secure App Engine site.
>> >
>> > The non-SNI supporting browsers I've tested generate big ol' certificate
>> > warnings and strongly encourage users NOT to continue browsing to the
>> site.
>> > Users generally have a choice to continue or not but the warnings sound
>> > quite ominous and make it seem like your illegitimate site is
>> pretending to
>> > be someone else's legitimate site ("the certificate this site is using
>> was
>> > issued for another web address"). Unfortunately, adopting SNI right now
>> > just pollutes the browsing experience and makes your site seem shady.
>> With
>> > Internet Explorer if the user clicks through the certificate warning and
>> > continues to you site, the URL input bar stays highlighted with a red
>> > background and an intimidating "certificate error" message is displayed
>> to
>> > the right of the URL.
>> >
>> > I'm all for Google profiting from App Engine but it seems like there are
>> > enough other opportunities for that since they monitor and charge for
>> just
>> > about everything else. I'm still hoping there's enough "don't be evil"
>> > within Google that they decide to favor a seamless browsing experience
>> over
>> > a pay-for-proper-securi
Re: [google-appengine] Re: managing bulk emails from app engine app
hie can some one help us on suggesting third party emails systems which are good to go to integrate with app engine? Vik On Thursday, 12 July 2012 22:51:24 UTC-7, Vivek Kumar wrote: > > Hie Jeff > > Which thrid party system do you guys use? please share the details like > how u r using their service to send emails from your gae app > > Vik > > On Sunday, 8 July 2012 09:13:15 UTC-7, Jeff Schnitzer wrote: >> >> I should add that we also use a third-party email system. Ultimately >> it's no harder to make a REST call to an external service than to make >> a call to MailService, and many services offer a much more robust >> solution. GAE's mail system has silly limitations like the inability >> to send emails with inline (Content-ID) image attachments. >> >> Just make sure that your 'unit of work' is the same as a single >> urlfetch. You wouldn't want to put 100 REST calls in a single task - >> imagine it failed at #50, then the whole task will retry and re-spam >> #1-#49. If your mail service does "send this message to these 100 >> people", great; otherwise stick to one-email-per-task. We do >> one-email-per-task. >> >> Jeff >> >> On Sun, Jul 8, 2012 at 8:57 AM, Richard Watson >> wrote: >> > Offload both transactional and bulk email to a 3rd-party email >> specialist. >> > It's their core competence, and you're likely to be able to send bulk >> email >> > with one api call once your list is set up. If you have issues you'll >> have >> > better insight into what those are. You can get delivery and read >> reports, >> > and automatic remove-me-from-your-list handling. >> > >> > >> > On Sunday, July 8, 2012 5:27:04 PM UTC+2, Per wrote: >> >> >> >> Hi Vik, >> >> >> >> technical details aside, keep in mind that the spam filter settings on >> App >> >> Engine can be pretty strict. We have been sending mails for 18 months >> now, >> >> increasing the number gradually, and we also used DKIM signing. Still, >> >> suddenly some time last week our mails stopped getting sent. From all >> I can >> >> tell some Google mechanism decided that we're a spammer. We have >> inquired >> >> with Google instantly, but of course the GAE customer service is poor >> as >> >> always and never got back to us. So we switched to an external email >> >> provider now (mailgun, but there are dozens out there), and I'm quite >> happy >> >> with that, since tracking of emails is a lot more convenient too. It's >> not >> >> free though. >> >> >> >> Long story short, if you all of a sudden send 10k mails, be prepared >> to >> >> get filtered by Google because they think you're a spammer. Make sure >> to >> >> spread the load, and track what you have sent already, so you know >> what >> >> you'd need to resend if push comes to shove. >> >> >> >> Cheers, >> >> Per >> >> >> >> >> >> On Saturday, July 7, 2012 7:19:12 PM UTC+2, Vivek Kumar wrote: >> >>> >> >>> Hello >> >>> >> >>> We have around 1 registered users with us who are blood donors. >> We >> >>> want to send them periodic emails like every month to remind them or >> their >> >>> account status etc. >> >>> Obviously, a single request cannot process so many emails. >> >>> >> >>> So, what is the suggested way to handle this use case without hitting >> >>> request time limits etc on app engine? >> >>> >> >>> our app is in GAE for java >> >>> >> >>> Vik >> > >> > -- >> > 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/-/m4NlskwCrF8J. >> > >> > 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 view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/GaZ_VCP6tUAJ. 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] SSL for custom domain app engine performance issues
Hi Will,
There are potentially many causes of end-to-end latency in a request.
During my testing I see roughly equal performance between appspot.com and
SSL on my custom domain.
Are you able to exclude DNS as a source of the increased latency (retry a
few times to ensure the host is in your systems cache)?
Is there a significant different in a straight TCP connection to each of
different addresses (see python code below)?
SSL in general can add additional latency on top of a non-SSL connection
due to the initial multiple round trips associated with the SSL handshake.
Thanks,
Cayden Meyer
Product Manager, Google App Engine
import socket
import time
def time_connect(*args, **kwargs):
sock = socket.socket()
start = time.time()
sock.connect(*args, **kwargs)
end = time.time()
print end - start, 'seconds'
time_connect(('www.appspot.com', 80))
time_connect(('ghs.googlehosted.com
Re: [google-appengine] Re: SSL support
Hi Jason, We offer both SNI and VIP to give you options between price and better browser compatibility. If it is important to you to have full compatibility with all browsers or a particular subset that does not support SNI such as Android 2.2 then using a VIP is the best option. If you wish to use SNI and give users without SNI support the best possible experience then there are a few things you can do such as what I suggested in my previous post. Your summary of my suggestion is one way of supporting non-SNI browsers when using SNI. In the case of Android 2.2 or below, apart from the suggestions already mentioned there is also the option of having an Android application which connects securely to your application's appspot.com address. Cheers, Cayden Meyer Product Manager, Google App Engine On 19 July 2012 14:03, Jason Galea wrote: > Hi Cayden, > > thanks for your input, but I have to ask, in what way does preventing a > browser from connecting to a site not give the visitor a negative > impression of that site? Is it better that the visitor thinks the site is > not available at all? > > I think you may be downplaying the number of incompatible browsers in use > today. Ignoring XP, Google's Nexus One got Android 2.2 just 2 years ago, a > common contract period for mobiles.. so how many pre-2.2 Android phones > have been sold since then? > > Just to clarify.. your suggested solution, if using SNI to provide a > secure website and wanting to somewhat support non-SNI browsers would be: > > - never publicise secure urls > for each connection: > - detect the browser and decide whether or not the browser supports SNI > (a mostly accurate guess based on a list of browsers in your code) > - either redirect to the secure url, warn the user and tell them to > install a new browser, or just serve up the unsecured content. > > cheers, > > J > > > > > On Thu, Jul 19, 2012 at 1:18 PM, Cayden Meyer wrote: > >> Hi all, >> >> I am the Product Manager on App Engine responsible for SSL. >> >> There seems to be a little bit of confusion about how VIPs can be used. A >> single VIP can be used for a number of applications via the use of a >> wildcard or multi-domain/SAN certificate. Multiple domain (domain.comand >> domain.net) support can be achieved by adding the additional domain as >> an alias of your primary domain and using a multi-domain/SAN certificate. >> >> Regarding the concerns about browser support for SNI, SNI is supported by >> most modern browsers with a few exceptions, notably Internet Explorer and >> Safari on Windows XP as well as Android 2.2 and below. Please note that >> this is not all browsers on Windows XP simply IE and Safari, Chrome and >> Firefox will work on XP without issue. >> >> I would also like to clarify what happens when a user with a browser that >> does not support SNI visits an App Engine application being served over >> SNI. If the page is being served over HTTP there will be no issues. If the >> site is being served over HTTPS the browser will be unable to connect. >> This is a decision we made to stop users being presented with security >> warnings which may give them a negative impression of the site. We >> recommend warning users who visit your application (over HTTP) using a >> browser that does not support SNI to install a browser which does support >> SNI (such as Chrome or Firefox) . >> >> I hope this addresses some of the questions raised in this thread. >> >> Cheers, >> >> Cayden Meyer >> Product Manager, Google App Engine >> >> >> >> On 19 July 2012 10:07, Jeff Schnitzer wrote: >> >>> >>> http://blorn.com/post/20185054195/ssl-for-your-domain-on-google-app-engine >>> >>> It still works and it's still $20/mo. Yes, it's unencrypted between >>> CF and Google. Assuming you aren't taking credit cards directly, is >>> that a problem? >>> >>> Jeff >>> >>> On Wed, Jul 18, 2012 at 2:39 PM, Doug Anderson >>> wrote: >>> > I share your sentiment about the SSL support 100%... it's great to >>> finally >>> > have it but the reality is the ecosystem just isn't ready for SNI yet. >>> > There are still too many browsers that don't support SNI including the >>> > Kindle Fire and every other pre-Ice Cream Sandwich Android device (of >>> which >>> > there are many). To be honest I expect Google to be a better steward >>> of >>> > the Internet. Proper SSL support should be encouraged and offered as >>> an >>> > inherent part any professional web development platform. SSL should >>> NOT be >>> > treated as a major feature upgrade where cost becomes a deciding >>> factor for >>> > adoption. By favoring SNI Google is compromising the integrity of the >>> > browser experience anytime the overwhelming majority of Android users >>> browse >>> > to a secure App Engine site. >>> > >>> > The non-SNI supporting browsers I've tested generate big ol' >>> certificate >>> > warnings and strongly encourage users NOT to continue browsing to the >>> site. >>> > Users generally have a choice to
RE: [google-appengine] Re: Startup time exceeded...on F4?!
I can make searches that are slow. You just have to pick things no one has searched before. That said, the 1% of bad check outs would only apply if you only serve 1 request from the slow server. If each instance serves 100k requests in its lifetime, then you are talking about 1/100k being negatively impacted. Even my lowliest of instances serves 3000 in 2 hours. Before dying. I said 15s spinup because I think that was your number. I shoot for spin ups that are under 4s. If my spinup is more than 4s I create a new app, or dynamic back end to handle the requests with specialized version of the microapp that is faster to load. -- 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: SSL support
> > Hi Cayden, > Thank you for responding, as this is an extremely important issue. Google has always stated their objective was to make the internet better, faster, easier. However, this SSL solution is a less-than-expected solution. 1) Charging $99/month for an acceptable solution puts a real roadblock in the SSL chain. Shouldn't Google want to make SSL ubiquitous, as part of their objective? $99/year is more of an acceptable rate, though still about double what it should be. $1200/year prices SSL out of the budget for smaller apps, and seems usurious. 2) I, too, think you are downplaying the incompatibility of the SNI solution. I believe that somewhere near 15% of visitors cannot use the SNI solution. We are not willing to block even 1% of our visitors. We pay Google AdWords too much to get them, just to turn them away again. I cannot believe Google would even consider SNI is an acceptable solution, turning away web visitors. 3) Detecting browsers and redirecting is a waste of resources. 4) Serving insecure content (when security is warranted) is unacceptable. 5) Breaking the security chain without informing the visitor is unacceptable. 6) Detecting browsers, and serving up a "Go away and download a better browser" message is absurd! Talk about giving the visitor a negative impression of your site. In summary, SNI is a poor solution, and not up to Google standards. VIP is a fine solution, but priced absurdly. -- 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/-/rbFBHQ4R29EJ. 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] Help. My app is down
I can access buzzjourney.appspot.com 2012/7/17 buzzjourney > Hi, > > I am unable to access my app (buzzjourney.appspot.com). > All I get is the Server Error message. > I am unable to deploy (keeps waiting until it gives up). > Please assist. > Is anyone else experiencing this issue? The system status page does not > show any issues. > > -- > 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/-/tOSQIdTRnlwJ. > 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: SSL support
We were happy enough to go with the SNI solution. We don't have mobile users on our web interface, and we are yet to receive a complaint from an irate Windows XP user. We detect what browser and OS a client has, and if it's not SNI friendly we show them a warning: http://imgur.com/a/Axzur As you can see from the table in the above link even on XP you have options (via other browsers that suck less). On 19 July 2012 15:54, GAEfan wrote: > Hi Cayden, >> > > Thank you for responding, as this is an extremely important issue. > Google has always stated their objective was to make the internet better, > faster, easier. However, this SSL solution is a less-than-expected > solution. > > 1) Charging $99/month for an acceptable solution puts a real roadblock in > the SSL chain. Shouldn't Google want to make SSL ubiquitous, as part of > their objective? $99/year is more of an acceptable rate, though still > about double what it should be. $1200/year prices SSL out of the budget > for smaller apps, and seems usurious. > 2) I, too, think you are downplaying the incompatibility of the SNI > solution. I believe that somewhere near 15% of visitors cannot use the SNI > solution. We are not willing to block even 1% of our visitors. We pay > Google AdWords too much to get them, just to turn them away again. I > cannot believe Google would even consider SNI is an acceptable solution, > turning away web visitors. > 3) Detecting browsers and redirecting is a waste of resources. > 4) Serving insecure content (when security is warranted) is unacceptable. > 5) Breaking the security chain without informing the visitor is > unacceptable. > 6) Detecting browsers, and serving up a "Go away and download a better > browser" message is absurd! Talk about giving the visitor a negative > impression of your site. > > In summary, SNI is a poor solution, and not up to Google standards. VIP > is a fine solution, but priced absurdly. > > > -- > 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/-/rbFBHQ4R29EJ. > > 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.
