Re: [google-appengine] Google App Engine Android Facebook login

[Ruben A.]

Les, I have a quick question for you.  Above you state:

"If you expect a small number of users, at least to start with - use 
Firebase.
If you already have a lot of users or expect lots of users -- use Identity 
Toolkit."

I am not looking for an exact number, but would you consider 50k users 
'small' and better for a firebase app then Identity toolkit?

Thanks

Ruben


On Saturday, July 11, 2015 at 1:16:11 PM UTC-5, Les Vogel wrote:
>
> I should have it published before 2pm today.
>
> On Sat, Jul 11, 2015 at 9:16 AM, Shruthi Sharat  > wrote:
>
>> Hi,
>>
>>Thank you for the reply. I will be waiting for that sample code.
>>
>> How do I validate the id token in my app engine back end which i am 
>> getting from the toolkit? Can you please provide some kind of documents or 
>> sample code.
>>
>> Regards,
>> Shruthi Kumbham
>>
>>
>>
>> On Fri, Jul 10, 2015 at 12:19 AM, 'Les Vogel' via Google App Engine <
>> google-a...@googlegroups.com > wrote:
>>
>>> Firebase Auth is easy to get started with and use.  Your connecting 3rd 
>>> party auth to it.  (The folks from Firebase might describe this differently)
>>> Identity Toolkit is fairly robust and will scale to millions of users.
>>>
>>> If you expect a small number of users, at least to start with - use 
>>> Firebase.
>>> If you already have a lot of users or expect lots of users -- use 
>>> Identity Toolkit.
>>>
>>> The sample I mentioned should be published tomorrow afternoon.   
>>> https://github.com/GoogleCloudPlatform/Abelana
>>>
>>> On Thu, Jul 9, 2015 at 1:37 AM, Shruthi Sharat >> > wrote:
>>>
 Hi, 

  Thank You. Please let me know how is Firebase and Identity Toolkit 
 differs ? I am not able to decide which one to go with.

 Can I have my backend code and database running on App Engine and just 
 use Firebase for authentication and sessions ? If Yes, how can i connect 
 my 
 Firebase with my App Engine ?

 Which is best to go with, Firebase or Identity Toolkit ? 

 Kindly clarify. I find very less documentation on these.

 Regards,
 Shruthi Kumbham



 On Mon, Jul 6, 2015 at 10:05 PM, 'Les Vogel' via Google App Engine <
 google-a...@googlegroups.com > wrote:

> Hope to have an example published by Tuesday of next week.
>
> Les
>
> On Fri, Jul 3, 2015 at 12:38 AM, Shruthi Sharat  > wrote:
>
>> Thank you so much for reply.
>>
>>  I could able to use the identity toolkit API and able to login via 
>> G+ and facebook.  But I am not able to access my endpoints by logging 
>> into 
>> G+ or Facebook. 
>>
>> Please let me know the procedure to do it. I can't find any 
>> documentation also.It will be a great help.
>>
>> Regards,
>> Shruthi Kumbham
>>
>> On Thu, Jul 2, 2015 at 2:07 AM, 'Les Vogel' via Google App Engine <
>> google-a...@googlegroups.com > wrote:
>>
>>> Hi Shruthi,
>>>
>>> You might wish to take a look at the Google Identity Toolkit 
>>>  Libraries(Java 
>>> , & Go 
>>>  ) & Samples (
>>> Android , 
>>> iOS , & Java 
>>> ).  It will 
>>> let you do Facebook & G+ and your own authentication and connect with 
>>> Android, iOS, and your backend on AppEngine.  The docs should help 
>>> explain 
>>> the product (and there are some samples on GitHub) -- we hope to 
>>> publish a 
>>> full end-to-end sample sometime within the next two weeks.
>>>
>>> Les
>>>
>>> On Wed, Jul 1, 2015 at 4:36 AM, Shruthi Sharat >> > wrote:
>>>
 Hi,

 I am working on Mobile application which has a Google App 
 Engine backend, now i am able to login with G+ and access the APIs 
 created 
 in backend with oAuth.

   How can I access my backend APIs by logging in with any other 
 social media platforms like facebook and twitter. How can i sync the 
 oAuth 
 of facebook and my Google App Engine APIs. 

 Help me in finding a solution for this.

 Thank You

 -- 
 You received this message because you are subscribed to the Google 
 Groups "Google App Engine" group.
 To unsubscribe from this group and stop receiving emails from it, 
 send an email to google-appengi...@googlegroups.com .
 To post to this group, send email to google-a...@googlegroups.com 
 .
 Visit this group at http://groups.google.com/group/google-appengine
 .
 To view this discussion on the web visit 
 https://g

[google-appengine] Re: how to setup my app engine app to send mail from my custom domain

[Anastasios Hatzis]

Patrice, I use the GAE email service to send mails from the app (it's just 
low traffic notifications). For doing this, I have setup Google Apps groups 
as senders, e.g. nore...@mydomain.com (Google Apps for Work customers with 
that domain). This works still great. But I think that this option is not 
mentioned anymore in the docs. Is this feature still supported for new apps 
or new email-accounts? Or does it only work for older apps?

On Friday, October 23, 2015 at 7:54:16 PM UTC+2, Patrice (Cloud Platform 
Support) wrote:
>
> Hi,
>
> From the link on the "learn more" in your error message, we specifically 
> state that you need to have a gmail or Google domain, so you won't be able 
> to use mydomai.com to do this. YOu will need to either use the 
> appspotmail, or a gmail. 
>
> To use the email you want, I would suggest using something like SendGrid 
> , which will provide more flexibility in that 
> regards.
>
> Cheers!
>
> On Thursday, October 22, 2015 at 11:58:08 PM UTC-4, Naresh Pokuri wrote:
>>
>> I am porting my application on Google App Engine with my personal gmail 
>> account. As part of application I have to send email to my application 
>> users regarding their content. I am able to send mails using my personal 
>> account(i.e myma...@gmail.com ). But that's not good. I 
>> want to send mails from supp...@mydomai.com/i...@mydomain.com to 
>> represent my company. For that I bought a domain from godaddy.com and 
>> registered with third party mail provider zoho.com.
>>
>> Now I am trying to add sup...@mydomai.com  to my 
>> application under Settings.
>> Then I get
>> "Failed to add authorized senders An error occurred trying to add 
>> authorized senders. This may occur if you lack sufficient privileges. Learn 
>> more 
>> 
>> "
>>
>> Then I try to add sup...@mydomai.com  to my owners list 
>> under application permissions section. Even now I am not able to add him to 
>> permitted email list.
>>
>> How can a user with email sup...@mydomai.com , which is not 
>> managed by gmail can accept the invitation.
>>
>> I have no clue what I can do now? Please guide me
>>
>
-- 
HATZIS Edelstahlbearbeitung GmbH
Hojen 2
87490 Haldenwang (Allgäu)
Germany

Handelsregister Kempten (Allgäu): HRB 4204
Geschäftsführer: Paulos Hatzis, Charalampos Hatzis
Umsatzsteuer-Identifikationsnummer: DE 128791802
GLN: 42 504331  6

http://www.hatzis.de/

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/ed9cc467-c34f-4475-9e3d-fc38f0bef464%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Failed to load resource: the server responded with a status of 404 (OK)

[Patrice (Cloud Platform Support)]

Hi Sandeep,

Normally such questions about what to do when something doesn't work are in 
a better position to be asked and answered on Stack Overflow 
. We do monitor the posts related to the tags we 
sponsor and answer there, on top of the community itself being very active.

In any case, to properly answer your question, we would need:

- Your logs (as they apparently didn't pass through first time) 
- The endpoints code
- The exact command used to deploy.

If you ask your stack question with all that information, someone (possibly 
someone from support, or the community) will be happy to provide further 
help.

Cheers!

 Friday, October 23, 2015 at 2:40:00 AM UTC-4, Sandeep Jain wrote:

> i am  facing some problem on google endpoint.
> i have  created project in google endpoint with  java API and angularjs 
> and database which is google datastore. 
> i have uploaded the project on google cloud server and getting an error.
>
> localhost:/_ah/api/explorer is ok.
>
> But when I deploy, nothing changes.
>
> https://myhscheckup-1106.appspot.com/_ah/api/explorer is not working.
>
> we are getting below error -
> Failed to load resource: the server responded with a status of 404 (OK)
>  
> https://myhscheckup-1106.appspot.com/_ah/api/discovery/v1/apis/hsendpoint/v1/rest?fields=rootUrl%2CservicePath%2Cresources%2Cparameters%2Cmethods&pp=0
> i have also attached a log file so please go through it and let me know if 
> there is an error asap. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/10d1fb55-68f2-43bc-9656-841b6a81bfcb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: how to setup my app engine app to send mail from my custom domain

[Patrice (Cloud Platform Support)]

Hi,

>From the link on the "learn more" in your error message, we specifically 
state that you need to have a gmail or Google domain, so you won't be able 
to use mydomai.com to do this. YOu will need to either use the appspotmail, 
or a gmail. 

To use the email you want, I would suggest using something like SendGrid 
, which will provide more flexibility in that regards.

Cheers!

On Thursday, October 22, 2015 at 11:58:08 PM UTC-4, Naresh Pokuri wrote:
>
> I am porting my application on Google App Engine with my personal gmail 
> account. As part of application I have to send email to my application 
> users regarding their content. I am able to send mails using my personal 
> account(i.e mymai...@gmail.com). But that's not good. I want to send 
> mails from supp...@mydomai.com/i...@mydomain.com to represent my company. 
> For that I bought a domain from godaddy.com and registered with third 
> party mail provider zoho.com.
>
> Now I am trying to add supp...@mydomai.com to my application under 
> Settings.
> Then I get
> "Failed to add authorized senders An error occurred trying to add 
> authorized senders. This may occur if you lack sufficient privileges. Learn 
> more 
> 
> "
>
> Then I try to add supp...@mydomai.com to my owners list under application 
> permissions section. Even now I am not able to add him to permitted email 
> list.
>
> How can a user with email supp...@mydomai.com, which is not managed by 
> gmail can accept the invitation.
>
> I have no clue what I can do now? Please guide me
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/dcdd999a-94dc-484f-8e86-c77b6e2870fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Google Groups limits

[Patrice (Cloud Platform Support)]

Hi,

I have to say, I'm not familiar enough with the Google Apps administration 
side of things to help you here.

If I'm not mistaken though, having a SuperAdmin account for Google Apps, 
you should have access to create a support case directly no? This will link 
you up with the appropriate specialists who know the product and will be 
able to help you here.

Let me know if this doesn't help, I'll be happy to hunt down other venues 
for you.

Cheers!

On Thursday, October 22, 2015 at 1:36:27 PM UTC-4, Serve The Cocc wrote:
>
> Hello App Engine gurus,
> First of all- i am sorry for barging on this tech forum... i am not a 
> cloud guru- just a Google Group for Work (Non-Profit) Super Admin tapping 
> for a solutions that i have not found on the lay sites.
> I am managing an organization made up of about 100 users/members; spread 
> across about 25 Groups.
> The org is Non-profit with non-paid volunteers so i was looking for a no 
> cost solution if possible.
>  
> 1. i am using nested groups which has limitations. example; user1 is 
> in group A. Group A is nested in Group B. The fact that user1 is not a 
> direct member of Group B is causing several issues mainly with permissions 
> and Group B not showing in the user's 'My Group' area. there are other 
> issues but these are the main ones. i really want to avoid adding 
> user1 directly in Group B , would rather use nested groups to minimize 
> errors because the users are dynamic and will be moved around periodically.
> 2. i am looking for a Google Group app for my users to easily access and 
> use on their mobile devices(phones). 
>  
> would appreciate a robust solution that i can incorporate to facilitate 
> this need.
> Thanks much
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/be2e563c-92cd-44c8-a9a1-523df51ea8bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: I am not able to quantify what are App Engine Frontend Instance Hours

['Alex Martelli' via Google App Engine]

On Fri, Oct 23, 2015 at 6:43 AM, Ryan (Cloud Platform Support) <
rbruy...@google.com> wrote:

> Anastasios hit the nail square on the head. Idle instances are instance
> that are doing nothing. When a request comes in it will start a 4th. With
> your setup it will be more aggressive in shutting down the spare instances
> that's all. They are meant to have instances always ready to take requests.
> Depending on the language you are using it is more or less important to
> have these. Python is the fastest to boot, so you don't need as many, Java
> is the longest to boot so you need more idle.
>

When I last measured this for myself (a while ago) I noticed that Go was
fastest (for a "hello world" app responding to a request starting from a
state with zero instances running). Considering that Go is the only GAE
runtime where applications are compiled to native-code binaries (no JVM or
Python or PHP interpreter needs to spin up), this did not surprise me.
However, you're better off doing your own measurements, since things may
change.


> If Anastasios assumptions are correct and there are no end user
> interactions you can leave it at 0 and just take a slight hit when you send
> your first request.
>
> It looks like you want to only ever have 3 instances. You should use
> Manual scaling with instances set to 3.
> If you have no need for instant response you can use basic
> with max_instances set to 3, this will scale down the number when they are
> not needed but cap at 3.
>

That's what I've been doing, personally, for modules that don't respond to
users' requests, but rather only do "background processing" (cron and/or
queued tasks) -- I forego autoscaling for those modules, in favor of basic
or manual scaling, since for those modules I can usually predict the load
reasonably well in advance and don't need to provision for sudden surges as
I have to for modules that respond to users' requests (and besides having
more predictability and no real fear of sudden surges, as you notice, Ryan,
such "background processing" modules usually don't suffer much if some
extra latency is added, as "user-facing" modules would).

To choose between basic and manual scaling, consider that you're charged
for (wall-clock elapsed time) 15 minutes *after* an instance is done
serving its last request. So, it's not very useful if an instance goes idle
(i.e is done serving its last request), shuts down say 5 minutes after
going idle, then another 5 minutes later another request comes and a new
instance has to spin up for the new request: you're still being charged for
the instance that's shut down (and will be charged for a further 5 minutes
more) PLUS the new one being spun up. It would have been a bit cheaper, as
well as a bit faster, in this case, to just not let the first instance shut
down -- i.e, to use manual scaling (where no automatic spin-up nor
shut-down happens) rather than basic scaling.

I'm mentioning this because the OP wrote about a cron job running every 5
minutes (although in that case it's not entirely clear how many instances
will be needed to serve all those jobs).


Alex


>
> @Anastasios be careful using daily budget to limit the number of
> instances. When you reach the cap it will stop all traffic request and not
> do any work until it resets.
>
> On Friday, October 23, 2015 at 1:41:00 AM UTC-4, Naresh Pokuri wrote:
>>
>> I have started my GAE app with *Auto-scaling* having *min-idle-instances
>> 3*, each with 1GB RAM and 2.4GHz processor(i.e *F4_1G*). And I have a
>> cron job which runs on every 5 minutes. With this setup keeping application
>> idle for one day should equal to 72 instance hours. But I see that it
>> already reached 428 instance hours. So, I am clueless here how GAE
>> calculates instance hours, with this alone I can keep my budget in control.
>> Can someone help me in this *instance hours*
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-appengine+unsubscr...@googlegroups.com.
> To post to this group, send email to google-appengine@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-appengine.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-appengine/27eb091a-b210-4d1c-86e2-1d38a143ac65%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/g

[google-appengine] Re: referer spam, relentless!

[Ryan (Cloud Platform Support)]

Salutations EJ,

I will need some more information to investigate this. In the mean time 301 
redirect your site to a file that can be cached. This way it will stop 
hammering your site. I will then need the following information (feel free 
to private message me with the details):

App ID:
Full URL that is being hit:
Log sample showing the hits, more the better.

On Thursday, October 22, 2015 at 7:32:37 PM UTC-4, EJ Kowal wrote:
>
> I have an website I recently ported to GAE and we have an spammer hitting 
> us every .10 of a second with back_url=(url) spam. Looks like the previous 
> site may have been misconfigured.
>
> Anyways, the spammer is hitting the same page over and over again, just 
> with different back_url=(url). I checked and they are using quite an 
> extensive list of IP's so the Ddos won't work. Any other suggestions? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/3e3bc2b2-c080-4db8-91db-88e0590ef465%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: I am not able to quantify what are App Engine Frontend Instance Hours

[Ryan (Cloud Platform Support)]

Anastasios hit the nail square on the head. Idle instances are instance 
that are doing nothing. When a request comes in it will start a 4th. With 
your setup it will be more aggressive in shutting down the spare instances 
that's all. They are meant to have instances always ready to take requests. 
Depending on the language you are using it is more or less important to 
have these. Python is the fastest to boot, so you don't need as many, Java 
is the longest to boot so you need more idle. If Anastasios assumptions are 
correct and there are no end user interactions you can leave it at 0 and 
just take a slight hit when you send your first request.

It looks like you want to only ever have 3 instances. You should use Manual 
scaling with instances set to 3.
If you have no need for instant response you can use basic 
with max_instances set to 3, this will scale down the number when they are 
not needed but cap at 3.

@Anastasios be careful using daily budget to limit the number of instances. 
When you reach the cap it will stop all traffic request and not do any work 
until it resets.

On Friday, October 23, 2015 at 1:41:00 AM UTC-4, Naresh Pokuri wrote:
>
> I have started my GAE app with *Auto-scaling* having *min-idle-instances 
> 3*, each with 1GB RAM and 2.4GHz processor(i.e *F4_1G*). And I have a 
> cron job which runs on every 5 minutes. With this setup keeping application 
> idle for one day should equal to 72 instance hours. But I see that it 
> already reached 428 instance hours. So, I am clueless here how GAE 
> calculates instance hours, with this alone I can keep my budget in control. 
> Can someone help me in this *instance hours*
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/27eb091a-b210-4d1c-86e2-1d38a143ac65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: I am not able to quantify what are App Engine Frontend Instance Hours

[Naresh Pokuri]

Thanks Anastasios Hatzis for the detailed explanation. That threw some 
light on my understanding of Instance Hours. You said,


If I understand idle instances correctly, that means that at least three 
> instances will be running that do nothing. If your cron-job starts, a 
> fourth instance would be started, so there will always be three idle 
> instances, plus the instances that are processing the cron-jobs.
>

Does that mean that min-idle-instances are always idle ? And won't take up 
any requests to process ? Why will a fourth instance be started when we 
already have three idle instances ? What does min-idle-instances signify ?

Now, we have enabled max-idle-instances to 3 as well. So, the instance 
hours with this setup {min-idle: 3, max-idle: 3}, should come up to 24 * 3 
* 6 = 432  F1 Instance Hours, And I should not be charged for any dynamic 
instances that will spin up beyond 3. Correct me if I am wrong.

Thank you very much.




On Friday, 23 October 2015 16:37:31 UTC+5:30, Anastasios Hatzis wrote:
>
> There might be more than one reason for this:
>
> From the documentation 
> 
> :
>>
>> *Important:* When you are billed for instance hours, you will not see 
>> any instance classes in your billing line items. Instead, you will see the 
>> appropriate multiple of instance hours. For example, if you use an F4 
>> instance for one hour, you do not see "F4" listed, but you will see billing 
>> for four instance hours at the F1 rate.
>
>
> So in your case with *F4_1G*, which costs 0.30$ per hour, rather than 
> 0.05$ per hour of a *B1* instance, this is factor 6. The billings always 
> show instance hours as B1, so 72 hours F4_1G translates to 432 hours B1. 
> The same applies to the billing dashboard.
>
> However, there can indeed be more instances with your setup, than the 3 
> you want, hence the "min-idle-instances":
>
> From the docs :
>
>> Auto scaling modules use dynamic instances - but if you specify a number, 
>> N, of minimum idle instances, the first N instances will be resident, and 
>> additional dynamic instances will be created as necessary.
>
>
> For example, if your cron job handler has an error and exponentially adds 
> tasks into the queue. Or if tasks run much longer than expected, so 
> additional instances are needed to handle the overlapping tasks. With your 
> setup it is possible that you end up with more than three *F4_1G* 
> instances during peeks, but never will fall below three. If I understand 
> idle instances correctly, that means that at least three instances will be 
> running that do nothing. If your cron-job starts, a fourth instance would 
> be started, so there will always be three idle instances, plus the 
> instances that are processing the cron-jobs.
>
> You can limit this, either in auto-scaling (e.g. max_idle_instances 
> ),
>  
> or kind of ultimately, you can set a daily budget. I recommend to check 
> again the dashboard from your screenshot, just to be certain what the 
> reason is for your instance hours. There is the "Summary" button on top. 
> Toggle it to "Instances" diagram and switch the period to 1 day, for 
> example, just to see if there were any peeks with more than 3 instances.
>
> As far as I understand, you have no user-facing features in your app (or 
> this module), but only cron-jobs? Do you expect to have always same load 
> for your app or module? Maybe it doesn't matter if your cron-jobs have to 
> wait a few additional seconds until a new instance is spawned (just in 
> case). If the answers are all yes, you could consider basic-scaling with 
> max-instances set to 3.  If you set the idle_timeout to something longer 
> than your 5 minute cron-job schedule (e.g. 10m), the setup could work fine 
> for your use-case.
>
>
> On Friday, October 23, 2015 at 7:41:00 AM UTC+2, Naresh Pokuri wrote:
>>
>> I have started my GAE app with *Auto-scaling* having *min-idle-instances 
>> 3*, each with 1GB RAM and 2.4GHz processor(i.e *F4_1G*). And I have a 
>> cron job which runs on every 5 minutes. With this setup keeping application 
>> idle for one day should equal to 72 instance hours. But I see that it 
>> already reached 428 instance hours. So, I am clueless here how GAE 
>> calculates instance hours, with this alone I can keep my budget in control. 
>> Can someone help me in this *instance hours*
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.googl

[google-appengine] Re: I am not able to quantify what are App Engine Frontend Instance Hours

[Anastasios Hatzis]

There might be more than one reason for this:

>From the documentation 
:
>
> *Important:* When you are billed for instance hours, you will not see any 
> instance classes in your billing line items. Instead, you will see the 
> appropriate multiple of instance hours. For example, if you use an F4 
> instance for one hour, you do not see "F4" listed, but you will see billing 
> for four instance hours at the F1 rate.


So in your case with *F4_1G*, which costs 0.30$ per hour, rather than 0.05$ 
per hour of a *B1* instance, this is factor 6. The billings always show 
instance hours as B1, so 72 hours F4_1G translates to 432 hours B1. The 
same applies to the billing dashboard.

However, there can indeed be more instances with your setup, than the 3 you 
want, hence the "min-idle-instances":

>From the docs :

> Auto scaling modules use dynamic instances - but if you specify a number, 
> N, of minimum idle instances, the first N instances will be resident, and 
> additional dynamic instances will be created as necessary.


For example, if your cron job handler has an error and exponentially adds 
tasks into the queue. Or if tasks run much longer than expected, so 
additional instances are needed to handle the overlapping tasks. With your 
setup it is possible that you end up with more than three *F4_1G* instances 
during peeks, but never will fall below three. If I understand idle 
instances correctly, that means that at least three instances will be 
running that do nothing. If your cron-job starts, a fourth instance would 
be started, so there will always be three idle instances, plus the 
instances that are processing the cron-jobs.

You can limit this, either in auto-scaling (e.g. max_idle_instances 
),
 
or kind of ultimately, you can set a daily budget. I recommend to check 
again the dashboard from your screenshot, just to be certain what the 
reason is for your instance hours. There is the "Summary" button on top. 
Toggle it to "Instances" diagram and switch the period to 1 day, for 
example, just to see if there were any peeks with more than 3 instances.

As far as I understand, you have no user-facing features in your app (or 
this module), but only cron-jobs? Do you expect to have always same load 
for your app or module? Maybe it doesn't matter if your cron-jobs have to 
wait a few additional seconds until a new instance is spawned (just in 
case). If the answers are all yes, you could consider basic-scaling with 
max-instances set to 3.  If you set the idle_timeout to something longer 
than your 5 minute cron-job schedule (e.g. 10m), the setup could work fine 
for your use-case.


On Friday, October 23, 2015 at 7:41:00 AM UTC+2, Naresh Pokuri wrote:
>
> I have started my GAE app with *Auto-scaling* having *min-idle-instances 
> 3*, each with 1GB RAM and 2.4GHz processor(i.e *F4_1G*). And I have a 
> cron job which runs on every 5 minutes. With this setup keeping application 
> idle for one day should equal to 72 instance hours. But I see that it 
> already reached 428 instance hours. So, I am clueless here how GAE 
> calculates instance hours, with this alone I can keep my budget in control. 
> Can someone help me in this *instance hours*
>

-- 
HATZIS Edelstahlbearbeitung GmbH
Hojen 2
87490 Haldenwang (Allgäu)
Germany

Handelsregister Kempten (Allgäu): HRB 4204
Geschäftsführer: Paulos Hatzis, Charalampos Hatzis
Umsatzsteuer-Identifikationsnummer: DE 128791802
GLN: 42 504331  6

http://www.hatzis.de/

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/db24953e-1a1b-4b9c-9c4e-97d0e7e050a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: Stop Backend from new Admin Console

[Alejandro Gonzalez]

Thanks Patrice, thats awesome as it's exactly what I am looking for :D

The feature to "suspend" a module from spinning new instances is not so 
important if the modules do it automatically when it is not the default 
version.

Cheers!




El miércoles, 21 de octubre de 2015, 18:59:45 (UTC+2), Patrice (Cloud 
Platform Support) escribió:
>
> Hi Alejandro,
>
> Yes, definitely. You are 100% right here. I honestly got confused with the 
> backends question and went back to the old "backends" mentality, where the 
> instance was simply UP. Now, if it's not the default one, you are right, 
> App Engine won't keep on spinning them up. 
>
> Completely sorry for the wrong message there. I just quickly tested to 
> make sure this is the correct behavior, and the non-default module doesn't 
> kick up instances if there is no traffic. Now if there is traffic, it will 
> obviously change, but that is a whole other story.
>
> Cheers!
>
> On Wednesday, October 21, 2015 at 5:06:33 AM UTC-4, Alejandro Gonzalez 
> wrote:
>>
>> Hello,
>>
>> Reading the modules documentation i found a phrase that confuses me...
>>
>> min-idle-instances:
>>> The minimum number of idle instances that App Engine should maintain for 
>>> this version. Only applies to the default version of a module, since other 
>>> versions are not expected to receive significant traffic.
>>
>>
>>
>> So...
>>
>>1. I have a module version configured with min-idle-instances = 2 (2 
>>resident instances)
>>2. This version is not the default version for the module
>>3. This version is not receiving any request
>>
>> The 2 min-idle-instances will still apply to this "non default" module 
>> version? If i shutdown the 2 resident instances for that module version... 
>> they are going start again? (please note that i don't have a ready to 
>> deploy project with modules thus i can't test this by myself)
>>
>>
>> Thanks.
>>
>>
>> Thanks again.
>>
>>
>>
>>
>> El martes, 20 de octubre de 2015, 18:22:42 (UTC+2), Patrice (Cloud 
>> Platform Support) escribió:
>>>
>>> Very welcome :).
>>>
>>> I forgot to tell you that, if you believe this is a Feature that could 
>>> potentially benefit a lot of users, you are more than welcome to post it 
>>> here  as a 
>>> Feature Request so we can look into adding that behavior to the console.
>>>
>>> Cheers!
>>>
>>> On Tuesday, October 20, 2015 at 12:17:03 PM UTC-4, Alejandro Gonzalez 
>>> wrote:

 Thanks for your clarification Patrice.


 El martes, 20 de octubre de 2015, 18:13:26 (UTC+2), Patrice (Cloud 
 Platform Support) escribió:
>
> Hi Alejandro,
>
> Unfortunately, for your second question, no it cannot be done. From 
> the console you can only delete a version, not suspend it, so you won't 
> be 
> able to deactivate a version, short of completely removing it. You can 
> upload the same application, but with a different app.yaml, so the 
> instances aren't up, but you won't be able to "suspend" the version from 
> the console.
>
> Cheers
>
> On Tuesday, October 20, 2015 at 12:07:57 PM UTC-4, Christian F. Howes 
> wrote:
>>
>> bummer.  I don't have an answer for you - the last of my backends 
>> were 
>> deleted a couple of months ago. 
>>
>> I hear you on how changes cascade! 
>>
>> christian 
>>
>> On 10/20/15 02:11, Alejandro Gonzalez wrote: 
>> > I know backends are deprecated... forget about them (thinking in 
>> the 
>> > refactor i need to made and how it will affect to my CI flow, build 
>> scripts 
>> > and app versioning approach...) 
>> > 
>> > If I have a module deployed to a version (v1-2-54-back) and 
>> configured to 
>> > have 2 resident instances: can i stop that module version from the 
>> admin 
>> > console so it does not start more instances (without deleting it so 
>> i can 
>> > re-activate it)? 
>> > 
>> > Maybe i need to rethink my versioning and deployment processes a 
>> bit... i 
>> > will start another specific thread for this if i need advice (I bet 
>> i will 
>> > :D) 
>> > 
>> > 
>> > El martes, 20 de octubre de 2015, 1:35:10 (UTC+2), Christian F. 
>> Howes 
>> > escribió: 
>> >> 
>> >> note that i was reminded by google support recently that backends 
>> are a 
>> >> deprecated feature, so i bet managing them in the new console 
>> won't ever 
>> >> come. :( 
>> >> 
>> >> the modules with manual scaling ("B1" etc. instance classes) work 
>> great, 
>> >> and we have found them much easier to manage (the logs are 
>> separated from 
>> >> other modules, the deployments are much smoother for us). 
>> >> 
>> >> Good luck! 
>> >> 
>> >> Christian 
>> >> 
>> >> On Monday, October 19, 2015 at 2:49:21 AM UTC-7, Alejandro 
>> Gonzalez wrote: 
>>