Pesquisar

Discussão (1)2
Entre ou crie uma conta para continuar
Pergunta
· Jul. 7

Is there a way to specify a number of IRISDB processes to be kept alive for serving requests and background jobs ?

In IRIS, every time a request need to be processed, a specific IRIS process (IRISDB.EXE) need to be assigned to handle that request.

If there is no spare IRIS process at that time, process will need to be created (and later destroyed). On some Windows systems (especially with security/antimalware solutions being active) creating new processes can be slow, which can results in delays during peak times (due to inrush of requests).

Because of that, it's sometimes useful to have some a certain number of processes already created and idling, for handling requests, especially during peak times (eg: in the morning). Is there a way to do that in IRIS ? (eg: in Portal or via config file)

I know it's already possible in Apache using the MinSpareServers setting and a specific NSD configuration.

The NSD process will hold connections made to IRIS, preventing IRISDB processes to be terminated once request is created.
That way it's possible to have a "pool" of IRISDB.exe processed to be created and stay.

However there is a major caveat which is those processes can be used for something else than a specific Apache node :

  • If multiple Apache nodes are used (eg: using a load balancer), each of them will use N processes. For example with 4 Apache nodes each being set to hold 100 processes, 400 processes will be created. If one Apache node need more than 100 processes it cant use some from the 400 processes pool at IRIS side.
  • Those processes can't be used for something else than requests (eg: jobs, IRIS work queue, ... ). Can be an advantage, depending how you look at it.

What I am looking is a setting, set at IRIS that will create and hold a certain amount of processes, regardless what they will be used for (either request or jobs).

2 Comments
Discussão (2)2
Entre ou crie uma conta para continuar
Resumo
· Jul. 7

Publications des développeurs d'InterSystems, semaine Juin 30 - Juillet 06, 2025, Résumé

Juin 30 - Juillet 06, 2025Week at a GlanceInterSystems Developer Community
Resumo
· Jul. 7

Nuevas publicaciones en la Comunidad de InterSystems, 30 junio - 6 julio

Artículos
Anuncios
#InterSystems Official
#Comunidad de Desarrolladores Oficial
30 junio - 6 julioWeek at a GlanceInterSystems Developer Community
Artigo
· Jul. 7 3min de leitura

Definiciones y referencias del cubo de análisis

Quizá esto sea bien conocido, pero quería ayudar a compartirlo.

 

Considerad que tenéis las siguientes definiciones de clases persistentes:

Una clase Factura con una propiedad que referencia a Proveedor.

Class Sample.Invoice Extends (%Persistent, %Populate)
{
Parameter DSTIME = "AUTO";
Property InvoiceNumber As %Integer(MINVAL = 100000) [ Required ];
Property ServiceDate As %Date(MINVAL = "+$h-730") [ Required ];
Index InvoiceNumber On InvoiceNumber;
Property Provider As Sample.Provider [ Required ];
Index Provider On Provider [ Type = bitmap ];
/// Build some invoices, this will firstly create 100 Providers
/// <Example>
/// Set tSC=##class(Sample.Invoice).Build()
/// </example>
ClassMethod Build(pCount As %Integer = 100020, pInit As %Boolean = 0) As %Status
{
    #dim tSC 			As %Status=$$$OK
    #dim eException  	As %Exception.AbstractException
    try {
        If pInit {
            $$$THROWONERROR(tSC,##class(Sample.Provider).%KillExtent())
            $$$THROWONERROR(tSC,##class(Sample.Invoice).%KillExtent())
        }
        $$$THROWONERROR(tSC,##class(Sample.Provider).Populate(100))
        $$$THROWONERROR(tSC,##class(Sample.Invoice).Populate(pCount))
    }
    catch eException {
        Set tSC=eException.AsStatus()
    }
    Quit tSC
}
}

y Proveedor

Class Sample.Provider Extends (%Persistent, %Populate)
{

Property Name As %String [ Required ];
Property NPI As %Integer(MAXVAL = 9000000000, MINVAL = 100000000) [ Required ];
}

Si llamáis al método Build en Sample.Invoice, podéis consultar esto con SQL.

SELECT
InvoiceNumber,Provider->Name, Provider As ProviderId,ServiceDate
FROM Sample.Invoice

y veréis

El área que trata este artículo es cómo decidir crear una dimensión sobre Proveedor.

Lo que he comprobado que funciona bien es seguir este patrón.

Esto hace lo siguiente:

  1. Define la dimensión Unique Id en Proveedor (que es el Id de Sample.Provider). Esto es importante porque es totalmente posible que haya más de un Proveedor con el nombre SMITH, JOHN. Al definir el nivel de dimensión en la propiedad Proveedor, estamos indicando que la tabla de dimensiones se cree basada en un Proveedor único. Si miramos en la tabla de dimensiones generada, vemos...

  1. Define una propiedad para el nivel que

 a. Identifica la propiedad = Provider.Name

 b. Obtener valor en tiempo de ejecución = Sí

 c. Usar como nombres de miembros = Sí

Esto tiene el efecto secundario de definir en la tabla de dimensiones la siguiente declaración de propiedad

/// Dimension property: Name<br/>
/// Source: Provider.Name
Property Name As %String(COLLATION = "SQLUPPER(113)", MAXLEN = 2000) 
[ Calculated, 
SqlComputeCode = {Set {Name}=##class(Sample.BI.Cube.Invoice.Provider).%FetchName({Provider})}, SqlComputed ];

con el método %FetchName que se ve así

/// Fetch the current value of %FetchName.<br/>
/// Generated by %DeepSee.Generator:%CreateStarTable.
ClassMethod %FetchName(pKey As %String) As %String
{
 // If we don't a value, show key as this is most likely the NULL substitute
 Set tValue=pKey
 &SQL(SELECT Name INTO :tValue FROM Sample.Provider WHERE %ID = :pKey)
 Quit tValue
}

 

Esto significa que cuando se recuperen los miembros de una dimensión, devolverá el Nombre del Proveedor y no el Id del Proveedor.

Usando Analyzer podemos ver

¿Por qué es esto importante?

  1. Si el nombre del Proveedor cambia en Sample.Provider, el cubo no tiene que ser reconstruido ni sincronizado. Si tenemos cientos de millones de facturas y cambian los nombres de los proveedores, no queremos tener que reconstruir o sincronizar el cubo de facturas por un solo cambio en el nombre de un proveedor.
  2. La tabla de dimensiones para Proveedor se basa en el Id del Proveedor, lo que permite tener más de un proveedor con el mismo nombre en la tabla de dimensiones o en el cubo.

Si en lugar de definir una Propiedad de Nivel de Dimensión definimos la Propiedad de Nivel como Provider.Name, esto significa que cuando el cubo se construye o sincroniza:

  1. El índice único de la dimensión se basa en Provider.Name, lo que provoca que todos los proveedores con el mismo nombre se agrupen bajo ese nombre.
  2. Si Provider.Name cambia, será necesario reconstruir el cubo.
Discussão (0)1
Entre ou crie uma conta para continuar