If your bottleneck is the I/O performance of each server, I would launch a process per-server to scan the directories and potentially (I/O performance permitting) more processes to process each found file from a queue.
You seem to have the part of enqueueing and processing the found files in parallel already down, but short of eliminating the network bottleneck by launching processes on the remote servers or by launching local processes for each server, I don't see how your approach could be made faster.
You could periodically launch the equivalent of
dir /b /s c:\audiofiles\ > \\centralserver\incoming\audio-%hostname%.l +og
... or use Perl to do the same. That would somewhat eliminate the network traffic. But if your scanning is bound by the ability of the (windows server) hard disks to deliver the directory entries, that won't help much either.
Before you embark on a longer programming spree, you could do a test in the shell to see whether the parallel performance is actually faster than the serial scanning:
TS=$(date '%Y%m%d-%H%M%S') for server in (server01 server02 server03); do ls -1R /mnt/$server/incoming > /tmp/$server-$TS.log & done
This will try to scan three servers in parallel.
In reply to Re^5: File::Find won't iterate through CIFS share withouth "dont_use_nlink"
by Corion
in thread File::Find won't iterate through CIFS share withouth "dont_use_nlink"
by reinaldo.gomes
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |