#Performance

Caché Version String: Cache for UNIX (Red Hat Enterprise Linux for x86-64) 2016.2.1

We have a mirrored Ensemble system (110, backup and 210, primary). At one time (14:00) there is a disruption in the production. The messages are not being processed.

Cache version: Cache for Windows (x86-64) 2017.2.1 (Build 801_3U)

Good Afternoon,

I have a co-worker who is trying to run the below query via ODBC. The issue is that the query appears to be running extremely slow (nearly 2 hours).

I use the following code to start a start a job :

Class MyClass Extends (...)
{
    ClassMethod Foo()
    {
       job $CLASSMETHOD("MyClass","MyMethod") //take forever depending hardware
    }

    ClassMethod MyMethod()
    {
       //do database related stuff
    }
}

On local environment, calling Foo() is instantaneous (a few ms). On production/test servers (which have much better hardware than local) calling this function is slow and take between 200 ms to 800 ms. Obviously starting a new job with "job" command take lot of time on those environments.

Here is a snippet that I learned yesterday

You can define an index on a collection property but when I tried to use it, I failed. I was using

     Select ….. where …. :xx %INLIST collproperty

But this will not use an index, but the equivalent syntax

     SELECT .. WHERE ... FOR SOME %ELEMENT(collproperty) (%VALUE=:xx)

will use the index

Check out

Any recommendations, to this VMware disk type debate, with Cache installations in particular?

Thick Provision Lazy Zeroed

Thick Provision Eager Zeroed

Thin Provision

I am designing the software architecture for an Ensemble/Healthshare production to be deployed on Amazon AWS EC2 servers (2 mirrored m4.large - 4 vCPUs / 16 GiB RAM running RedHat Linux 3.10.0-327.el7.x86_64 and Healthshare for RHEL 64-bit 2016.2.1). It's a rather CPU-intensive production involving massive XSLT 2.0 transformations (massive both in terms of size and volume). I was wondering if anyone has experience configuring Ensemble productions on EC2 servers. My question or concern has to do with the following statement in the Ensemble documentation:

As I was going though and trying to figure out why our CACHE.dat has increased in size over the past 18 days, I found that EnsLib_HL7.Message is still retaining messages dating back to 2014 even though we have our purge set to 10 days. Has anyone else experienced this?

Thanks

Scott Roth

The Ohio State University Wexner Medical Center

Currently, we are running 2014.1 on two different servers (OpenVMS, RHEL). The plan is to transition from OpenVMS to RHEL, but our Write Daemon is in a Troubled state on both servers.

On the OpenVMS server, we have a WIJ file that's 26G and can grow to 40G (size of database cache). Since it hasn't grown to 40G, we don't believe the size of the WIJ file to be the issue.

What else should we be looking at regarding the performance of the Write Daemon?

Has anyone done any kind of integration with Dynatrace, which is a JVM transaction monitoring tool? Our organization uses this extensively with our Java and .Net applications and we wanted to know if it is even possible.