1 of 1 people found this helpful
Given that the workstations are all pretty much the same, I'd suspect that the upload of images to your hosted file has to do with the network hardware. Switches, cables, connectors, hubs, etc. All are suspects. Maybe the simplest thing to do is to swap the physical location of the fastest machine with the slowest. If their performance is also interchanged, then the problem is in the wires/switches. If it is hard to physically move the machines, you can also try swapping their physical connections in the switching 'closet'.
You didn't actually say whether this is wired or wireless, I'm just assuming you have wires.
Also, you say the images are stored "by reference". Are you using the newest 'Managed Containers'? If not, you really want to look into using them, since it is unclear from your description where the images files actually reside. (I hope they aren't distributed across all of the workstations.)
-- Drew Tenenholz
Many thanks for your thoughts. I will look into the managed containers as I
haven't done anything with these since updating everything to v12. Thanks
for the tip.
The images reside on another server (also Windows 2008 R2) in our
centralized job files.
That is a great idea about physically relocating workstations and seeing
what happens. My sense was that it had something to do with switches (or
other obscure network bits that I know zero about) and not the individual
workstations, since my machine suddenly took a speed hit after our IT
consultants installed monthly patches/updates. It has been difficult to get
them to seek a solution and their answer is to automatically blame
Filemaker (that they do not offer support on).
Again thank you so much for the great ideas. I will post any advancement
made towards a successful solution.
1 of 1 people found this helpful
I've seen this kind of variation among workstations with small networks where we could pin things down to some hardware such as the quality/speed of the internal tework cards on the different machines. A generational change in the network card can be enough to to speed things up by multiples.
Another factor is whether an individual workstation has email, browsers, and other network connections open, all sharing bandwidth and taking their toll even when they are hidden or background operations.
If you have a slow network card and have a lot of background network stuff running on a workstation, you can get slowdowns based on the card speed difference X the number of network access operations running on that station. The multiples pile up quickly.
At then there's still the other exteranl network hardware already under consideration. These factors can all build on each other when more than one of them is a bottleneck.
Thanks Stephen - I appreciate you sharing your knowledge and experience on
The fastest machine is certainly the one that probably has the least
additional operations happening on it - as I use it for testing and hence
it tends to only have one single main application running at a time. I will
look into this and see if I can narrow it down.
We have been investigating further and have yet to track this speed difference issue down, but something new came up that seemed to potentially invalidate my original thought that it was a network related issue.
This was because occassionally I have to copy the database(s) over to a laptop so that they can be used out of the office in a disconnected state. I move the images over to the local drive and then update their referenced locations by re-importing the photos to the new local directory with all of the network cabling unplugged. I am not using v12 managed storage containers yet.
Normally, it takes a while before the field mapping dialog comes up, but once mapping is set, the process is lightening fast and typically import is complete (to say 12,000 images) within a could of seconds.
However, the last time I performed this operation, the same slow speed issue occurred with image importation - with it having slowed down to about 3 per increment. I cannot fathom what could have made this change, but it seems that this is not a client/server problem as I had originally thought.
Again I appreciate the insights aleady given and would welcome any further thoughts.
To jump in here a bit - have you checked the thumbnail settings on the database? If you're creating the thumbnails on the fly (i.e., thumbnail creation is set to "temporary"), it might be having an effect. Alternatively, if the images are different, and you're using permanent thumbnail storage, the first time the image is loaded, it'll create thumbnails, which will slow things down; after that, the images might load faster.
Just something to check. Off the top of my head.
Thanks for your input.
I have not used the manage containers feature before and the thumbnail generation was indeed it was set to 'temporary'. I switched off thumbnail generation and retried the import but it made no discernable difference in the import speed.
BUT - what it did lead me to think about was a mapping that I had across to a thumbs container that I have in the db (but in fact never use). I re-mapped my script step to exclude an import to the thumbs container and this indeed corrected all of the speed differences between the different network workstations and the slow local import on the laptop. Even the slowest of the workstations now imports 300 photos without barely blinking.
So the speed difference problem seems to be in the method that is called up by the thumb generation and I assume that this must be some utility that exists on the local machine and accessed by Filemaker? Since the speed differences used to come and then sometimes correct itself, I assume that whatever utility is used is subject to patching or updates and that is what affects performance? As you can tell, I know little about this subject technically and maybe someone with better knowledge can give a better and more authoritive explanation.
But thank you everyone for your input in helping identify the cause of this issue.