Emmanuel

That is a big question and it depends on what you are doing.

If you are writing SQL queries, then look at the SQL performance statistics in INFORMATION_SCHEMA.STATEMENT_DAILY_STATS. 

If you are using an interoperability production, look at the activity and volume statistics.

For general database activity, you could use ^SystemPerformance as described, but with that you have to process the data with an extra tool and it is difficult to interpret. I suggest you enable the History Monitor. It will give you almost everything ^SystemPerformance gives you, with a fraction of the effort. You just look at the DB and CPU stats with SQL.

Lorenzo

Two guesses - 

First, check that the task 'Update SQL query statistics' is running and that you have waited long enough for the task to run.

Second, are you looking at a query that is embedded SQL in a 'deployed' class (meaning there is no source code)? There is a problem with statistics for deployed classes, but I don't remember if it matches your situation exactly.

The page in the management portal is limited and was never intended to meet the needs of everyone.

The intention was to make the information readily accessible from SQL, so people could use their favorite reporting tool or dashboard product. 

Wrapping SQL in a restful service would be straightforward and there is an example of a REST service that calls a query and generates the JSON for Grafana here 

Dave

And just to add some more details

I am using the SimpleJson plugin from Grafana Labs as my data source -   https://grafana.com/plugins/grafana-simple-json-datasource

The url http://localhost:52777/syshistory/ for that points to the REST application that is implemented by the page I included. When setting up the data source, I only checked ‘Basic Auth’ and added the username and password under ‘Basic Auth Details’.

dave

When i wrote this, i was quoting an already old test report. While it may or may not have been correct at the time, it is certainly not relevant or useful today with modern hardware.

The proper story today is that there is a fixed CPU overhead per byte encrypted or decrypted.  

The fractional overhead of a single core  would be approximately the data read or write rate in bytes per second divided by the CPU clock speed in hertz.

So on my current 2.8 GHz laptop reading 100 MBs would take roughly 3.6% of one core. Different chips and data rates would give different results. 

you would need to give a lot more detail about  CustomEDI.SQLSIUInRequest and its ImportFromString method for anyone to tell you what is going wrong. What data type does the ImportFromString return, and have you tested it in isolation?

I think the 'normal' way to do this, would be to leave the HL7 message as an object. You could use a business process that extracts only the fields that are needed to retrieve the patient ID and send that to the SQL database. But i suspect you already have external logic that processes a whole serialized HL7 message.

https://community.intersystems.com/post/apm-finding-expensive-parts-your...

also describes how to locate expensive points in your code.

In this case you are talking about tiny differences. If this is executed millions of times in  a common path  that is executed frequently you might want to  think about it, but  for most applications it is not an issue. Those SQL queries that don't use an index are the killers.

based on feedback, i have updated the document to warn against activating other monitor classes without checking first. Some will affect the performance of your system, but the ones I describe in the article are safe.

"There are a number of of other classes but don't be tempted to activate them without testing first. Some use PERFMON and are not suitable for running on a live system."

Dave

The meaning is documented 

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

including information about when the alerts are sent and how often the sensors are sampled.

Changing he values is documented:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

you have to navigate the options in 

do ^%SYSMONMGR

to edit the sensors. You have to then provide CPUusage (case sensitive) as the sensor you want to edit.

If you have a general query this is a great place to ask.

But if you have an operational problem you should pick up the phone (or your preferred technology)  and call InterSystems support. The people there enjoy answering questions and getting systems back in action.

617-621-0700 in the US but if you google InterSystems Support i think you will get what you need worldwide.

John

the only place i can think of it being used in the pull down menu for selecting a target in a send. It only offers you configuration items that exist in the production you choose. If you haven't specified a production it lists everything it can find and gives you a big red warning.

There is nothing to stop you typing in a target that isn't on the list

dave