1

ファイルをftpサーバーにアップロードするためにSTORBINARY関数を使用し、このサーバーからダウンロードするためにRETRBINARY関数を使用するpython 2.7コードがあります。

ただし、問題は、Dell ラップトップと比較して、異なるブランドの 3 つのラップトップでアップロードに非常に長い時間がかかることです。奇妙な点は、ファイルを手動でアップロードすると、すべてのシステムで同じ時間がかかることです。

手動アップロード速度と Python スクリプトを使用したアップロード速度は、Dell ラップトップで同じです。ただし、他のすべてのブランドのラップトップ (IBM、Toshiba、Fujitsu-Siemens で試しました) では、python スクリプトのアップロード速度は手動の試行よりも非常に低くなります。また、これらの他のすべてのラップトップでは、python スクリプトを使用したアップロード速度は同じ (1Mbit/秒) ですが、手動アップロード速度は約 1 秒です。8 メガビット/秒。

アップロードのファイルサイズを変更しようとしましたが、役に立ちませんでした。TCP Optimizer はすべてのシステムでダウンロード速度を改善しましたが、アップロード速度には影響しませんでした。すべてのシステムでこのスクリプトを使用したダウンロード速度は問題なく、手動ダウンロード速度と同じです。

サーバーを確認したところ、空き容量が 90% を超えています。ネットワーク接続はすべてのラップトップで同じです。一度に 1 台のラップトップだけをアップロードしてみます。すべてのラップトップは、ほぼ同じシステム構成、同じオペレーティング システム、およびほぼ同じ空きドライブ容量を備えています。どちらかと言えば、Dell ラップトップは処理能力と RAM の点で他の 2 つより少し劣りますが、これらのアップロード中の CPU 使用率とネットワーク使用率を何度も確認したため、影響はないと思います。他のウイルスやプログラムが私の帯域幅を食い尽くしていないことを確信しています.

storbinary コマンドでも、ブロックサイズを 57344(56 kB) に指定すると、アップロード速度が本来の 1 ～ 1.5 Kbit/s から 5 Kbit/s 程度に向上します...その理由は何ですか? また、手動アップロード クライアント (filezilla を使用) で使用されているブロックサイズ、またはアップロードに最適なブロックサイズを見つけるにはどうすればよいですか?? @ギドット

完全なコード:

def upnew(counter=0):

    f=open("c:/10", "w")

    f.write(os.urandom(10*1024*1024))
    f.close()

    print "Logging in..."

    ftpserver='xxxxxxx'

    ftpuser='xxxxxxx'

    ftppw='xxxxxxxxx'

    ftp = FTP(ftpserver)    
    ftp.login(ftpuser, ftppw)  

    t = open("c:/10", "rb")                       
    upstart = time.clock() 

    ftp.storbinary('STOR 10', t)

    upende = time.clock()-upstart

    print ((10*8)/upende)

    print "press Return to disconnect"
    raw_input()

    ftp.quit()
    print "FTP Verbindung abgebaut"


upnew(1)
4

3 に答える 3

0

あなたのコードの実用的なサンプルを提供してください... ftp 関数の実装が有用なフィードバックを提供することが不可能であることを確認することができませんが、一般的にはスレッドまたはソケットを使用することでメリットが得られる可能性があります。

于 2012-09-13T12:32:54.663 に答える
0

私は間違っているかもしれませんが、問題は ftp.storbinary() を呼び出して使用する方法にあるようです

代わりに ftp.ntransfercmd() を使用してみて、バッファを使用して処理中に転送を分割します。これにより、ftp 転送の進行状況を追跡できるという追加の利点が得られ、理論的には、必要に応じてプロセスを一時停止および再開できるようになります。

このスクリプトのパフォーマンスをテストしていませんが、次のようなことを試すことができます。

    def ftpUploader():
        BLOCKSIZE = 57344 # size 56 kB

        ftp = ftplib.FTP()
        ftp.connect(host)
        ftp.login(login, passwd)
        ftp.voidcmd("TYPE I")
        f = open(zipname, 'rb')
        datasock, esize = ftp.ntransfercmd(
            'STOR %s' % os.path.basename(zipname))
        size = os.stat(zipname)[6]
        bytes_so_far = 0
        print 'started'
        while 1:
            buf = f.read(BLOCKSIZE)
            if not buf:
                break
            datasock.sendall(buf)
            bytes_so_far += len(buf)
            print "\rSent %d of %d bytes %.1f%%\r" % (
                  bytes_so_far, size, 100 * bytes_so_far / size)
            sys.stdout.flush()

        datasock.close()
        f.close()
        ftp.voidresp()
        ftp.quit()
        print 'Complete...'
于 2012-09-13T14:47:50.357 に答える
0

Python は主にスクリプト作成とプロセスの自動化に使用され、技術的には変化が速い言語とは見なされていません (ただし、他のほとんどのスクリプト言語よりも高速です)。Filezilla は C/C++ を使用してコーディングされており、Python よりもパフォーマンスがはるかに優れています。とはいえ、これは公正な比較ではなく、一般的なパフォーマンスの問題を引き起こす可能性のあるロジックの問題を特定しようとする際に考慮する必要があります。

storbinary は基本的に ntransfercmd のラッパーとして機能し、独自のバッファーを定義する必要なく ntransfercmd を呼び出します (これが、以前の推奨事項の理由です)。

さらに、コード snip-it を再度分析した後、print ステートメントを介して storbinary を呼び出していることに気付きました...これはエラーですか?

この時点で、パフォーマンスに影響を与える可能性のあるロジックの問題を特定するために、この例で使用されているすべての関連コードが必要になります。追加情報を提供するために、以前のスニップイットに基づいて構築してください。

ここで考慮すべきもう 1 つの要素は、テストを実施する一般的なシステム環境です。テストを実行した各システムの場所、FTP サーバーからの距離、さらに ISP または DNS の違いを考慮してください。 ftp などの TCP/IP ベースの接続に関連するパフォーマンスの問題をトラブルシューティングする場合、サーバーが大きな要因になる可能性があります。

于 2012-09-14T17:33:24.920 に答える