On Monday, 6 November 2017 10:54:14 UTC+11, Ani Hatzis wrote:
>
>
>
> On Sunday, 5 November 2017 23:59:42 UTC+1, Peter Camilleri wrote:
>>
>> Last night at 12:00 I recorded this from the billing page
>>
>> App Engine Flex Instance Core Hours 8,640.47 Minute $9.92
>>
>> And this morning I recorded this
>>
>> App Engine Flex Instance Core Hours 191.79 Hour $13.22
>>
>> 8600 minutes is about 144 hours
>>
>> 191 - 144 = 47 hours of time used in 9 hours. So it looks like I've got 5 
>> apps running simultaneously which is eating up my credit.
>>
>
> OK. In case that there is really just one instance running all the time 
> (as your Versions page suggested), it might be that you have the instance 
> configure with multiple vCPUs (cores). Flexible environment is charged per 
> core hour (see doc here 
> <https://cloud.google.com/appengine/pricing#flexible-environment-instances>). 
> So, an instance with four cores running for one (real) hour will be charged 
> with 4 core hours. In the 9 hours you had ~ $3.3 costs for core hours, ~ 
> $0.37/core hour, depending on your region, we talk about an instance with 
> maybe 8 cores. Check your app.yaml file for a "resources" configuration 
> (see doc here 
> <https://cloud.google.com/appengine/docs/flexible/python/configuring-your-app-with-app-yaml#resource-settings>).
>  
> What does the "cpu" value say? If you want to can copy-paste the section 
> here.
>

Nothing of the sort. I was just following the cloudsql tutorial (
https://github.com/GoogleCloudPlatform/python-docs-samples/tree/master/appengine/flexible/cloudsql
)



runtime: python

env: flex

entrypoint: gunicorn -b :$PORT main:app


#[START env]

env_variables:

    # Replace user, password, database, and instance connection name with 
the values obtained

    # when configuring your Cloud SQL instance.

    SQLALCHEMY_DATABASE_URI: >-

      mysql+pymysql://sensitive-data-removed

#[END env]



#[START cloudsql_settings]

# Replace project and instance with the values obtained  when configuring 
your

# Cloud SQL instance.

beta_settings:

    cloud_sql_instances: sensitive-data-removed

#[END cloudsql_settings]


But I will try specifying the resources. Does this look ok?


manual_scaling:

  instances: 1

resources:

  cpu: 2

  memory_gb: 1.4

  disk_size_gb: 10


 

>  
>
>>
>> My versions page looks like this. Could this be where my credit is going?
>>
>>
>> <https://lh3.googleusercontent.com/-Yl59lWZNOgk/Wf-Lksx79xI/AAAAAAAAV5E/V9ED6YsESJgcV9OqF8QwWGjZZgIhBvHAgCLcBGAs/s1600/Screen%2BShot%2B2017-11-06%2Bat%2B9.06.02%2Bam.png>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> I thought that these instances do not consume resources if they are 
>> stopped? The lower 6 instances are also created when I execute "gcloud app 
>> deploy app.yaml" with no extra arguments. So should I instead be specifying 
>> a specific version each time I deploy (e.g. dev or prod) so that I am 
>> overwriting the current instance and not creating a new instance each time? 
>>
> However these are all inside of my "default" service, so I thought they 
>> would naturally be overwriting the last deployed version naturally.
>>
>>
> You are right, stopped instances don't consume resources (at least not for 
> the VM). What you are seeing in this page are all versions of the app that 
> have been deployed until now. When you deploy a version, by default, 
> instance of an older version is stopped. A new instance spins up and gets 
> all the traffic. So your current version is in the first line, handling 
> 100% of the traffic, running 1 instance. Below are the older versions (no 
> traffic and no instances).
>
> Older versions are kept, so you have the opportunity to roll-back to an 
> older version in case your new version shows elevated errors. You can 
> delete versions that you don't need anymore though, but in that case you 
> can't just roll-back to them.
>
>
>> Python flexible environment (although this is only because the standard 
>> environment tutorials using CloudSQL wouldnt work out of the box.)
>>
>
> Have you followed these Cloud SQL instructions of standard environment 
> here <https://cloud.google.com/appengine/docs/standard/python/cloud-sql/>? 
> If you had no other reason for flexible, I would recommend the standard 
> environment. Albeit there are many good reasons for choosing flexible 
> environment over standard, flexible needs more administrative overhead than 
> standard. In standard it's easier to focus on your own code.
>

Yea I followed that tutorial and my database couldnt connect to cloudsql. I 
tried the flexible equivalent tutorial and it worked fine, so I continued 
with flexible (I thought the pricing difference would be negligible for the 
moment, and I just wanted to get my app development going. I'm not fussed 
over a several dollars a month, but I dont want to be haemorrhaging 60$).

I'll give standard another go.
 

>  
>
>>
>> No worries. I quickly checked and found my instance was not using the 
>> cheapest instance type. So that cut my SQL costs by about 80% right there.
>>
>
> Great! And add budgets & alerts to your billing account. It's really 
> helpful to stay alerted about potential config errors wreaking havocs to 
> your credits during your first steps.
>
>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/320990ad-f1fe-400e-a07c-b7baf593db20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to