Blog

The fastest query is one you never execute.

The premise is that one of the slowest parts of starting up an application isn’t starting the application itself, it’s loading the initial application state. This can become a problem when you’re loading many copies of your application on many servers, especially you’re in the cloud and paying for CPU cycles. In that article, a commenter proposes reading application start up state from a serialized blob; basically a chunk of memory written to disk. The trick is that the serialized blob is stored in cache rather than on disk or in a database. Sometimes you need to hit disk in order to refresh the cache, but the general idea is that all configuration info is stored in a single binary object that can be quickly read and used to start up an application to a known good state.

Caching for More Than Start Up Times

Once you start caching application start state, it’s natural to look for more places to introduce additional caching. Remember, the fastest query is the one that you never execute.

Most people already know that they can add caching to their application to improve performance and get around slower parts of the system. There are a number of well understood design patterns that focus around caching and its place in software architecture. A lot of people don’t take this one step further and use caching as a trick to avoid down time when they roll out updates.

You might be thinking “Wait a minute, doesn’t my database/SAN/operating system have some kind of cache?” You’re right, it does. Storage cache is your last line of defense before reading from disk. Why not cache things in your application and skip the network hit?

So what happens when you need to update the application? In the past you probably scheduled an outage in the middle of the night. Or maybe you performed rolling outages from server to server and then slowly brought features online across groups of servers. However you did it, it’s complicated, requires down time, and you need to have a rollback plan; rollbacks on large databases can take a lot of time.

What if instead of just caching configuration to avoid slow start up, you start caching all data (or as much as can fit into memory)? You’re doing that already, right? Why mention it again?

If you’re caching data already, it seems logical that your application is written with multiple tiers. Those tiers are probably divided out by application or by service. If so, there’s a lot of logical separation between different features and functionality. You might even be calling a read/write API as if it were a service provided by a third party. This is a perfect example of how you can cache your reads and avoid hitting lower layers of the application; the front end never needs to know that anything exists apart from the services that provide data.

If you can cache data at the service level, you can theoretically take your back end systems offline for maintenance and bring them back online with minimal disruption to your users. Ideally, there would be no disruption. You could queue up modifications during your maintenance window and then commit them to the database once the updated database, services, or features are back online.

The Beauty of Isolation

By isolating features and layers from each other, you can make your applications more responsive. Rather than relying on servers to respond quickly during application start times, you can make it possible to load binary configuration data from cache. Frequently run queries can be served even faster by caching results in memory. Down times can even be avoided by caching reads and writes during the maintenance window. Of course, caching writes can be difficult. You can start by caching reads and keep your application up most of your users; it’s better than shutting everyone out completely.

To learn more about caching on Windows, read up on AppFabric Cache. On the *nix side of things, there’s the tried and true memcache. More novel and exotic solutions exist, but AppFabric Cache and memcache are great places to get started.

What does PLF stand for, you ask?  I’ll start by introducing my partners in PLF order:

Peschka, Jeremiah (Blog – @Peschkaj) – I met Jeremiah a couple of years ago at a PASS Summit.  We were both wandering the hallways, and we ended up spending hours together talking about databases, data mining, and Apple gear.  We tried starting a business project together, had a good time, but it fell to pieces shortly before go-live.

Little, Kendra (Blog – @Kendra_Little) – I first met Kendra last year in Miami, preparing to head out on the first SQLCruise.  She got off to a bad start by flying into the wrong airport, and then had a family emergency that kept her from boarding the boat with us.  Later, I got the chance to work with her on a contentious Microsoft project that involved opinionated yelling.

Ford, Tim (Blog – @SQLAgentMan) – I met Tim a few years ago when I spoke at the Michigan PASS chapter he ran.  We started SQLCruise together, and along the way, we’ve had all kinds of things go wrong.  Cruise lines have screwed us, swag vendors have missed their promises, and life has thrown us all kinds of crazy curveballs.

I’ve failed with all three of them, and they’re great partners.

I’ve long said that I won’t recommend anyone as a consultant unless I’ve seen them in action on a server-down situation.  You learn a lot about a person when you fail with them.  You learn how they handle pressure, politics, and personalities.

As I’ve gone through life, I’ve made little notes about people who are amazing in failure situations. Tim, Kendra, and Jeremiah have been truly enjoyable people to work with even during the darkest situations.  Starting a business is hard as hell – most small businesses fail – and even the successful ones have tough challenges along the way.  I want partners who do more than just live and learn; I want partners who can laugh and learn.

We’re building a new consulting and training company.

The best way to describe it is from our consulting offerings page:

Brent Ozar PLF is a boutique consulting firm focused on understanding your environment and strategy. We partner with you to objectively identify pain points and develop solutions that align to your business goals.  Your experience comes first; we share our knowledge and expertise to help you.

That isn’t just marketing fluff – we really live it.  You see us giving away our knowledge for free at user groups, conferences, and webcasts.  You read our blogs.  You get answers from us on #SQLHelp.  We love sharing, learning, and solving problems, and we’ve all been doing it for businesses for years.

Jeremiah, Kendra, and I will be focusing on SQL Server, storage, virtualization, and the cloud.  Tim has been running SQLCruise for a while, and he’ll continue to focus on that.  He’s not quitting his day job – SQLCruise is a part-time thing, but we’re merging that into the new company.  SQLCruise has been a fun success, and we’ve got more innovative events coming soon for training and problem solving.

The company name is Brent Ozar PLF, and BrentOzar.com is the home base for our company, but we’re all equal partners in this.  Jeremiah, Kendra, Tim, and I will be writing technical blog posts here, hosting webcasts, and more.  We first thought about starting a new company name and a new web site, but after talking with our genius branding consultants, we realized BrentOzar.com made the most sense.  I’ve been blogging here for a decade, it’s got great search engine visibility, and I steadily get new clients here month after month.  Why start a new site and struggle building a new brand from scratch when we’ve already got one?

Next up, I’m tagging Tim Ford to talk about why he’s taking part.

At the Connections conference in Orlando, I had the opportunity to sit down with Richard Campbell, host of RunAs Radio, and talk shop.  I love conversations with Richard because he gets to travel and touch all kinds of cool systems, so as a result we end up jumping off-topic all over the place, talking about the neat stuff we’ve seen and the way it changes IT jobs.

In the podcast, we talked about the two extremes of IT: seems like half the people are excited to cut their costs by going to the cloud, and the other half are excited to raise their performance by switching to solid state drives.  No matter which way you want to go, databases (and database performance tuning) techniques are changing.

Head over to RunAsRadio.com and listen.  Enjoy!

Copy, paste, copy, paste. I just love plagiarizing helping the community.

Tom LaRock challenged us to write an eleven word blog post and I couldn’t resist resurrecting an old theme.  John Dunleavy (who plagiarized my posts last year) emailed me a while back to say he’d like to meet me at the DevConnections conference in Orlando and buy me a drink to apologize.  I really admired his guts.  It takes huge drawers to make that kind of request, and I respect that.  We went out to dinner and had a wonderful time.

A wise man once told me that carrying a grudge is like swallowing poison and hoping the other guy dies.  Another wise man told me that DevConnections feels like the PASS Summit, only without the backstage drama.  Life is short enough as it is.  We can’t succeed by forcing others around us to fail – and in fact, it’s often the opposite.  I feel most successful when those around me succeed.  I don’t want any event, blogger, presenter, or consultant to fail.  I want us all to find our niche, our moral compass, and our happiness.

Life is a never-ending journey of learning our own lessons and helping those around us learn theirs.  If people had given up on me when I made my first mistakes, I’d be homeless right now.  I’m only here because my bosses and my peers saw enough value in me to be patient with my problems and help me get better.  Every time that I can pay that forward is a success.

What can you do to mend a fence today and help someone become a success?