Hello, I'm at the stage of porting the data from old (SQL2005+conquest 1.4...) to new (SQL 2019+conquest 1.5) platform, and I found a stange behaviour that apparently hampers the performences with MsSQL.
If I transfer the images from another instance, or put them in the "incoming" folder, the current setup imports around 50 img/s. However, I noticed that the hardware is barely used: processsors around 20%, processor queue 0, disk queue 0 (see attachments, the hardware is old but capable: 2x 4 cores xeon, SAN based on 15k disks). I noticed that during import the lsass process uses as many as resources as sql+conquest together. I investigated a bit the issue, and I found that dgate64 logins and logout from SQL for each image. Apparently, the vast majority of time is used to do these continuos logins, that seem to tax lsass and cause unneded delays. I wonder if these logins for each image are needed. Couldn't be kept logged-in the proces, at leas for some minutes?
Interestingly, if the database is regenerated (dgate64 -ARMAG0) a single login is performed and all the images are imported under the same connection to SQL, at an incommensurably higher speed. I understand that in this case no disk write is implied, but it looks like it is not the disk the bottleneck. This is also suggested by the fact that remote transfer (implying full disk write) and data in "incoming" (implying only a move between directories in the same partition) hve similar speeds of 40-60 img/s.
BTW the documentation looks to suggest that pooled logins are faster tahn unpooled ones, and teh logins are of the unpooled variety.