DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Join us tomorrow at 1 PM EST: "3-Step Approach to Comprehensive Runtime Application Security"
Save your seat
  1. DZone
  2. Data Engineering
  3. Databases
  4. New Profiling and Monitoring in Couchbase Server 5.0 Preview

New Profiling and Monitoring in Couchbase Server 5.0 Preview

For those using Couchbase, the latest preview build is up! Check out the latest N1QL enhancements in action and improvements for monitoring.

Matthew Groves user avatar by
Matthew Groves
·
Feb. 25, 17 · Tutorial
Like (1)
Save
Tweet
Share
4.44K Views

Join the DZone community and get the full member experience.

Join For Free

N1QL query monitoring and profiling updates are just some of the goodness you can find in February’s developer preview release of Couchbase Server 5.0.0.

Go download the February 5.0.0 developer release of Couchbase Server today, click the “Developer” tab, and check it out. You still have time to give us some feedback before the official release.

As always, keep in mind that I’m writing this article on early builds, and some things may change in minor ways by the time you get the release.

What Is Profiling and Monitoring For?

When I’m writing N1QL queries, I need to be able to understand how well (or how badly) my query (and my cluster) is performing in order to make improvements and diagnose issues.

With this latest developer version of Couchbase Server 5.0, some new tools have been added to your N1QL-writing toolbox.

N1QL Writing Review

First, some review.

There are multiple ways for a developer to execute N1QL queries.

  • Use the SDK of your choice.
  • Use the cbq command line tool.
  • Use the Query Workbench in Couchbase Web Console
  • Use the REST API N1QL endpoints

In this post, I’ll be mainly using Query Workbench.

There are two system catalogs that are already available to you in Couchbase Server 4.5 that I’ll be talking about today.

  • system:active_request – This catalog lists all the currently executing active requests or queries. You can execute the N1QL query SELECT * FROM system:active_requests; and it will list all those results.
  • system:completed_requests – This catalog lists all the recent completed requests (that have run longer than some threshold of time, default of 1 second). You can execute SELECT * FROM system:completed_requests; and it will list these queries.

New to N1QL: META().plan

Both active_requests and completed_requests return not only the original N1QL query text, but also related information: request time, request id, execution time, scan consistency, and so on. This can be useful information. Here’s an example that looks at a simple query (select * from travel-sample) while it’s running by executing select * from system:active_requests;

{
    "active_requests":{
        "clientContextID":"805f519d-0ffb-4adf-bd19-15238c95900a",
        "elapsedTime":"645.4333ms",
        "executionTime":"645.4333ms",
        "node":"10.0.75.1",
        "phaseCounts":{
            "fetch":6672,
            "primaryScan":7171
        },
        "phaseOperators":{
            "fetch":1,
            "primaryScan":1
        },
        "phaseTimes":{
            "authorize":"500.3µs",
            "fetch":"365.7758ms",
            "parse":"500µs",
            "primaryScan":"107.3891ms"
        },
        "requestId":"80787238-f4cb-4d2d-999f-7faff9b081e4",
        "requestTime":"2017-02-10 09:06:18.3526802 -0500 EST",
        "scanConsistency":"unbounded",
        "state":"running",
        "statement":"select * from `travel-sample`;"
    }
}


First, I want to point out that phaseTimes is a new addition to the results. It’s a quick and dirty way to get a sense of the query cost without looking at the whole profile. It gives you the overall cost of each request phase without going into detail of each operator. In the above example, for instance, you can see that parse took 500µs and primaryScan took 107.3891ms. This might be enough information for you to go on without diving into META().plan.

However, with the new META().plan, you can get very detailed information about the query plan. This time, I’ll execute SELECT *, META().plan FROM system:active_requests;

[
    {
        "active_requests":{
            "clientContextID":"75f0f401-6e87-48ae-bca8-d7f39a6d029f",
            "elapsedTime":"1.4232754s",
            "executionTime":"1.4232754s",
            "node":"10.0.75.1",
            "phaseCounts":{
                "fetch":12816,
                "primaryScan":13231
            },
            "phaseOperators":{
                "fetch":1,
                "primaryScan":1
            },
            "phaseTimes":{
                "authorize":"998.7µs",
                "fetch":"620.704ms",
                "primaryScan":"48.0042ms"
            },
            "requestId":"42f50724-6893-479a-bac0-98ebb1595380",
            "requestTime":"2017-02-15 14:44:23.8560282 -0500 EST",
            "scanConsistency":"unbounded",
            "state":"running",
            "statement":"select * from `travel-sample`;"
        },
        "plan":{
            "#operator":"Sequence",
            "#stats":{
                "#phaseSwitches":1,
                "kernTime":"1.4232754s",
                "state":"kernel"
            },
            "~children":[
                {
                    "#operator":"Authorize",
                    "#stats":{
                        "#phaseSwitches":3,
                        "kernTime":"1.4222767s",
                        "servTime":"998.7µs",
                        "state":"kernel"
                    },
                    "privileges":{
                        "default:travel-sample":1
                    },
                    "~child":{
                        "#operator":"Sequence",
                        "#stats":{
                            "#phaseSwitches":1,
                            "kernTime":"1.4222767s",
                            "state":"kernel"
                        },
                        "~children":[
                            {
                                "#operator":"PrimaryScan",
                                "#stats":{
                                    "#itemsOut":13329,
                                    "#phaseSwitches":53319,
                                    "execTime":"26.0024ms",
                                    "kernTime":"1.3742725s",
                                    "servTime":"22.0018ms",
                                    "state":"kernel"
                                },
                                "index":"def_primary",
                                "keyspace":"travel-sample",
                                "namespace":"default",
                                "using":"gsi"
                            },
                            {
                                "#operator":"Fetch",
                                "#stats":{
                                    "#itemsIn":12817,
                                    "#itemsOut":12304,
                                    "#phaseSwitches":50293,
                                    "execTime":"18.5117ms",
                                    "kernTime":"787.9722ms",
                                    "servTime":"615.7928ms",
                                    "state":"services"
                                },
                                "keyspace":"travel-sample",
                                "namespace":"default"
                            },
                            {
                                "#operator":"Sequence",
                                "#stats":{
                                    "#phaseSwitches":1,
                                    "kernTime":"1.4222767s",
                                    "state":"kernel"
                                },
                                "~children":[
                                    {
                                        "#operator":"InitialProject",
                                        "#stats":{
                                            "#itemsIn":11849,
                                            "#itemsOut":11848,
                                            "#phaseSwitches":47395,
                                            "execTime":"5.4964ms",
                                            "kernTime":"1.4167803s",
                                            "state":"kernel"
                                        },
                                        "result_terms":[
                                            {
                                                "expr":"self",
                                                "star":true
                                            }
                                        ]
                                    },
                                    {
                                        "#operator":"FinalProject",
                                        "#stats":{
                                            "#itemsIn":11336,
                                            "#itemsOut":11335,
                                            "#phaseSwitches":45343,
                                            "execTime":"6.5002ms",
                                            "kernTime":"1.4157765s",
                                            "state":"kernel"
                                        }
                                    }
                                ]
                            }
                        ]
                    }
                },
                {
                    "#operator":"Stream",
                    "#stats":{
                        "#itemsIn":10824,
                        "#itemsOut":10823,
                        "#phaseSwitches":21649,
                        "kernTime":"1.4232754s",
                        "state":"kernel"
                    }
                }
            ]
        }
    },
    ...
]


The above output comes from the Query Workbench.

Note the new “plan” part. It contains a tree of operators that combine to execute the N1QL query. The root operator is a Sequence, which itself has a collection of child operators like Authorize, PrimaryScan, Fetch, and possibly even more Sequences.

Enabling the Profile Feature

To get this information when using cbq or the REST API, you’ll need to turn on the “profile” feature.

You can do this in cbq by entering set -profile timings; and then running your query.

You can also do this with the REST API on a per request basis (using the /query/serviceendpoint and passing a querystring parameter of profile=timings, for instance).

You can turn on the setting for the entire node by making a POST request to http://localhost:8093/admin/settings, using Basic authentication, and a JSON body like:

{
    "completed-limit":4000,
    "completed-threshold":1000,
    "controls":false,
    "cpuprofile":"",
    "debug":false,
    "keep-alive-length":16384,
    "loglevel":"INFO",
    "max-parallelism":1,
    "memprofile":"",
    "pipeline-batch":16,
    "pipeline-cap":512,
    "pretty":true,
    "profile":"timings",
    "request-size-cap":67108864,
    "scan-cap":0,
    "servicers":32,
    "timeout":0
}


Notice the profile setting. It was previously set to off, but I set it to “timings”.

You may not want to do that, especially on nodes being used by other people and programs, because it will affect other queries running on the node. It’s better to do this on a per-request basis.

It’s also what Query Workbench does by default.

Using the Query Workbench

There’s a lot of information in META().plan about how the plan is executed. Personally, I prefer to look at a simplified graphical version of it in Query Workbench by clicking the “Plan” icon (which I briefly mentioned in a previous post about the new Couchbase Web Console UI).


Let’s look at a slightly more complex example. For this exercise, I’m using the travel-sample bucket, but I have removed one of the indexes (DROP INDEX travel-sample.def_sourceairport;).

I then execute a N1QL query to find flights between San Francisco and Miami:

SELECT r.id, a.name, s.flight, s.utc, r.sourceairport, r.destinationairport, r.equipment
FROM `travel-sample` r
UNNEST r.schedule s
JOIN `travel-sample` a ON KEYS r.airlineid
WHERE r.sourceairport = 'SFO'
AND r.destinationairport = 'MIA'
AND s.day = 0
ORDER BY a.name;


Executing this query (on my single-node local machine) takes about 10 seconds. That’s definitely not an acceptible amount of time, so let’s look at the plan to see what the problem might be (I broke it into two lines so the screenshots will fit in the blog post).


Looking at that plan, it seems like the costliest parts of the query are the Filter and the Join. JOIN operations work on keys, so they should normally be very quick. But it looks like there are a lot of documents being joined.

The Filter (the WHERE part of the query) is also taking a lot of time. It’s looking at the sourceairport and destinationairport fields. Looking elsewhere in the plan, I see that there is a PrimaryScan. This should be a red flag when you are trying to write performant queries. PrimaryScan means that the query couldn’t find an index other than the primary index. This is roughly the equivalent of a “table scan” in relational database terms. (You may want to drop the primary index so that these issues get bubbled-up faster, but that’s a topic for another time).

Let’s add an index on the sourceairport field and see if that helps.

CREATE INDEX `def_sourceairport` ON `travel-sample`(`sourceairport`);


Now, running the same query as above, I get the following plan:

This query took ~100ms (on my single-node local machine) which is much more acceptable. The Filter and the Join still take up a large percentage of the time, but thanks to the IndexScan replacing the PrimaryScan, there are many fewer documents that those operators have to deal with. Perhaps the query could be improved even more with an additional index on the destinationairport field.

Beyond Tweaking Queries

The answer to performance problems is not always in tweaking queries. Sometimes you might need to add more nodes to your cluster to address the underlying problem.

Look at the PrimaryScan information in META().plan. Here’s a snippet:

"~children": [
  {
    "#operator": "PrimaryScan",
    "#stats": {
      "#itemsOut": 13329,
      "#phaseSwitches": 53319,
      "execTime": "26.0024ms",
      "kernTime": "1.3742725s",
      "servTime": "22.0018ms",
      "state": "kernel"
    },
    "index": "def_primary",
    "keyspace": "travel-sample",
    "namespace": "default",
    "using": "gsi"
  }, ... ]


The servTime value indicates how much time is spent by the Query service to wait on the Key/Value data storage. If the servTime is very high, but there is a small number of documents being processed, that indicates that the indexer (or the key/value service) can’t keep up. Perhaps they have too much load coming from somewhere else. So this means that something weird is running someplace else or that your cluster is trying to handle too much load. Might be time to add some more nodes.

Similarly, the kernTime is how much time is spent waiting on other N1QL routines. This might mean that something else downstream in the query plan has a problem, or that the query node is overrun with requests and are having to wait a lot.

We Want Your Feedback!

The new META().plan functionality and the new Plan UI combine in Couchbase Server 5.0 to improve the N1QL writing and profiling process.

Stay tuned to the Couchbase Blog for information about what’s coming in the next developer build.

Interested in trying out some of these new features? Download Couchbase Server 5.0 today!

We want feedback! Developer releases are coming every month, so you have a chance to make a difference in what we are building.

Bugs: If you find a bug (something that is broken or doesn’t work how you’d expect), please file an issue in our JIRA system at issues.couchbase.com or submit a question on the Couchbase Forums. Or, contact me with a description of the issue. I would be happy to help you or submit the bug for you (my Couchbase handlers high-five me every time I submit a good bug).

Feedback: Let me know what you think. Something you don’t like? Something you really like? Something missing? Now you can give feedback directly from within the Couchbase Web Console. Look for the icon at the bottom right of the screen.

Couchbase Server Database Relational database

Published at DZone with permission of Matthew Groves, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Visual Network Mapping Your K8s Clusters To Assess Performance
  • A Real-Time Supply Chain Control Tower Powered by Kafka
  • Promises, Thenables, and Lazy-Evaluation: What, Why, How
  • Type Variance in Java and Kotlin

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: