One of our ongoing goals is to make sure you can slice up and drill down on your data in any way you need to. Just creating a web app already gives you a lot of ways to do this: we pull out your URLs, controller/actions, apps, and more. Internally, though, there can be even more. To help you tackle that challenge, we’re excited to annouce a new feature: Partitions. Partitions are a new type of filter that let you tell us what category a particular request falls into, right from inside your code.

What is this meant for? To help you get started, here’s a few places we’ve found partitions to be useful:

Logged in vs. Logged out

First and foremost, Tracelytics shows you how fast the various contents of your page load, which directly translates to your user’s experience on your site. Frequently, though, not all users see the same content; specifically, logged in users tend to have a much richer experience. That richness comes at a price, though.

If your pages typically load in 0.8 seconds, is that because everybody is getting a good experience, or is your barebones landing page hiding the fact that most registered users are actually waiting 4 seconds before all their content shows up? With partitions, you can divide up your traffic and make sure that even both groups are seeing the kind of performance you want them to see.  (And it’s true–this is important. Just ask Stack Overflow.)

API vs. Browser vs. Googlebot

As businesses grow, they frequently run more than just a website. There will be internal tools for both business and development, an API for 3rd-party developers, a beta site for adventurous customers, and more–often all running from the same codebase on the same hardware. Code and infrastructure reuse is great, but it can make it difficult to understand what kind of experience each group has.

With partitions, you can tag where each request is coming from. That information is propagated to all layers within that app, so even if only your load-balancer knows that the incoming request is for the beta site, you can still view all database queries the beta site incurred (and hopefully see that they’re better than what you have in prod right now!). Similarly, web crawlers tend to disproportionately visit slow or uninteresting corners of your web site. By separating these requests into their own partition, you can attack and optimize the pages that are slow for real, live users. Partitioning like this ensures that no matter how your users visit your site, they’ll get a fast, consistent experience.

Semantic Separation

One of the larger chunks of code we have is our trace-processing pipeline. In order to ensure that all our customers get their data in realtime, it’s important that all the machinery is well-behaved and consistent. All of our customers run different stacks and configurations, and, as a result, their traces turn out a little bit differently. We use partitions to categorize each trace by its dominant layer type, e.g. SQL, services, or profiles. Since we process each of these types in separate modules, they each perform a little differently. Being able to split them up in the same way that we think and talk about them makes debugging and performance tuning that much faster.

Get to it!

Hopefully by now, you’ve thought of some way you could divide up your own apps with partitions. If so, head on over to the partition documentation, get started, and let us know how it goes!