Caché and Ensemble 2017.1 field test now available

I am pleased to announce the field test of Caché and Ensemble 2017.1, including many new improvements.

The product team at InterSystems looks forward to your participation in the field test and feedback over the coming months.

Some of the more significant changes in 2017.1 are the new RESTful APIs for iKnow, FIPS 140-2 validated cryptography for Caché database encryption, and improved DocBook search.  As always there are a host of scalability and performance improvements to the core database and SQL.  And hundreds of smaller improvements and corrections.  Summary of the Caché changes can be found HERE and the Ensemble changes HERE.

Product management will be posting greater details how you can use the improvements in 2017.1 to improve your Caché and Ensemble based solutions.   Look for these postings in the next few days.

You can download the latest field test of 2017.1 HERE.

We welcome all your comments, questions and feedback.

  • + 6
  • 0
  • 734
  • 2

Attached documents

Comments

Re: Caché Release Notes, Other Items of Note: Lightweight SQL Profile

What is that?

Here are some details from the developer:

Customers need to know which SQL queries play a significant role in their application performance. To help in this determination we now keep statistics against all SQL in the SQL statement index. The information we record is:

1) Number of times a query is run

2) Total time spent in query

3) Standard deviation of the query

4) Date we first recorded seeing a query run

Although this information is deliberately sparse to keep the overhead of recording it as small as possible (both in time taken and space used) it should allow the following sorts of questions to be asked:

1) Which query is run more often than any other?

2) Show me the slowest 5 queries?

3) Which queries take more total time than any others?

4) A developer has a way to optimize query X, is the overhead of this query actually significant on my live system?

All this data is stored in the SQL statement index and viewable in the system management portal under the statement index pages as additional columns. Users can sort by these columns as needed. The data will be recorded by all SQL including cached queries via xDBC, or server side cached queries e.g. %SQL.Statement or embedded SQL. We default to always recording this information on any query except for a 'natural' query which is one we can determine at compile time is so simple that the overhead of recording statistics will effect performance and there is no advantage to keeping statistics as the query is already very simple. A good example of a natural query is 'select Name from Table where %ID=?' as this query does not involve any looping and any index references. We will mark these queries as natural in the SQL statement index. The exact definition of what is a natural query may be extended in the future. By default we will now collection statistics on all non-natural queries. To minimize the overhead of this collection the data is stored in the partition and only written to a global either when the process terminates or after a set period of time. This writing of the data to a global does not directly update the statistics in the SQL statement index, but a background process periodically wakes up which aggregates the data from any processes into the global statistics. This means the data in the SQL statement index does not include the most recent activity, but by deferring this update we avoid blocking the process doing useful SQL work.

The statistics are SQL mapped from the INFORMATION.SCHEMA.STATEMENTS class so you can perform SQL queries against this to view the statistics as well as viewing them in the SMP.