wtx

WTX

主にWebテクノロジーに焦点を当てたさまざまな輸送の実装と関連ツールのコレクション。 6つのIETF RFC（6265、6455、7541、7692、8441、9113）の社内開発、2つの正式な仕様（GRPC、PostgreSQL）、および他のいくつかの発明されたアイデアを特徴としています。

1. クライアントAPIフレームワーク
2. データベースクライアント
3. データベーススキーママネージャー
4. GRPCクライアント/サーバー
5. HTTPクライアントフレームワーク
6. HTTPサーバーフレームワーク
7. HTTP/2クライアント/サーバー
8. プールマネージャー
9. UIツール
10. WebSocketクライアント/サーバー
11. HTTP/2を超えるWebSocket

すべての機能はオプションであり、コンパイル時間に設定する必要があります。詳細については、意図したドキュメントをご覧ください。

ワーキングヒープアロケーターを備えた埋め込みデバイスは、このno_stdクレートを使用できます。

パフォーマンス

一般的にパフォーマンスを改善する多くのことは、プロジェクトで使用されます。

1. 手動のベクトル化：大量のデータを処理することでアルゴリズムが知られている場合、コンパイラがX86プロセッサのSIMD命令を利用できるようにするために、ループを分割する最良の方法を分析するためにいくつかの実験が実行されます。
2. メモリの割り当て：可能な場合はいつでも、すべてのヒープ割り当ては、インスタンスの作成の開始時に1回だけ呼び出され、さらに、スタックメモリの使用量は、ヒープメモリよりも優先されることが好ましいです。
3. 依存関係が少ない：デフォルトでは、サードパーティが注入されていません。言い換えれば、追加の依存関係は、貨物機能の選択を通じてユーザー次第であり、編集時間を短縮します。たとえば、 cargo tree -e normal --features postgresを使用して、PostgreSQLクライアントが必要とする16の依存関係を確認できます。

メモリは通常、その場で作成され、ドロップされる代わりにインスタンスレベルで保持されるため、その使用量はユースケースによって大幅に成長する可能性があることに注意する価値があります。充当されている場合は、リソースの共有プールを使用してみるか、当事者間で交換できるデータの量を制限してみてください。

高レベルのベンチマーク

WTXベンチをチェックアウトして、さまざまなベンチマークを確認するか、誤解や誤った誤解を自由に指摘してください。

主に、パフォーマンスに影響を与える2つのこと、選択されたランタイムと事前に割り当てられたバイトの数があります。特に、握手ごとに新しいインスタンスを作成する必要があるサーバーの場合、短命または低移動接続の多数のバイトを事前に割り当てると、マイナスの影響があります。

低レベルのベンチマーク

リポジトリに#[bench]がマークされたものはすべて、一般的に他の部分の基礎として機能する非常に特定の操作を測定するという意味で、低レベルのベンチマークと見なされます。

https://bencher.dev/perf/wtxを見て、さまざまな期間にわたってすべての低レベルのベンチマークを表示します。

輸送層のセキュリティ（TLS）

ネットワーク接続を必要とする機能を使用する場合、暗号化された通信を実行する必要があることが多く、 wtx特定のストリーム実装でハードコーディングされていないため、最適なTLSプロバイダーを選択するのはあなた次第です。

TokioRustlsConnectorやTokioRustlsAcceptorなどの一部のユーティリティは、物事をより便利にするために利用できますが、クライアントの使用の証明書を提供する木枠をアクティブにする必要があることに留意してください。

例

さまざまなユースケースのデモンストレーションは、 wtx-instancesディレクトリとドキュメントに記載されています。

制限

• 16ビットのポインター長のシステムをサポートしていません。

• 任意の数のスライスの長さの間違いのない合計が予想されます。そうしないと、プログラムは予期しない操作につながる可能性のあるオーバーフローをトリガーする可能性があります。たとえば、32ビットシステムでは、このようなシナリオは、メモリを交換せずに、またはulimitのような特定のリミッターを介して実行可能である必要があります。