FileZilla Server Optimization for an internal 10GB network

We have a digital cinema system content library (hold all digital content for the theater) that is directly connected to a 10GB optical switch-port with MTU set at 9,000.  However the transfer rates seem slow after 2 simultaneous connections and I was wondering if the default FileZilla Server settings may be hindering the performance for transferring these large files (roughly 6-15GB files) throughout the network.  Is there any recommended changes anyone could suggest to the FileZilla Server app to optimize or take advantage of the network capabilities?

Thanks for your help and suggestions!
Gregg AckermanAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

robocatCommented:
Most likely the bottleneck is in the disk system of the library.

Transferring one big file is mostly sequential IO (which can be archieved by any PC type SATA hard drive),

Transferring 3 or more large files simultaneously from the same media is in essence random IO and requires a high(er) performance disk system (eg. RAID with SAS disks or SSD).

What kind of disk hardware do you have?
2
Zephyr ICTCloud ArchitectCommented:
Hi,

Is the MTU set on both ends and all equipment in between the devices? Because if not it will not have any effect.

As for tweaking, there's not much to tweak on FileZilla, except for the amount of simultaneous transfers, don't set it too high because it will have inverse effect on the speed, you can experiment with it of course.
1
Gregg AckermanAuthor Commented:
robocat,

Great comment, I didn't really put much thought on the disk IO.  We are utilizing a  Dell RAID 5 array spanning over eight 1TB 7.2K SAS drives.  I thought this would provide enough performance, throughput and capacity to allow FileZilla to perform well-above a 100MB/sec rate.  We achieve over 100MB/sec network transfer rates on only 2 simultaneous transfers (both running at 50-60 each).  The third and subsequent transfers start to crawl at 2-5MB/sec throughput after the two initial and established transfers start.  I was hoping to see faster network transfer rates or a better capacity capability with more simultaneous transfers on our 10GB SFP+ connection to the switch's backbone.  I guess I could have saved money and just teamed 1-4GB NIC ports instead of the 10GB SFP+ NIC ports.

Thanks for your help!
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

Gregg AckermanAuthor Commented:
spravtek,

Great point on the MTU.  I did set the MTU on both ends, both the NIC and the switch-port.  I'm wondering if there is a better MTU to choose over 9,000?  Is that MTU best for sending large files?  I did some research and I am not sure if I have the most optimal MTU setting.

On FileZilla, I have set NO LIMIT on the most of the limiting settings for transfers.  Currently when 2 simultaneous transfers occur, I get the largest network throughput, fluctuating around 50-60MB/sec each transfer.  After 2 transfer, all subsequent transfers crawl around 2-5MB/sec.  Now that you mentioned the simultaneous transfer settings, I wonder if I should set it to 2, allow the maximum throughput to complete before starting other transfers.  Hmm

Thanks for your help!
0
Zephyr ICTCloud ArchitectCommented:
For large files a MTU of 9000 should be ok, mostly it comes down to experimenting though. If your devices support it you could go higher even... But I had cases where a MTU of 1514 would work better than a MTU of 9000.

If I was you limiting the simultaneous transfers would be a good first step, if all that is still not hitting the mark I'd start taking a look at other things, like storage (as robocat mentioned).
1
Gregg AckermanAuthor Commented:
You know I think I am running into that as well...I clocked the MTU of 1514 as better performing.  It may be the process in which FileZilla sends the file.  Thanks for the your help, it is very much appreciated.
0
Zephyr ICTCloud ArchitectCommented:
It's a possibility that the buffers of the switches can't follow, not large enough ... It could be lots of things, to get to the bottom of it you could start sniffing the traffic, but that might be a bit overboard ;)

Glad to help!
1

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
robocatCommented:
> Now that you mentioned the simultaneous transfer settings, I wonder if I should set it to 2, allow the maximum throughput to complete before starting other transfers

It all depends on what you're trying to do.

If you have to transfer a certain number of files in the shortest possible time, then yes, serializing the transfers will speed up the overall process. Less is more!

But in a "streaming" concept, it may not matter that much as long as each client gets enough data to play the media.
1
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Networking

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.