in such "photosystem" like is the Syno Photos (DSM7) are these four critical elements frequently overlooked (by the vendor or by customers):
The first element is about the data:
1. the number of photos stored for the first batch
2. median of the file size
3. the amount of metadata stored within the file
4. this isn't about + 100 photos daily increment (peanut)
The second element is about the engine (system) which operates the photosystem:
1. framework - hidden by Synology (e.g. PHP version + ImageMagick, ...)
2. DB - hidden by Synology. It seems to be the internal PostgreDB.
3. added-value service engines, like face recognition, ...
4. reindexing process (DB power eater)
The third element is the NAS OS:
1. FreeBSD know
2. kernel ver is hidden by Synology long time (< 5.0 sure)
The fourth element is the NAS HW:
1. CPU (threads utilized by the kernel and the Second element)
2. RAM (Double Data Rate and operational frequency are crucial for the handling of such heavy data flow). DB with free 8GB RAM is a must for photos >10k in the catalogue!
3. MoBo performance
4. disk drives (each with possibility handling +80MB/s are usable = SATA2)
Conclusion:
So, when you don't have information about the second element, you can't tune the DB performance to achieve dramatic results, to the max. utilization of your 3rd and 4th elements.
Another problem is that you do not have root privileges on this database, so it is not possible to change its behaviour at all. When you will find tune steps, each additional update of the DSM system and Photos will change your tuning setup = because it is the internal Syno DSM DB.
Then the first element with more than 10000 photos will kill all patience.
The fourth element with HW from 2012 and insufficient architecture or power will kill all great features from the second element.
There is no one universal setup for the second element that will perform excellently based on fundamentally different conditions in the first, third and fourth elements (and together).
The result is known.
PS:
I got bothered with the performance settings for MySQL (Piwigo) to keep my large photo catalogue flexible and fast. The advantage is that you can communicate directly with the authors of the system and share experiences with users who have already tried something. With Syno Photos, you are referred to what Syno has to offer. And the fact that Syno does not often bother with user problems is perhaps clear to everyone.
The first element is about the data:
1. the number of photos stored for the first batch
2. median of the file size
3. the amount of metadata stored within the file
4. this isn't about + 100 photos daily increment (peanut)
The second element is about the engine (system) which operates the photosystem:
1. framework - hidden by Synology (e.g. PHP version + ImageMagick, ...)
2. DB - hidden by Synology. It seems to be the internal PostgreDB.
3. added-value service engines, like face recognition, ...
4. reindexing process (DB power eater)
The third element is the NAS OS:
1. FreeBSD know
2. kernel ver is hidden by Synology long time (< 5.0 sure)
The fourth element is the NAS HW:
1. CPU (threads utilized by the kernel and the Second element)
2. RAM (Double Data Rate and operational frequency are crucial for the handling of such heavy data flow). DB with free 8GB RAM is a must for photos >10k in the catalogue!
3. MoBo performance
4. disk drives (each with possibility handling +80MB/s are usable = SATA2)
Conclusion:
So, when you don't have information about the second element, you can't tune the DB performance to achieve dramatic results, to the max. utilization of your 3rd and 4th elements.
Another problem is that you do not have root privileges on this database, so it is not possible to change its behaviour at all. When you will find tune steps, each additional update of the DSM system and Photos will change your tuning setup = because it is the internal Syno DSM DB.
Then the first element with more than 10000 photos will kill all patience.
The fourth element with HW from 2012 and insufficient architecture or power will kill all great features from the second element.
There is no one universal setup for the second element that will perform excellently based on fundamentally different conditions in the first, third and fourth elements (and together).
The result is known.
PS:
I got bothered with the performance settings for MySQL (Piwigo) to keep my large photo catalogue flexible and fast. The advantage is that you can communicate directly with the authors of the system and share experiences with users who have already tried something. With Syno Photos, you are referred to what Syno has to offer. And the fact that Syno does not often bother with user problems is perhaps clear to everyone.
