[PHP] What is 'database call count' exactly?

We noticed the high ‘database call counts’ in our system up to 5000.
But looking at the trace details we see the database call only up to/around 100.
Is this a completely different metric?


1 Like

Hey there @reinhard ,

Thanks for reaching out to the New Relic Community! I think I might be able to shed some light on your situation through the docs I’ve included below.

https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/nrql-query-tutorials/nrql-segment-your-data-buckets/#example

I hope this helps!

Cheers

Hi @eschwall ,
Thanks for your reply!
I don’t find the answer to my question in that documentation.
I did not use the bucket feature, and I don’t understand how it would help me.

I’m just curious what does the ‘database call count’ mean? That 1 transaction is calling the database 5000 times is impossible, so I cannot believe it.

Hi @reinhard

Apologies for the delay in getting to this!

I have gone ahead looped in out PHP agents team to help support this one, its a little out of scope. They will reach out here on this post with their findings.

Should you have any updates or new findings in relation to this issue please do let us know.

Hello @reinhard,

To clarify, DatabaseCallCount is directly defined as “The number of database calls made by this transaction.” You can see this in the New Relic data dictionary at the following link:

The way that New Relic works, we track each of your transactions and then record some aggregated detail data to Insights about each transaction. This is compared to the APM product where we report aggregated metrics each minute about each transaction. Here is a link to the documentation we have regarding the default attributes available on the Transaction attributes:

Can you provide us with a permalink to where you think the database call count is incorrect? To create a permalink to any page within the New Relic user interface, click the “Share” button next to the Time Picker just below your username at the top right of the page. This will show us the exact page and time period that you are observing.

For example comparing:
https://onenr.io/07wkvZvdGQL
and
https://onenr.io/0vwB1l19bQp

Hi @reinhard

Thank you for providing those links, they are sure to be helpful!

Currently @tlugo is not in office ( due to timezone differences ), so I will loop in another PHP team expert here to have a look!

Thank you for your patience!

Hi @reinhard,

Thanks for that update! I looked at both of those permalinks but unfortunately it doesn’t appear to show correlating data. The first permalink took me to a transaction trace for your radio-cloud03status application, but the second took me to a query for a specific request.uri value that doesn’t appear to have any results. Is there a different query that shows this transactional/database data as incorrect that you can share?

ah, it looks like the data cannot be found anymore if it is too old. Is the data only available for some days?
Here are new examples:
https://onenr.io/0BQ1A2r5bQx
vs
https://onenr.io/0ZQWb5emxjW

Hi @reinhard

I hope you are well.

Thanks for the update here, the links will be sure to provide great insight here. It is a little out of my scope but I will loop in an engineer here to help.

Please note the engineer will reach out here.

Should you have any new updates please do reach out, or should have any follow up questions.

Hi @reinhard ,

My sincerest apologies, but (as I imagine you already know) the links you provided is too old. The retention in your account only allows the data to be there for 8 days, so can you please provide us with fresh links showing the problem? Our team is already aware of the problem but just need a new concrete example to work with.

Thank you!

Sure:
https://onenr.io/07wkvYzgrQL
and
https://onenr.io/0EjOeKWpAw6

less than 100 calls vs 6065 calls

Hi @reinhard !

I was able to speak to our development team regarding this problem and they noticed what I did, which is that this transaction has a very large amount of spans. On the PHP agent’s side, we downsample to avoid sending all of the data to our collector servers. The queried trace is showing the database call count correctly. However, we are unable to store and send that much data and therefore the more detailed transaction page is only showing the queries for which it has data.

There is a specific value in your newrelic.ini configuration file (specifically span_events.max_samples_stored) that allows you to increase the amount of data the agent is able to save and send. It defaults to 2K spans and has a max of 10K. However, increasing this can have a large effect on ingest and agent performance (specifically when not using infinite tracing). I believe setting this value will allow you to see more than what is being gathered by default.

For more information about this setting, please see the following link:

OK, Thanks!
We will look into it again!

Hi @reinhard im glad @tlugo was able to help here. Please do let us know if you need further support here.