Hi there. Fortunately for the ML team, the Previews team kept a detailed cost breakdown for different preview types - including on the fly generation cost, async generation cost, and cost to serve a preview. Our ballpark accounted for some of the varying costs, though the difference is not significant.
Hi joosters, thanks for the question. It is always a good practice to ask if we are solving the right problem.
The decision to prewarm is ultimately a product decision to give users a better experience across the many surfaces where they encounter file previews. There are limitations to how fast previews can be generated on the fly, even under optimal conditions (unlimited top-of-the-line hardware, max of 1 request at a time). For instance, optimal on-the-fly preview generation for more expensive files (say, a video that is an hour long or a gigapixel image) can add 10s of seconds to tti -- not good from a user perspective!
Given this constraint, we wanted to optimize where we spend on the preview generation infrastructure without negatively impacting the user experience. We chose to do this with a combination of heuristics and the ML solution described in the article.
Hi mehrdada. In the article, we discuss how to evaluate tradeoffs of ML projects. One of these tradeoffs is cost of development and deployment vs. cost of not developing a solution. In our particular case, the tradeoff made sense.
Hi setib, great question. The original idea to use heuristics for preview cost reduction came out of a Hack Week project. This led to an initial brainstorm meeting between the ML team and the Previews team about what this might look like as a full-fledged ML product.
From the beginning the ML team's focus was on providing measurable impact to our Previews stakeholders. One thing that helped us collaborate effectively was being transparent about the process and unknowns of ML (which are different from the constraints of non-ML software engineering). We openly shared our process and results, including experimental outcomes that did not work as well as planned and that we did not roll into production. We also worked closely with Previews to define rollout, monitoring, and maintenance processes that would reduce ops load on their side and provide clear escalation paths should something unexpected happen. Consistent and clear communication helps build trust.
On their side, the Previews team has been an amazing ML partner, and it was a joy to work with them.
Hi folks, author here. I am very excited to share this post about how we use machine learning at Dropbox to optimize our document preview generation process. Enjoy!
I'll be online for the next hour or so; happy to answer any questions about ML at Dropbox.