BLOGS

ベンチマーク

warning: file_get_contents(http://www.telize.com/geoip/54.224.56.126) [function.file-get-contents]: failed to open stream: HTTP request failed! in /var/www/www.4d.com/docs/includes/common.inc(1762) : eval()'d code on line 4.

64-bitでのシーケンシャルソート

64-bit環境におけるシーケンシャルソート

パフォーマンスにおける拡張性の効果をお見せするために、32-bitおよび64-bitバージョンの4D Server v12を使用して、シーケンシャルソートにかかる時間を比較しました。ソートでは比較に使用する一時的なデータを格納するメモリが必要になります。4D Serverはこの種の処理にキャッシュを使用せず、“エンジンメモリ” (キャッシュの外に4D Serverが割り当てることのできる仮想メモリ) 内のメモリを割り当てます。今回のテストでは両環境でキャッシュに同じサイズを設定しました。必要な一時メモリの量が大きくなると、32-bitバージョンでは物理メモリ内に一時メモリ領域を確保できなくなります。そこでOSはディスクにメモリをスワップします。スワップが発生するということは遅くなるということです。ディスクアクセスはミリ秒単位で計測され、RAMアクセスはマイクロ秒単位で計測されます。64-bitバージョンでは、4D Serverは必要なメモリをすべてRAMでまかなうことができます。

 

4D Server v12 64-bitでのクエリ

キャッシュサイズを増やしてクエリをスピードアップ

拡張性とは通常、速度のことではありません。より多くのメモリを割り当てられることで、アプリケーションの動作が速くなるわけではありませんが、より重いロードをサポートできるようになります。しかし動作が速くなることもあります。これは4D Serverがより多くのRAMを使用できるようになるためです。典型的な例はキャッシュサイズです。32-bitバージョンではキャッシュに最大2.3GBを割り当てることができます。(残りは接続やプロセス、ユーザー、コードを処理するためにエンジンが使用します。) 64-bitバージョンにはこの制限がなく、キャッシュにすべてのレコードインデックスを格納することができます。これによりアプリケーションが速くなります。すべてのデータをキャッシュに置くことができることで、4D Serverは (空きスペースを作ってユーザーがリクエストしたレコードをロードする等のために) それをパージする必要はなくなります。レコードはすでにキャッシュにあり、ディスクとのスワップは発生しません。

 

この動作をお見せするために、同じテーブルに対するシーケンシャルクエリを2回実行して時間を比較しました。

 

4D Server v12 64-bitの拡張性

拡張性: 510ユーザーと64-bitバージョンの4D Server v12

フルロードの拡張性を検証するために、32-bitと64-bit、2つの4D Server v12.1に対して510のクライアントから同時接続する様子を観察します。各クライアントは2つの異なるプロセスでクエリー/作成/削除を行います。これらの処理を行う間、統計データを収集します。

 

Query by Formula - サーバで実行

4D v11 SQLは, フォーミュラによるクエリをサーバ側で実行するので, 劇的に速度が向上しています。

4D 2004において, フォーミュラによるクエリはクライアント上で実行されていました。これはすべてのレコードがネットワーク経由で渡され, フォーミュラを適用し, セレクションに加えるかどうか判定されることを意味します。

リクエストのロジックが許す限り, 4D v11 SQLはクエリをサーバ上で実行し, ネットワークの過大な負荷を避けます。通常のクエリのように, セレクションのみがクライアントに返されます。

QUERY BY FORMULA (スタンドアロン) のテストで使用した, 距離を測るフォーミュラに戻りましょう。

 

QUERY BY FORMULA(distance($latitudeRef;$longitude;[customer]latitude;
     [customer]longitude)<10)

4D 2004では, クエリに8.6秒かかりました。

4D v11 SQLでは, このクエリに要する時間は0.7秒です。

テーブルのレコード数, ネットワークの速度, 待ち時間にもよりますが, 12倍の速度向上です。

Query by Formula - スタンドアロン

4D v11 SQLは, フォーミュラによるクエリの実行速度が大幅に向上しています。

4D 2004では, フォーミュラはレコードごとにシーケンシャルに評価されます。

4D v11 SQLは, クエリを最適化するためにあらかじめフォーミュラを分析します。構文アナライザはクエリのシーケンシャルな部分を減少させることで最適化可能なフォーミュラを特定することができます。

私たちのテストケースでは, 顧客の地理的な位置 (緯度と経度による位置)を使用します。特定のポイントの10km以内にはいる顧客を見つけたいとします。"Distance"関数により, 2地点間の直線距離を知ることができます。

 

注記 : このテストではピタゴラスの定理を使用しています。この方法は高速ですが, 精度には 20km (12マイル) 程度の誤差が生じます。グローバルな2点間距離の算出には,  Haversine の半正矢関数などが適しています。

 

スケーラビリティテスト

How many simultaneous, active clients can 4D Server handle? This laboratory scalability test examines the limits of a real application on 4D Server v11 SQL.

4D v11 SQL Release 3のスケーラビリティ, 特にマルチプロセッサ処理の管理が向上したことに関する最近の発表ののち, 多くの方より 4D Server への同時接続数に関するご質問をいただきました。

仕様上, あるいは4Dのエンジニアが信じる限り, クライアントの同時接続数について4D Server v11 SQLは4D Server 2004のそれをはるかに上回っていることは疑いのないことです。しかしクライアント/サーバ接続の実際のユーザビリティは, 運用されているハードウェアと, アクティビティレベルやデータベースに接続した様々なマシンにより行われるリクエストに左右されます。

そのため私たちは, クライアント数の拡張を検討している顧客と共同で, スケーラビリティテストを行いました。4D 2004から変換され, 一切の最適化を行っていないこのテストの環境において, クライアント側から起動されたアクションの完全なコントロールを保持しつつ, バックエンドでは実際のアプリケーションを使用しました。

 

ベンチマークレポート

実在のアプリケーションお用いた4D v11 SQL パフォーマンステストの内容を紹介します。

全体が, 部分ごとの合計より大きいことがあるか?

これは私たちが4D v11 SQLの新しいアルゴリズムを作成するときに考えていた問題です。すべてのコマンドが個別に考慮され, ユニットテストを通じて性能の改善を評価する方法を知ってはいますが, パフォーマンスのトータルな性能向上を決定するのは, ユーザの感じ方です。

これを念頭におき, 私たちは, 絶え間なく変化するリクエストをクライアント/サーバ環境で実行する, 可能なかぎり現実的なアプリケーションに対して私たちのテストを走らせるべきと考えました。

 

Application Structure

手順

4D SQL v11の特定の振舞いを例証するために, 私たちは単純なストラクチャからリクエストを行います。このケースはコールセンター管理アプリケーションのサブセットです。