
Azure Functions – Significant Improvements in HTTP Trigger Scaling - supergeek
https://www.azurefromthetrenches.com/azure-functions-significant-improvements-in-http-trigger-scaling/
======
dillondoyle
I'm in the middle of trying to move a very simple ETL-light script to Google
(want to use bigquery over redshift). The idea was to use Cloud Functions.

I have ran into scale problems very fast at Google and now am having to use
App Engine and add more complication which I don't have personal engineering
skill/capacity.

Google support first bumped me up to 12000 max queries per 100 seconds and
said that's the limit, but that's not close to enough. We have super bursty
traffic (webhooks that aren't concatenated from source).

Google then increased to 100,000 per 100 seconds after they claimed 12k was
maximum.

It's still not enough and I think their sampling might be funky because when I
look at the invocation/traffic graphs it doesn't align with the stated maximum
(still throws quota errors).

Kind of frustrating. The idea of stateless functions without worrying about
engineering is a dream! I don't get why Google can't get 'google scale' here.
In the past we've used Snowplow on AWS when we had engineering help but that's
a huge amount of work/engineering time. The actual accept POST, store to cloud
storage, insert to DB is less than 100 rows.

Response time is also pretty bad in the extreme cases. Even though I end the
response before processing data I still see 95%/99% spikes when bursting on
the far less bursty data source (as in only bursting to 10/second). Just today
for this function I got 3764ms 99%!

~~~
doh
I don't know your flow, but how about using a queue system to prevent the
bursts of data?

We're internally using pubsub (and nats) sending billions of messages every
day. We don't use the push mode as Spotify [0] but pull from the queue instead
which allows us to run on our pace.

We do write into bigquery (and citus) and each components is doing it on their
own pace based on what they're capable of process at the moment.

[0] [https://labs.spotify.com/2017/11/20/autoscaling-pub-sub-
cons...](https://labs.spotify.com/2017/11/20/autoscaling-pub-sub-consumers/)

~~~
dillondoyle
Pub Sub is the same quota hits (or +1 /connection). I could use pub sub but I
still have to accept the incoming POST before publishing a message.

~~~
dillondoyle
To be clearer it's same quota problem using cloud functions. Moving to
something without the same quota/scale problems like Compute Engine or just
DIY containers might make sense but then I'm back to a complicated system
(Snowplow) that we have in AWS that's too complicated for me alone

~~~
doh
Understood. I think there is a bit simpler setup that you could utilize, but
it does require a custom deployment on GCE.

Request -> load balancer -> auto scaled pubsub writer -> pubsub -> client
(write to BQ, ...)

If it doesn't have to be a post request, then you could just write into pubsub
directly. Pubsub has a wide support of libraries [0] so you could do it from
any language. Pubsub also scales well. We're sending in around 300k messages
per sec and have very few problems with it.

[0]
[https://cloud.google.com/pubsub/docs/reference/libraries](https://cloud.google.com/pubsub/docs/reference/libraries)

~~~
dillondoyle
Yup that's pretty much where I'm going although without pub/sub ideally. it's
marketing analytics so if a few inserts fail it doesn't matter. But might not
be able to get the 0 -> 1000s instant working without Google's abstraction
messaging in front (similar setup on AWS w. kinesis but it's too complicated
for me)

I did think about doing something like transforming the POST in AWS Lambda
(the emitter data is hosted there too) and transform into something I can
ingest direct into pub/sub.

I can't control the emitting data. if I did it would be a much easier problem,
each POST request contains very little data if there were multiple entries per
single POST it would solve most of my problems, instead of sending 5k tiny
JSON posts /sec lol

------
appdrag
Title should be: AWS Lambda still crush all competitors both for response time
and throughput

~~~
ec109685
Aren’t response time and throughout directly correlated with one another. If
the former drops, the latter will increase, right?

~~~
appdrag
Nop because the load is supposed to be spread over thousands of servers... Not
just one

------
joncrane
Is this the Azure equivalent of AWS Lambda?

What factors other than some specific affinity to Microsoft makes a company
choose Azure over AWS?

~~~
evfanknitram
Yes it is.

What do you mean by Microsoft-specific stuff? I run a bunch of stuff there.
When I started using these things their PaaS offerings were much more mature
than the AWS counterpart (since they focused more on IaaS).

~~~
viggity
We run all PaaS except for two very special case VMs. It is an effin' delight
not having to worry about security, maintenance, updates. I just deploy my
code (app services) and query my data (azure table storage, azure sql). Shit
just works. Every time I need to deal with the VMs I cringe.

------
mcintyre1994
I hope they figure out how to productise Python properly, because these
improvements on the margin while great don't really fix 30 second import times
for a single library which is the current state of Python function apps.
That's a Microsoft library too (pydocumentdb).

~~~
jeffhollan
We have some really cool stuff in the works in this area right now. An
entirely new and revamped Python worker. Send me a DM on Twitter and happy to
help (@jeffhollan)

~~~
mcintyre1994
Sent you a message :)

------
stagetao
charts would be better if lines were differing in color a bit more.

