SFTPの速度制限（共有サーバーの良い隣人であること）
ローカルサーバーでWebサイトを開発しており、本番環境にアップロードする準備ができています。
最初のアップロードは4 GBの範囲になります。サーバーを非難したくありません。Filezillaの速度制限設定はそれを防ぐのに役立つと思います。
デフォルトの速度制限はDownload: 100 KiB/sおよびUpload: 20 KiB/sです。それらは実行可能ですか？ 1つのアップロードイベントに対して100 KiB/sで問題ありませんか？
また...私は：
Webサイト全体を圧縮し、1つのモノリシックZipファイルとして転送します（サーバーで解凍します）？または...
Filezillaの圧縮を使用してローカルディレクトリをSFTPするだけですか？
ありがとうございました。
Post Mortem：最初のアップロードでは、ホスティング会社のパネルでファイルマネージャーを使用して、サイトのモノリシックZipファイルを選択してアップロードしました。私は..それらのツールとデフォルトを使用することでどれだけのトラブルが発生する可能性があります。すぐにアップロードされ、CPU使用率が一時的に急上昇しただけで解凍されました。これは毎日の使用には適したオプションではありませんが、1回限りのイベントの場合は大丈夫だったと思います。
Local-development-siteとserver-production-siteの間の長期的な同期のために、Filezillaを試して報告します。
Zipファイルに関しては、いくつかの要因に依存すると思います。 WinZipには、コードに書き込まれていない実用的なファイル制限がありましたが、4つのディレクトリに287,000 +/-小さなファイルを圧縮しようとすると失敗しました。新しいバージョンの方がうまく機能している可能性があります。 GunZip（GZip）を使用している場合、それが最適に機能する可能性があります。大きなファイルを転送したいのですが、インストール全体を圧縮すると、まだ問題が発生する可能性があります。その理由は次のとおりです。
FTPクライアントに依存します。一部のFTPクライアントは、失敗した場合にファイル転送を再開できます。クライアントは転送された量を認識し、失敗した場所から再開します。一部のFTPクライアントは、要求した場合でもそうしません。同様に、1つのFTPクライアントは、私が何をしようと、287,000 +/-ファイルを（zip圧縮せずに）決して転送しません。毎回何らかの理由で失敗し、よく知られた高品質のFTPクライアントでした。とてもイライラします。
制限速度のアイデアと、隣人にナイスになりたいというアイデアが好きです。あなたはそのことを称賛されるべきです！遅い転送速度を気にしないなら、私はそれを提案するでしょう。
私の個人的な好みは、1つまたは複数のZipファイルを使用することです。すべてのファイルの圧縮と解凍には時間がかかる場合があります。私はあなたの状況を完全には知りません。クライアントの作業が少なくなり、データが圧縮されるため、大きなZipファイルの転送は実際には高速になります。ファイルを圧縮し、単一のファイルとして転送しようとします。ただし、問題が発生しても驚かないでください。個々のファイルの転送は、低速ではありますが、うまく機能する可能性があります。
繰り返しますが、問題があるかどうかはすべてZipソフトウェアとFTPクライアントに依存します。多分彼らはうまく動作するでしょう。試してみてください。私は問題を抱えていたかもしれませんが、そうではないかもしれません。よく知られているクライアントを使用していたので、私はまったく問題があることに驚いた。
また、大きなファイルを解凍すると、CPUとI/Oサブシステムに一定期間打撃を与える可能性があることに注意してください。
ところで-新しいFTPクライアントを探していました。これがうまくいくかどうかをお知らせください。
使用したほとんどの共有サーバーは、許可されているアップロードのしきい値を超えると、一時的にアップロードを制限します。ファイルを処理するために必要なネットワーク接続が少ないため、＃1が最適です。サーバーは、新しい接続の開閉に多くのリソースを費やします。多くのネットワーク接続は通常、安価なサーバーを停止させます。
＃1を使用すると、1つの接続でファイルを処理できます。サーバーのプロセッサは、エンドユーザーにサービスを提供するサーバーの機能に大きな影響を与えることなく、ファイルを解凍できます。
ファイルとディレクトリのZIP圧縮は非常に役立ちます。その際、必ず結果を比較してください。
コンテンツの大部分がバイナリである場合、Zipファイルは元のファイルのサイズを超えることがあります。ほとんどの場合、テキストのようなファイル（HTML、Javascriptなど）は大幅に縮小される可能性があるため、そのステップを踏む価値があります。
FileZillaには、[転送]メニューで使用できる速度制限機能があります。
ただし、問題があります。ほとんどはバッファリングに関係しています。
FileZillaは確かにこれらの設定を尊重しますが、ネットワーク自体の速度が変動している場合、ネットワークまたはサーバーインターフェイスがビジー状態のときに速度制限のあるFileZillaが転送バッファをいっぱいにした状況に簡単に気付くことができます。
その後、ネットワークがより多くの帯域幅を開くと、データがサブネットを実際に移動する速度に制限がなくなります。これを理解することが重要です。データを爆発させて、できるだけ早くバッファをアンロードします。
言い換えれば、あなたはあなたの能力の範囲内で、良い隣人になるためにできることをすべてやっています。ネットワーク管理者はそれを尊重しています。
これが社内で一般的に行われている場合、管理者の最善のアプローチは、ネットワークの残りに影響を与えずにポート間の転送を処理できるように、両方のシステムがニースの高いバックボーン容量を持つネットワークスイッチ上にあることを確認することです。それは素敵で整頓されています。
ただし、転送がインターネットゲートウェイまたは他のユーザーが使用しているのと同じサーバーインターフェイスを経由している場合、ISPの転送上限を最大にするか、サーバー上のインターフェイスを飽和させることで、過度の競合を回避する簡単な方法がないことがわかります。
最近、私が使用しているISPは、それ自体で上限を強制するだけです。だからあなたは彼らに頭痛を引き起こしていない。
しかし問題は、そのゲートウェイを共有する必要があるネットワークの残りのユーザー、またはオンライン中に大規模な更新に使用しようとしているのと同じインターフェースで本番サーバーを使用しているユーザーです。
通常、スケジューリングが最善の解決策になることをお勧めします。たとえば、cronによってトリガーされるsftpを介した午前4時の転送。
いずれの場合も、必ず管理者と密接に協力してください。はい、彼らは忙しいですが、彼らが望む最後のものは、ヘルプの呼び出しをトリガーする原因不明の停止です。これを信じて。短い監督付きのテストと、従うアプローチの慎重な評価により、より良い体験が得られます。