The lion’s share of performance topics you should worry about with GCF have to do directly with response time. However, there’s two other topics you should consider, Cold boot time (which I covered previously) and deployment time.
This is exactly the issue that Rain Mages ran into.
Rain Mages has a robust backend system with lots of small microservices, each one powered by GCF. They ran into a development issue, in that deployment times were starting to give them the blues. Now, if you don’t do a lot of deployments, this might not be a problem, but when you’re doing 200 or so code deployments a day, you can end up wasting 40 hours of time, each day, just doing deployments.
Deployment & the dependency cache
One of the first things we noticed, is that each GCF for each microservice had a different set of dependencies. This is normally fine, but we noticed that when dependencies where shared, they weren’t even using the same versions.
The issue with this is that as versions of each dependency varies across deployments, cache misses much more likely, meaning that deployment times will be larger.
To test how much of an improvement this is, we consolidated all the GCF dependencies for all their microservicese to the max usable version of each dependency, and made everyone use the same versions. Therefore, these versions are expected to be present in the dependency cache, making deployments faster.
Deploy performance & extra data
Secondly, I noticed a few interesting statistics with respect to their deployment setup. It looked like they were shipping a lot of extra files (around 600 or so configs files and data files). They would then fetch these files from the local GCS bucket that their GCF stuff was deployed into.
While this very much streamlines the micro-function setup, and ensures that each push has a locally-true view of the universe, it was killing their deployment times. To show how much, we put together a similar test, and showed off the difference in the results:
The fix is in!
For Rain Mages, two things became apparent in these tests. Firstly, they needed to unify their dependencies around the most popular versions for their services, and secondly, moving uploads of their config data to a parallel process to a unique GCS bucket would save them a lot of deployment time headaches.