long delays first time in when calling business entity via D

Posted by Darren Parr on 06-Jan-2020 12:18

Hi

We've noticed long delays when running fetches via the DOH. We're using server side paging and the DS fill from start to finish is taking 0.8 seconds but we're looking at a huge amount of time before we see the entry in the log file. I think the DOH is taking an age to work out what to do.

The catalog fetch works via my own handler and I notice the column labels show instantly. Then I have to wait.

In my scenario, the catalog fetch occurs. 26 seconds later it calls the read method. Clearly the kendo grid is making the call pretty much immediately. The read call ends 0.8 seconds after its called. So its slow.

Note that after being called once, a subsequent call is OK and as I would like the first call.

My .gen file is 6 MB. Is it reading the .gen file thats taking the time. I dont believe it reads it all as a different read call consumes similar delays the first time its made.

Any ideas?

-Darren

OpenEdge Development - Forum

All Replies

Posted by Peter Judge on 06-Jan-2020 17:14

Darren,
 
The DOH does read the <service-name>.gen file on first request for that service and adds the info to its cache.  There are other caches that are loaded on first contact that may also contribute to that slowness.
 
You can preload those caches from the session startup procedure using code* similar to
 
OpenEdge.Web.DataObject.ServiceRegistry:RegisterAllFromFolder(substitute('&1/openedge', os-getenv('CATALINA_BASE'))).
 
This method loads all .gen and .map files in the given folder.
 
The ServiceRegistry class also has a RegisterFile() method if you want to load just a single mapping file.
 
The ServiceRegistryLoader (which does the work) doesn't have any logging showing how long a file takes to load.  I've added OCTA-18558: DataObjectHandler's ServiceRegistryLoader does not log how long files take to load for that. Please contact Tech Support if you'd like your name added to that issue.
 
 
 
* since we don't ship a session startup procedure we can't automatically pre-load the caches.
 
 
-- peter
 
 

Posted by Darren Parr on 07-Jan-2020 10:31

Thanks. I'm afraid that didn't work. After doing this we get an error when making the first call saying it cant find locate the service. In addition with my 12.1, RegisterFile doesn't show up (private perhaps?).

I think out biggest issue is likely to be the time each agent takes to load it. If there's a 40 second or greater delay, then staring multiple agents up front is likely to lead to the possibility the pas startup will timeout (180 sec by default).

Is there a way of caching it after its been loaded in a form which makes multiple agents faster?

-Darren

.

Posted by Peter Judge on 08-Jan-2020 15:54

> After doing this we get an error when making the first call saying it cant find locate the service.
 
Hm. That sounds like a bug …
 
Just to verify that once cached, things are performing ok?
 
The DOH's caching per-agent approach is currently only JSON file-based. I think it'd make sense to look into other approaches, so that each session doesn't have to do the parsing of the mapping file, but that'd be a new feature for us.
 
And just to confirm that the GEN file contains 1 service with many operations?
 
The load-file method name is OpenEdge.Web.DataObject.ServiceRegistry.RegisterFromFile(pcFile)  .
 
 
 

Posted by Darren Parr on 09-Jan-2020 17:19

Hi. Its fine once loaded. The .gen file contains a single service with 6 operations per business entity. We have about 400 business entities which explains why the delay exists.

I'll give it another go.

-D

Posted by Darren Parr on 09-Jan-2020 17:30

That works correctly. The RegisterFromFile is functionally correct. I think we're still looking at the same issue on agent startup in terms of time but its better than it not working at all. Our 400 BE's have the same static methods and so I think in a worst case, there may be a need for me to write my own handler and not use the DOH. I don't see the point in that extra work whilst the DOH does the job.

No immediate rush for now. We're in development  mode.

Thanks for your help.

-D

This thread is closed