15ミリビット/秒のネットワークで20ミリ秒の遅延でx11vncを使用しています。画面が大きく変化しているとき、x11vncが遅い-たとえば、ブラウザーでタブを切り替えるとき、ビューが完全に再描画されるまでに約2秒かかります。
奇妙なことに、x11vncの最大接続速度は、再描画が遅い場合でも、利用可能な帯域幅の約10％しかありません。x11vncが利用可能な帯域幅を使用して再描画を高速化しないのはなぜですか？たとえば、scpは問題なく使用可能な帯域幅を100％使用しています。
システム上のx11vncのボトルネックを特定するにはどうすればよいですか？これまでのところ私は思います：
どのようにすればx11vncをさらにプロファイリングして、スローダウンの原因を突き止めることができますか？
たとえば、x11vncが処理しているデータ量と、画面を取得し、処理して圧縮し、ネットワーク経由で送信するのにかかる時間を示すスイッチはありますか？
回答:
私自身の質問に答えるには：
タイトエンコーディングからhextileエンコーディングに切り替えると、再描画が遅いという問題が完全に解決しました。
詳細を追加すると、画面の再描画が遅い間に、クライアントのCPUが100％の使用率に急上昇していることに気付きました。私はタイトエンコーディングを使用しており、VNCタイトエンコーダー-比較結果のページから、タイクエンコーディングはヘクタイルエンコーディングと比較するとかなりCPUを集中的に使用することがわかります。hextileの最大CPU使用率に切り替えた後、100％になることはなく、利用可能な帯域幅のほぼ全体が使用され、再描画には常に1秒未満かかります。したがって、クライアントのCPUがボトルネックでした。
または、より良い代替手段（帯域幅が少なく、CPU使用率が低く、hextileよりも高速に見える）は、TurboVNCサポートを使用してx11vncをコンパイルし、TurboVNCクライアントを使用することです。
その理由は、画面キャプチャー/レンダラーが非効率的だからです。多くの異なるVNC実装がこれをいじって、パフォーマンスを向上させます。
ローカルコンソールの内容を正確に反映する必要がない場合、より良いソリューションは、リモートデスクトップ環境としてのNoMachineのNXまたはFreeNXです。WANリンク上でも、VNCと比較して昼夜のパフォーマンスです。
これがうまくいくことを願っています。http://www.karlrunge.com/x11vnc/faq.html#faq ... VNCビューアパラメータとx11vncパラメータを検索します。
それは私のために働いた。