A beta tester just emailed with an example of very slow tag gallery rendering.
Know that PhotoStructure has been designed to render pages as instantaneously as possible: imports and syncs “front-load” as much computation as they can, so PhotoStructure is still performant even when hosted on very CPU-constrained servers (like raspberry pi and shared VMs): but if your disk is slow, PhotoStructure will be slow.
If you run the webservice with --verbose or use your browser’s network tab and see response latencies for the /img/ endpoint take more than 10ms, something with your disk I/O is amiss. I’d check the following:
-
If you have a constrained network and a beefy server that’s currently running a sync, PhotoStructure may have “saturated” the I/O of your disk. SSDs happily parallelize reads, but “spinning rust” or HDDs will suffer under heavy concurrency. Try pausing the sync and see if that helps.
-
If the system’s underlying storage media is unhealthy, this can cause I/O latency. If your hardware supports it, run a self-test and check SMART for warnings or errors.
-
If this is mounting a windows remote file share, know that there are antivirus/antimalware apps that pre-scan on every file read (which slows down everything). If you have to run Windows, I recommend using Microsoft Windows Defender over any other solution.
-
If your library is mounted via a remote file share, know that consumer routers and switches can have terrible wired or wireless performance. I had a (well-rated!) router that caused 50% packet loss on wired connections, and have had a (couple!) switches that caused packet loss after a brownout. The
pingtool can help diagnose these issues.