
Performance and Usage at Instagram - cgredona
https://engineering.instagram.com/posts/193415561023919/performance-usage-at-instagram/
======
elithrar
> We saw app-wide impressions across all mobile platforms increase by 0.7%,
> and likes increase by 0.4%. This was driven by increases of impressions on
> all surfaces – for instance, “Explore Photos” impressions increased over 3%,
> and user profile scrolls increased 2.7%.

I'm curious about this: was it A/B tested? Those figures are so small that
they could just be seasonal or organic growth, the side effect of other things
(events, weather, etc) that lead to increased engagement in general, and so
on.

The technical improvements look great, but attributing them directly to
increased user engagement seems a little too fuzzy.

~~~
mikeyk
Yep, these were all A/B tested and the results were statistically significant.

------
babayega2
Always glad to hear that a big platform uses Django as backend. I wonder if
the spec are still the same as the ones listed here? [http://instagram-
engineering.tumblr.com/post/13649370142/wha...](http://instagram-
engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-
instances)

~~~
mikeyk
We have a follow up to that post coming soon, stay tuned.

------
revelation
OOM errors dropping by 30% when you go from 20 comments to 5 doesn't sound
like "a job well done", that's more your initial hint to figure the hell out
why 20 comments cause memory issues.

~~~
sigmar
I agree. and I'm surprised they made a blog post about this. The details of
this seems more embarrassing than it is enlightening.

>Comment bundles are particularly heavy: They contain the comment text itself
as well as its id, timestamp, and author metadata (including profile picture).
... Generating profile picture URLs is a CPU-inefficient operation because we
must dynamically compute the correct CDN URL. The more comments we load, the
more profile picture URLs we need to generate.

Is it loading the entire profile picture with each comment? Not just a small
thumbnail?

~~~
sloanesturz
I think it's only loading the URL to the profile photo image, which is stored
in the CDN. Calculating the URL is, apparently, the slow factor. Maybe it
requires some type of cryptographic operation that results in heavy CPU use?

~~~
sigmar
>I think it's only loading the URL to the profile photo image

Sorry, by "it" I should have written "the client." I meant to suggest my
question of whether that is where their client OOM errors are coming from.

~~~
mikeyk
We load a small thumbnail; it's the extra memory allocated to strings that was
the main factor that helped when we reduced the # of comments sent down.

------
ex3ndr
Why not to use binary protocol? 20kb for just links and captions?

~~~
elithrar
JSON is easier (faster) to parse on their client apps.

~~~
pquerna
If you are building a new app, I'd really suggest checking out gRPC:

[http://www.grpc.io/](http://www.grpc.io/)

The combination of an HTTP/2 stack w/ protocol buffers and libraries in
everything you'd write a mobile app in is a powerful combo, and its a pretty
high development velocity environment.

~~~
elithrar
gRPC is great, but Instagram's client apps are web-based (using React now),
and consuming protobuf in JavaScript is unlikely to be faster (and definitely
not as convenient) vs. JSON.

Given the limited resources of a lot of Android devices, an extra
unmarshalling step would offset any wire-size reductions.

~~~
krashidov
Just to clarify, do you mean that all of their mobile apps are on react-native
now? Or just their web apps?

