We Keep Coding

Dash (Flask App) Runs so much faster on my local than on Azure App Services

I've deployed my Dash Flask app to my companies Azure environment through App Services. At first, the initial load time was taking forever so I upgraded to Basic Tier and turned on "Always On".
Now the initial load time is instant, but the interactivity response times via all of my call backs (drop down selections, filters, check boxes etc) are like 5x slower than how it behaves on my local.
Is there anything else that I can do under Basic Tier, or app services in general, to help speed things up?

How to migrate Google App Engine Project to Compute Engine completely?

We have been using Google App Engine for the backend services of a project which has been developed completely as a Gooogle App Engine Project.
Lately, the front end instances were consuming more than 60-70% of our project expense. Thus we decided to do away with it completely and migrate to Google Compute Engine instead.
Wanted to know if anyone has migrated their GAE project to GCE. I understand that GCE VMs could be dynamically spun up from within a GAE app, but we want to completely do away with GAE. (Source)
As a last option, I shall host a Django project and use GAE files as the controller for the web services.
However, wanted to know if there are other potentially easier options for moving GAE projects to GCE while keeping the datastore integration intact.
TIA

Unfortunately the uniqueness of the standard environment support for the application may make your migration quite difficult.
Take, for example, the significant differences just between the standard env and the flexible env (which, if you want, would be like an intermediary step towards total migration to GCE): Migrating Services from the Standard Environment to the Flexible Environment. To me they're practically different beasts.
To make matters worse the very thing you consider the most important in your migration - keeping the datastore integration intact - is also the most likely to stand against your migration.
That's because chances are that your app uses one of the dedicated client libraries, optimized for and only available to the standard environment GAE apps. If so - the migration effectively means re-designing the entire interaction with the datastore to make it use one of the more generic datastore libraries instead. Which means more than just translating API calls - there are conceptual and functional differences that would need to be addressed.
So the answer to the title question may very well be: redesign your app for GCE. Personally I'm unsure if GCE is overall more cost-effective - I still prefer the standard env GAE. Assuming at some point the costs go up enough to maybe re-consider, I'd:
take a closer look at the pricing and the current app costs breakdown, to see which components are the heavier ones: if the majority of the costs come, for example, from the datastore usage - I wouldn't expect a migration to GCE to significantly help
try to tune the app's config and/or code to reduce costs: for example if the instance hours represent the majority in the costs tuning the scalability configurations depending on the actual traffic patterns might lower the bill
estimate the costs for similar usage patterns but with the corresponding components available on GCE (and/or GAE flex)
if the respective components are also available on GAE flex I'd make some experiments using that instead of going full GCE (which would pretty much require the re-write first).
A gradual transition using the flexible environment as a stepping stone could reveal if the estimated costs savings aren't quite there, thus helping drop the whole transition before doing the entire re-write. And also could help with the re-write, in case the transition still remains a "go".
Update: There might be another solution to consider for reducing costs: running the existing GAE app code through AppScale (see also appscale) on a more cost-effective IaaS provider.

Using GAE instances and GCE VM mixed

I am building a news aggregator app, and the backend can be separated (mostly) in two logical parts:
Crawling, information extraction, parsing, clustering, storing...
Serving the user requests
What I would like to do is:
a) create a heavy Google Compute Engine VM Instance to do the crawling (since that isn't doable with a Google App Engine, because the instance RAM is relatively small)
b) create a google app engine group of instances to serve the client requests which are light-weight and don't require much computational power per request
Is this possible to mix the two, Google App Engine and Google Compute Engine?
Or do I need to make the instances group on my own via GCE?

Another option you should explore is App Engine Flexible. (disclaimer, I work at Google on App Engine)
We allow you to build an App Engine application that has multiple modules. Those modules will run on GCE virtual machines, which are managed by App Engine. We auto-scale, auto-provision, etc. Under the hood, we're actually provisioning a managed instance group and auto-scaler the same way you would with GCE (just no work). You can also customize the CPU+Memory on the machine we run your app.
That way, both your front end and back end can run in the same project. Check out:
https://cloud.google.com/appengine/docs/flexible/python/
Hope this helps!

Google app engine load balancing does not seem to be working well

I already read this:
google app engine load balancing
and saw the video in https://www.youtube.com/watch?v=QJp6hmASstQ.
I have a paid app with the follow configuration:
threadsafe: true
automatic_scaling:
min_idle_instances: 1
max_idle_instances: 4
max_pending_latency: 200ms
When I looked in the "instances" tab in the app's admin I see I have 2 dynamic servers working (im not referring to the resident in this question), one handles most of the traffic, and the other one, for more than 10 minutes, does not get almost anything (as you can see in the image). I also checked and the 10 apis which it did handle, were handled very fast and no other api kept it working for long time.
This details are from the most "silent" period of the day. but when we have a big traffic its getting worse, the latency is rising and apis which should run at around 100ms, run at around 800ms which is really bad for us.
Should i maybe configure the app differently? why the load balancing does not split the work if it has more than one server working?

what are the cost/perfomance advantages of using "golang" in GAE

In terms of the Quotas/Usage limits per instance, is there any considerable improvement/advantage when using golang in Google appengine GAE instead of other offered language that run within GAE like python, java,php or all of them behave the same?
Or basically any instance no matter the language in use, behave the same way and can handle barely the same amount of maximum requests/sec per instance considering that this concerns more to the "GAE load balancer" or infrastructure, rather than the used programming language, same logic could applied to the memory,cpu usage?

App Engine doesn't have explicit limits or restrictions that would apply only when using a specific language. However the languages and their technologies might imply certain limitations, for example a Java Virtual Machine instance by itself requires significantly more memory and has significantly higher startup time (even when warmup requests are enabled) than starting the built-in web server of Go, so in case of a Java instance less memory will remain for the webapp itself to allocate and use (for a specific plan/type and instance).
I don't have concrete measures to compare, but (in case of Go):
"Code is deployed in source form and compiled in the cloud... Go is the first true compiled language that runs on App Engine. Go on App Engine makes it possible to deploy efficient, CPU-intensive web applications". (source)
If you think about it, other languages at App Engine are all interpreted (including Java which is byte code interpreted by a Virtual Machine) while Go is compiled into and runs as platform dependent native code. This should already tell something about performance.
For a "case-study" check out the following blog post:
From zero to Go: launching on the Google homepage in 24 hours
This blog also contains some performance report of a real-world app used by millions:
This chart - taken directly from the App Engine dashboard - shows average request latency during launch. As you can see, even under load it never exceeds 60 ms, with a median latency of 32 milliseconds. This is wicked fast, considering that our request handler is doing image manipulation and encoding on the fly.
App Engine uses the web server that is included in the Go standard library to serve your app, so that also means you can easily port a Go web app to App Engine, and that you know exactly what to expect from the web server serving your app on App Engine.
Found Official time comparisions of Python, Java and Go
The App Engine System Status can be considered official and a good comparision base.
You can click on any cells belonging to a specific day and language, and you get detailed historical statistics for Static and Dynamic GET latency (both secure and unsecure), Error rates, CPU usage/latency. These statistics are measured on an instance that is already up and ready to serve.
Analysing it for the day of January 27, 2015 here are the conclusions for Go, Java and Python:
Dynamic latency is roughly the same for all
CPU latency (to compute the 33rd Fibonacci number) is best for Java, then Go and slowest is Python.
Static file serving time is roughly the same but Go is fastest.