Lessons learned from building Demand Side Platform
LESSONS LEARNED FROM
Bartosz Bogacki <firstname.lastname@example.org>
CTO, CODER, ROCK CLIMBER
• Chief Technology Ofﬁcer at Bidlab
• IT Director at
• Software Architect / Project
Manager at Wolters Kluwer
• ﬁnd out more (if you care):
BIDLAB IS A DSP
DSP stands for Demand Side Platform
• There’s a lot of crappy blog posts
• There’s a lot of ugly shortcuts on Stack Overﬂow
• There’s a lot of poor quality comparison tests (comparing
apples and oranges, incorrectly measuring or not isolating
measured feature properly)
• Others have often different environment / data / usage
scenarios than you!
TOOLS AND LIBRARIES
• Learn how it works …really!
• Learn what are the constraints and weak points
• Check if it is supported by active community
• Use open source or pay for support (startup
programs are for kamikaze)
USE CLOUD HOSTING BUT…
• Don’t get locked-in !!
• Always test machine performance (often)
• Monitor CPU steal time
• Decide what you need (IO / memory / cpu / storage)
• Be aware of roundtrip time
• If you deliver static content - do it from cache (like varnish)
• Use in memory database (like memcached or redis) to
cache data or subresults for your application
• Use lightweight inapp cache to lower communication cost
(like Guava Loading Cache)
• Have a strategy for feeding and invalidating of your cache at
THINK ABOUT HA
• Have a HA plan, but do not implement, until you
really need it. Until then - do (and test) backups! :)
• Most of technologies that you would use have
recommended fault-tolerance solution, do not
invent it by yourself !
GATHER PRODUCTION DATA
TEST YOUR CONCEPTS &TOOLS
DON’T ASSUME !
• Use real, production data if you can!
• The real life is often more complex than you
thought at the beginning (typos, data consistency,
DO FUNCTIONAL &
• Use great tools, don’t invent
• apache-benchmark (ab)
PROFILE EARLY & OFTEN
• Know your application from
the execution perspective
• Know your hotspots
• VisualVM !!