Anyone left from the Frame 7 UNIX era? (performance issue)

[davej148]

It takes several minutes to open any document that is full of references to image files. The problem appears to be related to the extreme level of file attribute reads ("attr get" column when running fsstat -F 3) and lookup operations the application insists on performing before the document is available for editing. This is completely different from the latency seen when each page and new images are loaded. I typically see >300 attr gets, and >400 lookup ops *per second* when opening one of these files, so I could see over 100,000 of each before the file comes up. This is for a 50 page document with ~3 images per page. I looked into whether this was a hard disk latency issue, since it would take a spinner significant time to respond to all of these requests, even with small data per request, but it looks like virtually all of the requests were being handled by the filesystem cache (RAM). Does anyone know why all of these requests are being made, and if there is any way to get around the problem?

[Bob_Niland]

I haven't run FM7/Unix in over 6 years now, but don't recall a problem like this (and all our imported objects were on the enterprise network).

Is this a new problem broadly, or just arose on a new document?

Does the problem go away if you unselect:
View » Options » Display: ☐ Graphics
(just as a diagnostic, not a solution, and, alas, you have to have the file open to do that)

Separately, what are the image file types? If EPS or PDF, how are any preview/thumbnails encoded?

[davej148]

I haven't run FM7/Unix in over 6 years now, but don't recall a problem like this (and all our imported objects were on the enterprise network).

Is this a new problem broadly, or just arose on a new document?

This is not a new problem. It exists on all of my documents that are loaded with image

Does the problem go away if you unselect:
View » Options » Display: ☐ Graphics
(just as a diagnostic, not a solution, and, alas, you have to have the file open to do that)

I tried this, closed the document, then reopened with the same result: several minutes to open

Separately, what are the image file types? If EPS or PDF, how are any preview/thumbnails encoded?

The image file types are all JPEG

[Matt-Tech Comm Tools]

Are you running this on a box that's as old as Fm 7, or on a VM running circa 2000 UNIX?

Since more recent systems might have dropped support for things that Fm 7 is looking for, I would look at the system requirements for Fm 7 and ensure they're met.

[Bob_Niland]

Yep, the overall architecture could matter here:
What's the end user machine?

Is FM running locally or on the server?
What's the file server?
What FS is it running?

When I last used Solaris FM7.1 over a journaled Solaris network, the enterprise had already given up trying get any more Sun workstations for the end users, and had resorted to running FM7.1 on the servers, via a window on Windows (with some loss of function) at the desktop.

[davej148]

Yep, the overall architecture could matter here:
What's the end user machine?

Is FM running locally or on the server?
What's the file server?
What FS is it running?

When I last used Solaris FM7.1 over a journaled Solaris network, the enterprise had already given up trying get any more Sun workstations for the end users, and had resorted to running FM7.1 on the servers, via a window on Windows (with some loss of function) at the desktop.

By Bob_Niland

End  user machine: This might be confusing for those not familar with X, but the application is running on a Sun SPARC T5220 with Solaris 10. For the sake of this question, this should probably be considered the "end user machine". But the user is actually sitting on a Solaris 10 x86 machine with the $DISPLAY forwarded. It is basically being used as an X terminal for this application. The architecture of the user's display has nothing to do with the operation of the application. 

Application running locally or on the server?: Efectively locally. See above.

File server: This particular set of files are locally on the T5220.

FS (assuming File system): ZFS in RAID 10 configuration *BUT* adaptive replacement cache (ARC) checks show virtually all of the FS operations while opening a document have been read from cache (ARC), so it looks like no disk latency issues were involved.

[davej148]

Are you running this on a box that's as old as Fm 7, or on a VM running circa 2000 UNIX?

Since more recent systems might have dropped support for things that Fm 7 is looking for, I would look at the system requirements for Fm 7 and ensure they're met.

By Matt-Tech Comm Tools

Anything in particular? Nothing obvious looking at https://wwwimages2.adobe.com/content/dam/acom/en/devnet/framemaker/pdfs/InstallX.pdf. The application appears to be doing a huge number of file attribute checks, possibly proportional to the number of images referenced. I can't think of anything FM 7 could be looking for that would cause this

[davej148]

Are you running this on a box that's as old as Fm 7, or on a VM running circa 2000 UNIX?

Since more recent systems might have dropped support for things that Fm 7 is looking for, I would look at the system requirements for Fm 7 and ensure they're met.

By Matt-Tech Comm Tools

Anything in particular? Nothing obvious looking at https://wwwimages2.adobe.com/content/dam/acom/en/devnet/framemaker/pdfs/InstallX.pdf. The application appears to be doing a huge number of file attribute checks, possibly proportional to the number of images referenced. I can't think of anything FM 7 could be looking for that would cause this

By davej148

Missed first question: not a VM. Solaris is backward compatible, and I don't get any errors indicating I am missing anything.