September 13, 2013 at 16:38Profiler in MarkLogic Server
Profiling is a very important aspect when developing and supporting almost any application. No less this applies to databases. Especially with large amounts of information, the performance of queries to the data warehouse is very critical. As for query performance in MarkLogic Server and their profiling, we can say that these issues are one of the most important since the XQuery used in MarkLogic Server allows you to write not only very complex queries to the DB itself, but also quite complex applications.
MarkLogic Server has quite good profiling functionality presented in ten built-in functions. All of them are located in the namespace “http://marklogic.com/xdmp/profile“ and are accessible with the prefix “ prof: ”
This function is passed to XQuery as a text string whose performance is worth testing.
The return value for prof: eval is the sequence (, <result of executing XQuery>). The report contains fairly detailed information about XQuery execution.
Example
It is worth noting that XQuery passed in this way is in no way associated with the context in which prof: eval is executed . In order to pass parameters to debugged XQuery, you can use the $ vars parameter , which is a sequence of variables in the form (QName, <value>). Example
or so
If an error occurs while executing XQuery, prof: eval throws a PROF-PROFILEALLOW exception .
About the next function, we can say that it is similar to prof: eval, with the only exception that it receives not XQuery as a text string, but the path to the XQuery module.
The XQuery module does not have to be a library, it must be the “main” executable module. The path to the module resolves relative to the root of the application server. Otherwise, prof: invoke is completely analogous to prof: eval .
MarkLogic Server allows you to create profiles not only for XQuery passed in the prof: eval and prof: invoke function , but also for instructions located directly in the program module. Moreover, profiling is not tied to a specific program code, but to a request processed by the server. This allows you to debug not only the code in the current request, but also analyze any request knowing its ID and not interfering with the application code, which can be very useful in case of analyzing the application in the production environment.
In order to start collecting information about the execution, you need to call the function
Where $ request-id is the request identifier for which to start profiling.
You can get the ID of the current request using the xdmp: request () function .
In order to stop the collection of information you need to use the function
As follows from the foregoing, you can profile any code processed between calls to the prof: enable and prof: disable functions if profiling is performed for the current request, or between the times to which these functions were called if the analysis is not performed on the current request.
When trying to use the profiler, the following user rights are checked
“http://marklogic.com/xdmp/privileges/profile-my-requests” - to profile your requests
“http://marklogic.com/xdmp/privileges/profile-any- requests ” - to profile any requests
Of course, there is a small exception - for profiling the current request (the request for which there are profiling functions) special ghosts are not required, and “profile-my-requests” gives the right to profile all (except the current) requests of the current user.
To check if profiling is available for a specific request, you can use the function
In order to get the collected information about the execution of the request, use the function
Unlike prof: eval , which returns a report and the result of XQuery, the prof: report function returns only a report. Prof
example : report
Sometimes there is a need to delete the accumulated information and start reporting again, the function is used for this
The following function is similar to the prof: eval function , but unlike it, prof: value inherits the context when the specified XQuery is executed.
Inheriting context by prof: value function allows you to write such code
There are two more interesting features.
Where $ input is an XML document processed in an XSLT processor.
The name of these functions makes it clear that they are similar to the prof: eval and prof: invoke functions , but are used to profile XSLT, the processor of which the MarkLogic Server developers have so carefully built into their product.
MarkLogiс Server provides powerful tools for performance analysis. With this mechanism, you can create complex profilers for a variety of tasks. At the same time, MarkLogiс Server has a graphical profiler in the integrated console, which makes the analysis process simpler and more convenient for small tasks and in the development process.
MarkLogic Server has quite good profiling functionality presented in ten built-in functions. All of them are located in the namespace “http://marklogic.com/xdmp/profile“ and are accessible with the prefix “ prof: ”
prof:eval(
$xquery as xs:string,
[$vars as item()*],
[$options as node()?]
) as item()*This function is passed to XQuery as a text string whose performance is worth testing.
prof:eval( "1 + 1" )The return value for prof: eval is the sequence (
Example
PT0S 2013-09-13T00:00:00.000+04:00 6.0-3 13367197075475374717 1 + 1 1 33 1 PT0S PT0S It is worth noting that XQuery passed in this way is in no way associated with the context in which prof: eval is executed . In order to pass parameters to debugged XQuery, you can use the $ vars parameter , which is a sequence of variables in the form (QName, <value>). Example
prof:eval(
"declare variable $a external; $a + 1",
(fn:QName("", "a"), 1)
)
or so
prof:eval(
"declare variable $a external; declare variable $b external; $a + $b",
(fn:QName("", "a"), 1, fn:QName("", "b"), 1)
)
If an error occurs while executing XQuery, prof: eval throws a PROF-PROFILEALLOW exception .
About the next function, we can say that it is similar to prof: eval, with the only exception that it receives not XQuery as a text string, but the path to the XQuery module.
prof:invoke(
$path as xs:string,
[$vars as item()*],
[$options as node()?]
) as item()*
The XQuery module does not have to be a library, it must be the “main” executable module. The path to the module resolves relative to the root of the application server. Otherwise, prof: invoke is completely analogous to prof: eval .
MarkLogic Server allows you to create profiles not only for XQuery passed in the prof: eval and prof: invoke function , but also for instructions located directly in the program module. Moreover, profiling is not tied to a specific program code, but to a request processed by the server. This allows you to debug not only the code in the current request, but also analyze any request knowing its ID and not interfering with the application code, which can be very useful in case of analyzing the application in the production environment.
In order to start collecting information about the execution, you need to call the function
prof:enable(
$request-id as xs:unsignedLong
) as empty-sequence()Where $ request-id is the request identifier for which to start profiling.
You can get the ID of the current request using the xdmp: request () function .
In order to stop the collection of information you need to use the function
prof:disable(
$request-id as xs:unsignedLong
) as empty-sequence()As follows from the foregoing, you can profile any code processed between calls to the prof: enable and prof: disable functions if profiling is performed for the current request, or between the times to which these functions were called if the analysis is not performed on the current request.
When trying to use the profiler, the following user rights are checked
“http://marklogic.com/xdmp/privileges/profile-my-requests” - to profile your requests
“http://marklogic.com/xdmp/privileges/profile-any- requests ” - to profile any requests
Of course, there is a small exception - for profiling the current request (the request for which there are profiling functions) special ghosts are not required, and “profile-my-requests” gives the right to profile all (except the current) requests of the current user.
To check if profiling is available for a specific request, you can use the function
prof:allowed(
$request-id as xs:unsignedLong
) as xs:booleanIn order to get the collected information about the execution of the request, use the function
prof:report(
$request-id as xs:unsignedLong
) as element(prof:report)?
Unlike prof: eval , which returns a report and the result of XQuery, the prof: report function returns only a report. Prof
example : report
let $e as empty-sequence() := prof:enable( xdmp:request() )
let $r as xs:string := fn:string( 1 + 2 )
return
prof:report( xdmp:request() )Sometimes there is a need to delete the accumulated information and start reporting again, the function is used for this
prof:reset(
$request-id as xs:unsignedLong
) as empty-sequence()
The following function is similar to the prof: eval function , but unlike it, prof: value inherits the context when the specified XQuery is executed.
prof:value(
$expr as xs:string
) as item()*Inheriting context by prof: value function allows you to write such code
let $a := 1
let $b := 2
return
prof:value('$a + $b')There are two more interesting features.
prof:xslt-eval(
$stylesheet as element(),
$input as node()?,
[$params as map:map?],
[$options as node()?]
) as item()*prof:xslt-invoke(
$path as xs:string,
$input as node()?,
[$params as map:map?],
[$options as node()?]
) as item()*Where $ input is an XML document processed in an XSLT processor.
The name of these functions makes it clear that they are similar to the prof: eval and prof: invoke functions , but are used to profile XSLT, the processor of which the MarkLogic Server developers have so carefully built into their product.
MarkLogiс Server provides powerful tools for performance analysis. With this mechanism, you can create complex profilers for a variety of tasks. At the same time, MarkLogiс Server has a graphical profiler in the integrated console, which makes the analysis process simpler and more convenient for small tasks and in the development process.