2010 in-depth-v11

4D v11 SQLin Depth #1


• アーキテクチャー / スケーラビリティ

Tokyo/2010-03-03/04

用語の定義

Tokyo/2010-03-03/04

用語の定義• コオペラティブ: 他のプロセス（タスク, スレッド, ...）に譲るCPU時間を自分で決めるプロセス

Tokyo/2010-03-03/04


‣ 独占できる = ブロックできる（例 : Mac OS 9）

Tokyo/2010-03-03/04



‣ ひとつのアプリケーションのコオペラティブスレッドは必ず同じコアで実行される

Tokyo/2010-03-03/04




• プリエンプティブ: それぞれのプロセスに与えられるCPU時間はOSが判断する

Tokyo/2010-03-03/04




• プリエンプティブ: それぞれのプロセスに与えられるCPU時間はOSが判断する

• プリエンプティブな度合いが高いほど速い

Tokyo/2010-03-03/04

三対のツイン

��4

Tokyo/2010-03-03/04

三対のツイン• 4D Clientのグローバルプロセスは必ずサーバーにあるふたつのツインプロセスと対話している:

‣ プリエンプティブスレッド: «純粋な» DB4Dリクエストを処理 (query, order by, create, ...)

‣ コオペラティブスレッド: アプリケーションリクエストを処理 (Current date(*), GET PROCESS VARIABLE(-1;...), トリガ, ...)

��4

Tokyo/2010-03-03/04




• プリエンプティブな第三のスレッドと対話することもある

��4

Tokyo/2010-03-03/04




• プリエンプティブな第三のスレッドと対話することもある‣ これはBegin SQLが実行されると作成される

��4

Tokyo/2010-03-03/04





• それぞれの対話は異なるネットワークポートを使用する:

��4

. . . $date:=Current date(*) . . . QUERY([City];[City]Name=”Paris”) . . . Begin SQL . . .

Tokyo/2010-03-03/04






��4


アプリケーションサーバーポート: 19813

Tokyo/2010-03-03/04






��4


DB4D ポート: 19814

アプリケーションサーバーポート: 19813

SQLサーバーポート: 19812

Tokyo/2010-03-03/04

Tokyo/2010-03-03/04

4D Server

サーバー

オペレーティングシステム

コオペラティブプリエンプティブ

コア 1 コア 2 コア 3 コア 4

プロセス U1-1Req1... QUERY (Table1)

R2…⋯ R3…⋯

ユーザー 1

Tokyo/2010-03-03/04

4D Server

サーバー





R2…⋯ R3…⋯

ユーザー 1

プロセス U1-1 プロセス U1-1

19813 19814

Tokyo/2010-03-03/04

4D Server

サーバー





R2…⋯ R3…⋯

ユーザー 1

プロセス U2-1R1... Current date(*)

R2..

ユーザー 2

プロセス U3-1R1…⋯ R2


ユーザー 3


プロセス U2-2

R1.. R3

19813 19814

Tokyo/2010-03-03/04

4D Server

サーバー





R2…⋯ R3…⋯

ユーザー 1


R2..

ユーザー 2



ユーザー 3

プロセス U1-1

プロセス U2-1

プロセス U2-2

プロセス U3-1

プロセス U3-2

プロセス U1-1

プロセス U2-1

プロセス U2-2

プロセス U3-1

プロセス U3-2

プロセス U2-2

R1.. R3

19813 19814

Tokyo/2010-03-03/04

4D Server

サーバー





R2…⋯ R3…⋯

ユーザー 1


R2..

ユーザー 2



ユーザー 3

プロセス U1-1

プロセス U2-1

プロセス U2-2

プロセス U3-1

プロセス U3-2

プロセス U1-1

プロセス U2-1

プロセス U2-2

プロセス U3-1

プロセス U3-2

プロセス U2-2

R1.. R3

19813 19814

Tokyo/2010-03-03/04

4D Server

サーバー





R2…⋯ R3…⋯

ユーザー 1


R2..

ユーザー 2



ユーザー 3

プロセス U1-1

プロセス U2-1

プロセス U2-2

プロセス U3-1

プロセス U3-2

プロセス U1-1

プロセス U2-1

プロセス U2-2

プロセス U3-1

プロセス U3-2

プロセス U2-2

R1.. R3

19813 19814

Tokyo/2010-03-03/04

4D Server

サーバー





R2…⋯ R3

ユーザー 1


R2..

ユーザー 2


プロセス U3-2R1.. R2

ユーザー 3

プロセス U1-1

プロセス U2-1

プロセス U2-2

プロセス U3-1

プロセス U3-2

プロセス U1-1

プロセス U2-1

プロセス U2-2

プロセス U3-1

プロセス U3-2

プロセス U2-2

R1.. R2

19813 19814

Tokyo/2010-03-03/04

4D Server

サーバー





R2…⋯ R3

ユーザー 1


R2..

ユーザー 2



ユーザー 3

プロセス U1-1

プロセス U2-1

プロセス U2-2

プロセス U3-1

プロセス U3-2

プロセス U1-1

プロセス U2-1

プロセス U2-2

プロセス U3-1

プロセス U3-2

プロセス U2-2

R1.. R2

19813 19814

Tokyo/2010-03-03/04

4D Server

サーバー

19813 19814


R2…⋯ R3

ユーザー 1


R2..

ユーザー 2



ユーザー 3

プロセス U2-2

R1.. R3




スケジューラー

Tokyo/2010-03-03/04

4D Server

サーバー

19813 19814


R2…⋯ R3

ユーザー 1


R2..

ユーザー 2



ユーザー 3

プロセス U2-2

R1.. R2





Tokyo/2010-03-03/04

Begin SQL... Begin SQL... Begin SQL... Begin SQL... Begin SQL...

4D Server

サーバー

19813 19814


R2…⋯ R3

ユーザー 1


R2..

ユーザー 2



ユーザー 3

プロセス U2-2

R1.. R2





Tokyo/2010-03-03/04


4D Server

サーバー

19813 19814


R2…⋯ R3

ユーザー 1


R2..

ユーザー 2



ユーザー 3

プロセス U2-2

R1.. R2





1

Tokyo/2010-03-03/04


4D Server

サーバー

19813 19814


R2…⋯ R3

ユーザー 1


R2..

ユーザー 2



ユーザー 3

プロセス U2-2

R1.. R2





19812

Tokyo/2010-03-03/04


4D Server

サーバー

19813 19814


R2…⋯ R3

ユーザー 1


R2..

ユーザー 2



ユーザー 3

プロセス U2-2

R1.. R2





19812

Tokyo/2010-03-03/04


4D Server

サーバー

19813 19814


R2…⋯ R3

ユーザー 1


R2..

ユーザー 2



ユーザー 3

Process U2-2

R1.. R2

19812





Tokyo/2010-03-03/04


4D Server

サーバー

19813 19814


R2…⋯ R3

ユーザー 1


R2..

ユーザー 2



ユーザー 3

Process U2-2

R1.. R2

19812





Tokyo/2010-03-03/04


4D Server

サーバー

19813 19814


R2…⋯ R3

ユーザー 1


R2..

ユーザー 2



ユーザー 3

プロセス U2-2

R1.. R2





19812

Tokyo/2010-03-03/04





Tokyo/2010-03-03/04

伸張性と速度





DBリクエストは同時に複数のクライアントが実行できる

Tokyo/2010-03-03/04

伸張性と速度ボトルネック





DBリクエストは同時に複数のクライアントが実行できる

ランゲージトリガメソッド «サーバーで実行» ストアドプロシージャー Web サーバー/SOAP

4D自体: サーバーのユーザーインタフェースコネクションハンドラーある種の外部SQLリクエスト

Tokyo/2010-03-03/04

10 クライアント, QUERY または ORDER BY 同時に実行

ボトルネック

Tokyo/2010-03-03/04


2004以前: コオペラティブ

Tokyo/2010-03-03/04


Tokyo/2010-03-03/04


Tokyo/2010-03-03/04


Tokyo/2010-03-03/04

2004以前: コオペラティブ


Tokyo/2010-03-03/04

2004以前: コオペラティブ v11: プリエンプティブ... ...そしてスケーラブル


Tokyo/2010-03-03/04

いろいろなサーバー

Tokyo/2010-03-03/04

いろいろなサーバー

アプリケーションサーバー

Web /SOAP

SQL サーバー

DB4D サーバー

コオペラティブ

コオペラティブ

プリエンプティブ

プリエンプティブ

Tokyo/2010-03-03/04

v11-v12デスクトップクライアント-サーバー

コオペラティブプリエンプティブコオペラティブプリエンプティブ

インタフェース全般

ランゲージ

ストアドプロシージャー

HTTP サーバー


インデックスビルダー

フラッシュマネージャー

SQL サーバー

DB4D（データアクセス）

Tokyo/2010-03-03/04

v11-v12デスクトップクライアント-サーバー

コオペラティブプリエンプティブコオペラティブプリエンプティブ

インタフェース全般

ランゲージ

ストアドプロシージャー

HTTP サーバー


インデックスビルダー

フラッシュマネージャー

SQL サーバー

DB4D（データアクセス）

Tokyo/2010-03-03/04


4D Server

サーバー

19813 19814


R2…⋯ R3

ユーザー 1


R2..

ユーザー 2



ユーザー 3

プロセス U2-2

R1.. R2





Tokyo/2010-03-03/04

Tokyo/2010-03-03/04

ボトルネックランゲージトリガメソッド «サーバーで実行» ストアドプロシージャー Web サーバー/SOAP

!4D自体: サーバーのユーザーインタフェースコネクションハンドラーある種の外部SQLリクエスト

Tokyo/2010-03-03/04


Tokyo/2010-03-03/04


• サーバーが素早く終えられるように

• トリガ:

‣ 絶対に必要な場合だけ

‣ 汎用的なコードは避ける

• クライアントからプリエンプティブに (STA/

ATS, ...)

• EXECUTE ON CLIENTが活用できるかも

• コンパイルモードで重度のループ: IDLE

• コードリファクタリング: そんなにたくさんのストアドプロシージャーがほんとうに必要 ?

• . . .

Tokyo/2010-03-03/04


• サーバーが素早く終えられるように

• トリガ:

‣ 絶対に必要な場合だけ

‣ 汎用的なコードは避ける

• クライアントからプリエンプティブに (STA/

ATS, ...)

• EXECUTE ON CLIENTが活用できるかも

• コンパイルモードで重度のループ: IDLE

• コードリファクタリング: そんなにたくさんのストアドプロシージャーがほんとうに必要 ?

• . . .

考量せよ

«負荷と速度»


• アーキテクチャー


• アーキテクチャー• SQL vs 4D

Clichy/2010-02-03

SQL vs 4D - パフォーマンス

Clichy/2010-02-03

4D, 通常 QUERY( . . .)

SQL SELECT . . . FROM . . . WHERE . . .


Clichy/2010-02-03



インタプリター


Clichy/2010-02-03




DB4D エンジン

データファイル/インデックスファイル


Clichy/2010-02-03

• 4Dは不可分, ワンアクションに対して高度に最適化


Clichy/2010-02-03


‣ QUERY- 検索, セレクションの作成, 先頭レコードのロード- ここまでをすべてひとつのコマンドで


Clichy/2010-02-03



• SQLは汎用的

‣ ひとつの命令 (SELECT) であらゆる要求に対処


Clichy/2010-02-03



• SQLは汎用的


‣ 加えて存在するオーバーヘッド:

- 解析- 検証- SQL パススルー


Clichy/2010-02-03



• SQLは汎用的



- 解析- 検証- SQL パススルー- ランゲージバインディング


Clichy/2010-02-03



• SQLは汎用的



- 解析- 検証- SQL パススルー- ランゲージバインディング- エンジン障壁


Clichy/2010-02-03




DB4D エンジン


Clichy/2010-02-03




DB4D エンジン


Clichy/2010-02-03

• v11: SQL は 5-10 倍遅い場合がある


Clichy/2010-02-03


‣ しかしこれは飽くまで平均, あまり捕われないように

‣ 場合によっては, SQLのほうが速いことも


Clichy/2010-02-03



‣ 場合によっては, SQLのほうが速いことも- 典型例は計算を要するステートメント:

SELECT (Debits - Credits) FROM Clients into :rBalance

- プリエンプティブ

- 少ないネットワークリクエスト


Clichy/2010-02-03



‣ 場合によっては, SQLのほうが速いことも- 典型例は計算を要するステートメント:

SELECT (Debits - Credits) FROM Clients into :rBalance

- プリエンプティブ

- 少ないネットワークリクエスト

• SQL 12 vs SQL v11

‣ ローカルデータフェッチング => 2-3 倍高速

‣ リモートデータフェッチング => 5-20 倍高速


Clichy/2010-02-03

• どのような場合にSQLを使用するべき ?


Clichy/2010-02-03


‣ そのほうが速いと思える根拠があるとき


Clichy/2010-02-03


‣ そのほうが速いと思える根拠があるとき‣ SQLで記述したほうが楽なとき:


Clichy/2010-02-03


‣ そのほうが速いと思える根拠があるとき‣ SQLで記述したほうが楽なとき:


Clichy/2010-02-03


‣ そのほうが速いと思える根拠があるとき‣ SQLで記述したほうが楽（美しい ?）なとき

‣ 他のDB（4Dあるいはそれ以外）に接続するとき


Clichy/2010-02-03


‣ そのほうが速いと思える根拠があるとき‣ SQLで記述したほうが楽（美しい ?）なとき

‣ 他のDB（4Dあるいはそれ以外）に接続するとき

‣ SQL特有の機能が必要なとき


Clichy/2010-02-03

• DBメーカーの数だけ仕様が存在するというのが実情:

‣ OracleのコードがすべてMySQLで動くわけではない

‣ MySQLのコードがすべてPostgreSQLで動くわけではない

SQL-92

Clichy/2010-02-03

• DBメーカーの数だけ仕様が存在するというのが実情:

‣ OracleのコードがすべてMySQLで動くわけではない

‣ MySQLのコードがすべてPostgreSQLで動くわけではない

➡ Oracle, MySQL, PostgreSQL...で動いたコードがそのままでは4Dで動かないかもしれない（そしてこれをバグと呼ぶことはできない）

SQL-92


• アーキテクチャー• SQL vs 4D


• アーキテクチャー• SQL vs 4D• キャッシュ

Tokyo/2010-03-03/04

キャッシュ• 主要な目的は速度アップ（4D:データアクセス）

Tokyo/2010-03-03/04

キャッシュ• 主要な目的は速度アップ（4D:データアクセス）‣ 例:レコードをロードする

- 初回はディスクから読み込み:アクセスはミリ秒の世界

Tokyo/2010-03-03/04


- 初回はディスクから読み込み:アクセスはミリ秒の世界- 以降はキャッシュから:アクセスはナノ秒の世界

Tokyo/2010-03-03/04



1,000,000 倍高速

もし 1 ns = 1 秒だとすれば, 1 ms = 11,5 日

Tokyo/2010-03-03/04



Tokyo/2010-03-03/04



• キャッシュに収納されるものは ?- テーブル, フィールド, リレーション, インデックスなどストラクチャ定義情報 - 現在のデータベースに関する全般的な情報（ファイルパス, プロパティなど） - データファイルアロケーションビットテーブル - レコード, インデックス, BLOBの追加情報, 追加プロパティなど - インデックスページ - レコード - BLOB（キャッシュに充分のスペースがなければメインメモリに行くことも） - その他のプロパティ - シーケンシャルナンバー - トランザクション - セレクション - セット - 並び替え用の一時的バッファ, 先読み, ディスク書き込み用バッファなど

Tokyo/2010-03-03/04

キャッシュ

Tokyo/2010-03-03/04

キャッシュ• ほとんどは小さなオブジェクト: (<= 64 KB)

Tokyo/2010-03-03/04


‣ ファミリーごとにリンクしているため

Tokyo/2010-03-03/04


‣ ファミリーごとにリンクしているため- 例 #1: あるテーブルのレコード100,000,000 件分のアドレスのリストは複数のアドレステーブルに読み込まれる（それぞれは <= 64 KB）

Tokyo/2010-03-03/04



- 例 #2: セットは小さなオブジェクトに圧縮・分散されている

Tokyo/2010-03-03/04




• おおきいオブジェクトはユーザーオブジェクト:

Tokyo/2010-03-03/04





‣ BLOB　

Tokyo/2010-03-03/04





‣ BLOB　‣ ピクチャ

Tokyo/2010-03-03/04





‣ BLOB　‣ ピクチャ‣ テキスト

Tokyo/2010-03-03/04





‣ BLOB　‣ ピクチャ‣ テキスト‣ （レコード）

«BLOBs»と総称する

Tokyo/2010-03-03/04

キャッシュ

Tokyo/2010-03-03/04

キャッシュ• スタートアップで確保される

• アプリケーション実行中, 書き込み, パージ, フラッシュ, 再配置が繰り返される

Tokyo/2010-03-03/04



Tokyo/2010-03-03/04



Tokyo/2010-03-03/04



Tokyo/2010-03-03/04



• FLUSH BUFFERS

Tokyo/2010-03-03/04



• FLUSH BUFFERS• «汚れた»オブジェクトをディスクの保存すること

Tokyo/2010-03-03/04




• その後 «汚れていない»という印が付けられる

Tokyo/2010-03-03/04





• それにより, パージしても良い状態になる

Tokyo/2010-03-03/04





• それにより, パージしても良い状態になる

ディスクアクセスはミリ秒の世界 !

不必要にFLUSH BUFFERSしてはいけない

Tokyo/2010-03-03/04

キャッシュキャッシュがメモリを必要とするときは ?

Tokyo/2010-03-03/04

キャッシュ

• 状況:

- ロードしなければならないオブジェクトがある: レコード,アドレステーブル, ...

- 充分なスペースがない

キャッシュがメモリを必要とするときは ?

Tokyo/2010-03-03/04

キャッシュ

• 状況:



• 行動:


Repeat キャッシュの 10%をパージオブジェクトをアロケート Until 充分のスペース

Tokyo/2010-03-03/04

キャッシュ

• 状況:



• 行動:



Tokyo/2010-03-03/04

キャッシュ

• 状況:



• 行動:



Tokyo/2010-03-03/04



Tokyo/2010-03-03/04



確保したキャッシュ合計の10% キャッシュが1GBの場合,キャッシュマネージャーは100MBパージしようとする

Tokyo/2010-03-03/04




パージ

Tokyo/2010-03-03/04




パージ汚れていないオブジェクトをパージ

Tokyo/2010-03-03/04




パージ

メモリをアロケート

汚れていないオブジェクトをパージ

Tokyo/2010-03-03/04




パージ

OK?



Tokyo/2010-03-03/04




パージ

OK?


はい


Tokyo/2010-03-03/04




パージ

OK?


FLUSH BUFFERSいいえはい


Tokyo/2010-03-03/04




パージ

OK?


FLUSH BUFFERSいいえはい


Tokyo/2010-03-03/04



Tokyo/2010-03-03/04


• フラッシュする最初のオブジェクトまでジャンプ


Tokyo/2010-03-03/04


• フラッシュする最初のオブジェクトまでジャンプ➡キャッシュが先にフラッシュするオブジェクトはい

つも一緒とは限らない


Tokyo/2010-03-03/04


• フラッシュする最初のオブジェクトまでジャンプ➡キャッシュが先にフラッシュするオブジェクトはい

つも一緒とは限らない

• ディスクでの近接度を考慮して最適のフラッシュを試みる


Tokyo/2010-03-03/04



Tokyo/2010-03-03/04


v11は2004よりも劇的に速くなった汚れていないオブジェクトをパージ

Tokyo/2010-03-03/04


v11は2004よりも劇的に速くなった

• 2004: ハンドル(Mac)と連結リスト➡ オブジェクトは動いた➡ 4Dはリスト全体をたどる必要があった


Tokyo/2010-03-03/04




• V11: ポインタと一種のアドレステーブル➡ オブジェクトは動かない➡ 最大 3 アクセスでオブジェクトに到達


Tokyo/2010-03-03/04




• V11: ポインタと一種のアドレステーブル➡ オブジェクトは動かない➡ 最大 3 アクセスでオブジェクトに到達

(v11の新しいキャッシュメモリマネージャーのおかげ)


Tokyo/2010-03-03/04

キャッシュ

• 4D 32 ビット

最大サイズは ?

Tokyo/2010-03-03/04

キャッシュ

• 4D 32 ビット

➡ 最大 2.5 GB

➡ OS(32/64)に関係なく‣ ハードコードされた値‣ ユーザーが > 2.5 を設定した場合は下方修正


Tokyo/2010-03-03/04

キャッシュ

• 4D 32 ビット

➡ 最大 2.5 GB


• 4D 64 ビット(4D Server v12のみ)


Tokyo/2010-03-03/04

キャッシュ

• 4D 32 ビット

➡ 最大 2.5 GB


• 4D 64 ビット(4D Server v12のみ)

➡ «制限なし»




• データベースコンテキスト（トリガ, ...）

Tokyo/2010-03-03/04

データベースコンテキスト

4D Server

プリエンプティブコオペラティブ

19813 19814

プロセス U1-1Req1... ORDER BY (Table1)

R2…⋯ R3

ユーザー 1


Tokyo/2010-03-03/04


コオペラティブプロセス U1-1

プロセス U1-1Req1... R2…⋯ R3

Tokyo/2010-03-03/04

データベースコンテキストコオペラティブ

プロセス U1-1プロセス U1-1Req1... R2…⋯ R3

Tokyo/2010-03-03/04


��44

コオペラティブプロセス U1-1プロセス U1-1

Req1... R2…⋯ R3

Tokyo/2010-03-03/04


��44


Req1... R2…⋯ R3

コオペラティブツインプロセスが使用するもの:

- トリガ

- “サーバーで実行” プロパティが有効にされたメソッド

Tokyo/2010-03-03/04


��44


Req1... R2…⋯ R3


- トリガ


“サーバーで実行” トリガ

トランザクションステート

レコードロッキング

プロセスセット

プロセス命名セレクション

カレントセレクション

カレントレコード

Tokyo/2010-03-03/04


��44


Req1... R2…⋯ R3


- トリガ









Tokyo/2010-03-03/04


��44


Req1... R2…⋯ R3


- トリガ









Tokyo/2010-03-03/04


��44


Req1... R2…⋯ R3


- トリガ









Tokyo/2010-03-03/04


��44


Req1... R2…⋯ R3


- トリガ









Tokyo/2010-03-03/04


��44


Req1... R2…⋯ R3


- トリガ









Tokyo/2010-03-03/04


��44


Req1... R2…⋯ R3


- トリガ








カレントレコード(*) トリガのテーブルのみ

(*)

Tokyo/2010-03-03/04


��44


Req1... R2…⋯ R3


- トリガ








カレントレコード(*) トリガのテーブルのみ

(*)

Tokyo/2010-03-03/04

データベースコンテキスト• 例: リレートセレクションのsumをトリガで計算

‣ クライアントサイド:

. . .

QUERY([OrderLines];[OrderLines]_OrderID=[Order]ID) SAVE RECORD([Order]) . . .

‣ サーバーサイド («On save existing record»)

[Order]Total:=Sum([OrderLines]Price)

Tokyo/2010-03-03/04

データベースコンテキスト• 例: リレートセレクションのsumをトリガで計算

‣ クライアントサイド:

. . .

QUERY([OrderLines];[OrderLines]_OrderID=[Order]ID) SAVE RECORD([Order]) . . .

‣ サーバーサイド («On save existing record»)

[Order]Total:=Sum([OrderLines]Price)

[OrderLines] のセレクションは空

Tokyo/2010-03-03/04

トリガ• (特性と目的を考慮する)

Tokyo/2010-03-03/04


• クライアントサーバー: :

‣ セレクションとカレントレコード (カレントテーブルのレコード以外)

‣ クライアントと同期が取られていない => 再現する必要がある

≠ 2004

Tokyo/2010-03-03/04





プロセスセット,プロセス命名セレクション,レコードロッキング,トランザク

≠ 2004

Tokyo/2010-03-03/04





プロセスセット,プロセス命名セレクション,レコードロッキング,トランザクションステートは同期がとられている

≠ 2004

Tokyo/2010-03-03/04






• 複数が “同時に走る” (コオペラティブスレッドのプールの中で)

• 制限

≠ 2004

Tokyo/2010-03-03/04







• 制限‣ コオペラティブ(前述のとおり)

≠ 2004

Tokyo/2010-03-03/04







• 制限‣ コオペラティブ(前述のとおり)

‣ 最短の時間で終了しなければならない=(汎用的でない)

≠ 2004


• データベースコンテキスト（トリガ


• データベースコンテキスト（トリガ• スケジューラーを理解する

Tokyo/2010-03-03/04


• スケジューラーの目的 ?

• なぜv11になってもスケジューラーが必要なのか ?

Tokyo/2010-03-03/04




‣ 4Dランゲージはスレッドセーフではないから

Tokyo/2010-03-03/04




‣ 4Dランゲージはスレッドセーフではないから

• スケジューラーの擬似コード:

For 1からプロセス数まで If プロセスが遅延あるいは停止されていなければそのコードを 1 tick 実行する(16 ms)

Tokyo/2010-03-03/04



Tokyo/2010-03-03/04


• 4Dは各プロセス1 tickの徹底を試みる


Tokyo/2010-03-03/04



• スケジューラーに制御を返さないプロセスは他すべてを妨害する（ユーザーインタフェースも !）:


Tokyo/2010-03-03/04




‣ インタプリタモードでは大丈夫


Tokyo/2010-03-03/04




‣ インタプリタモードでは大丈夫‣ コンパイルモードでは起こり得る（典型的な例はIDLEをコールしない高密度ループ）For 1からプロセス数まで

If プロセスが遅延あるいは停止されていなければそのコードを 1 tick 実行する(16 ms)

Tokyo/2010-03-03/04




‣ インタプリタモードでは大丈夫‣ コンパイルモードでは起こり得る（典型的な例はIDLEをコールしない高密度ループ）

‣ プラグインは PA_Yield()あるいはPA_PieldAbsolute()をコールするべき


Tokyo/2010-03-03/04

スケジューラー実際には

Tokyo/2010-03-03/04

1.イベントをチェック（マウス, キーボード, ...）

➡ 適切な4Dプロセスに伝達する

2.その後, アクティブプロセスに1 tickずつのループに突入

スケジューラー実際には


Tokyo/2010-03-03/04

While 4D 実行中 // システムイベントを処理 Repeat If チェック_間隔が経過した If 4Dはビジーであるタイムアウト = タイムアウト_最短 Else タイムアウト = タイムアウト_最長 End if // ここでシステムに制御を返す Get イベントあるいはタイムアウトまで待機 If イベントは4Dプロセスに関係 Pass イベントをプロセスに伝達 End if End if Until イベントがない !

// それぞれの4Dプロセスに時間を与える For 4D プロセスそれぞれにつき Give 最低 1 tick アクティブプロセスを実行 End while

Tokyo/2010-03-03/04




Tokyo/2010-03-03/04



Tokyo/2010-03-03/04



Tokyo/2010-03-03/04



Tokyo/2010-03-03/04



SET DATABASE PARAMETER4D Server Scheduler 4D Remote Scheduler 4D Local Mode Scheduler

Tokyo/2010-03-03/04

スケジューラーデフォルト値

Tokyo/2010-03-03/04

スケジューラーデフォルト値

タイムアウト_最短タイムアウト_最長チェック_間隔

4Dを最高に 0 1 5

4Dを標準に 0 8 0

4Dを最低に 1 16 0

Tokyo/2010-03-03/04

スケジューラーWhile 4D 実行中 // システムイベントを処理 Repeat If チェック_間隔が経過した If 4Dはビジーであるタイムアウト = タイムアウト_最短 Else タイムアウト = タイムアウト_最長 End if // ここでシステムに制御を返す Get イベントあるいはタイムアウトまで待機 If イベントは4Dプロセスに関係 Pass イベントをプロセスに伝達 End if End if Until イベントがない !


Tokyo/2010-03-03/04

スケジューラー: 4Dを最高にWhile 4D 実行中 // システムイベントを処理 Repeat If 5 ticks が経過した If 4Dはビジーであるタイムアウト = 0 tick Else タイムアウト = 1 ticks End if // ここでシステムに制御を返す Get イベントあるいはタイムアウトまで待機 If イベントは4Dプロセスに関係 Pass イベントをプロセスに伝達 End if End if Until イベントがない !


Tokyo/2010-03-03/04

スケジューラー: 4Dを標準にWhile 4D 実行中 // システムイベントを処理 Repeat If 0 ticks が経過した If 4Dはビジーであるタイムアウト = 0 tick Else タイムアウト = 8 ticks End if // ここでシステムに制御を返す Get イベントあるいはタイムアウトまで待機 If イベントは4Dプロセスに関係 Pass イベントをプロセスに伝達 End if End if Until イベントがない !


Tokyo/2010-03-03/04

While 4D 実行中 // システムイベントを処理 Repeat If 0 ticks が経過した If 4Dはビジーであるタイムアウト = 1 tick Else タイムアウト = 16 ticks End if // ここでシステムに制御を返す Get イベントあるいはタイムアウトまで待機 If イベントは4Dプロセスに関係 Pass イベントをプロセスに伝達 End if End if Until イベントがない !


スケジューラー: 4Dを最低に

Tokyo/2010-03-03/04

スケジューラー• SET DATABASE PARAMETER（スコープ;値）

チューニング

Tokyo/2010-03-03/04

スケジューラー• SET DATABASE PARAMETER（スコープ;値）‣ スコープ:

- 4D Server スケジューラー- 4D Remote スケジューラー- 4D Local Mode スケジューラー

チューニング

Tokyo/2010-03-03/04



‣ 値:- 16進数で表記: 0x00mmMMBB

‣ タイムアウト_最短: 0 から 100 (0x00 から 0x64)

‣ タイムアウト_最長: 0 から 100 (0x00 から 0x64)

‣ チェック_間隔: 0 から 20 (0x00 から 0x14)

チューニング

Tokyo/2010-03-03/04




‣ タイムアウト_最短: 0 から 100 (0x00 から 0x64)

‣ タイムアウト_最長: 0 から 100 (0x00 から 0x64)

‣ チェック_間隔: 0 から 20 (0x00 から 0x14)

- デフォルト値: -1（最高/右）-2（標準/中央）-3（最低/左）

チューニング

Tokyo/2010-03-03/04




‣ タイムアウト_最短: 0 から 100 (0x00 から 0x64)

‣ タイムアウト_最長: 0 から 100 (0x00 から 0x64)

‣ チェック_間隔: 0 から 20 (0x00 から 0x14)

- デフォルト値: -1（最高/右）-2（標準/中央）-3（最低/左）

• 実行中のエンジンにローカルの値,保存されない

チューニング


• データベースコンテキスト（トリガ• スケジューラーを理解する


• データベースコンテキスト（トリガ• スケジューラーを理解する• スタック（メモリ）

Tokyo/2010-03-03/04

スタックとは ?• メモリの領域

Tokyo/2010-03-03/04


• コードの実行に不可欠な «オブジェクト» を収容

Tokyo/2010-03-03/04


• コードの実行に不可欠な «オブジェクト» を収容

• LIFOスタック:

‣ 返り値が収容される場所‣ パラメーター‣ ローカル変数‣ （サブルーチン毎）

Tokyo/2010-03-03/04

スタックのサイズプリエンプティブスレッド: デフォルトサイズ

Tokyo/2010-03-03/04


OS サイズWindows 1 MB

Leopard 512 KB

Snow Leopard 1 MB

Tokyo/2010-03-03/04



Leopard 512 KB

Snow Leopard 1 MB

• DB4D サーバー

• SQL ネットセッションマネージャー

• SQL ネットコネクション

• 予備 SQL

• クライアントグローバルプロセスのプリエンプティブツイン

Tokyo/2010-03-03/04



Leopard 512 KB

Snow Leopard 1 MB

• DB4D サーバー

• SQL ネットセッションマネージャー

• SQL ネットコネクション

• 予備 SQL

• クライアントグローバルプロセスのプリエンプティブツイン

GET/SET DATABASE PARAMETER(53;バイト数)

Tokyo/2010-03-03/04

スタックのサイズプリエンプティブスレッド: ハードコード値

➡フラッシュマネージャー (512 KB)

➡インデックスビルダー (512 KB)

Tokyo/2010-03-03/04

スタックのサイズコオペラティブスレッド

Tokyo/2010-03-03/04

スタックのサイズ

• 4Dコードを実行するため

• 起源:

‣ ランゲージ - New process / Execute on server

- 自動 ‣ Web/SOAP サーバープロセス ‣ メニューアイテムのプロパティ, ...

‣ On exit データベースメソッド

‣ 内部コード - ランタイムエクスプローラー, リモート管理画面, SQL プロセス, ...

コオペラティブスレッド

Tokyo/2010-03-03/04


• 最終的に配分される値は常に増量されているコオペラティブスレッド

Tokyo/2010-03-03/04


• 最終的に配分される値は常に増量されている‣ Windows- realSize = requested + 40 KB

‣ Mac- realSize = requested + (requested / 2) + 128 KB


Tokyo/2010-03-03/04


• 最終的に配分される値は常に増量されている‣ Windows- realSize = requested + 40 KB

‣ Mac- realSize = requested + (requested / 2) + 128 KB

• 512 KB要求した場合, 配分されるのは:

‣ Windows では 552 KB

‣ Mac では 896 KB


Tokyo/2010-03-03/04


New process() とスタック要求値

(rs)

プラットフォーム

再定義配分値

Tokyo/2010-03-03/04


New process() とスタック要求値

(rs)

プラットフォーム

再定義配分値

0 Windows 512 KB 552 KB0 Mac 512 KB 896 KB

> 0 および < 16 KB Windows 16 KB 56 KB> 0 および < 16 KB Mac 16 KB 152 KB

> 16 KB Windows 変更なし rs + 40 KB> 16 KB Mac OS 変更なし rs + (rs/2) + 128 KB

< 0Windows

Mac変更なし

rs + 40 KB

rs + (rs/2) + 128 KB

絶対にダメ. 例えば, -128*1024 を要求した場合, 4Dは4GBを配分しようとしてしまう（符号つき/符号なしの変換）

Execute on serverに-1はNew processに0と同じ

Tokyo/2010-03-03/04


Tokyo/2010-03-03/04


• デフォルト値:

‣ '4STK' リソース

コオペラティブスレッドID 名称値1 On event call 512 KB2 On serial port call 512 KB

3Exec on server, on client, メソッド実行, マクロ 512 KB

4 メニュー新プロセス 512 KB5 サーバータスク 256 KB6 旧・バックアップ 512 KB7 旧・復元 512 KB8 Web 256 KB

9Server event loop, cache, runtime explorer

512 KB

10 アップルイベント 512 KB

Tokyo/2010-03-03/04








512 KB


クライアントグローバルプロセスのサーバーコオペラティブツイン

Tokyo/2010-03-03/04








512 KB


クライアントグローバルプロセスのサーバーコオペラティブツイン

実際の値552-896 KB552-896 KB

552-896 KB

552-896 KB296-512 KB552-896 KB552-896 KB296-512 KB

552-896 KB

552-896 KB

Tokyo/2010-03-03/04

4D Server

Operating System

Cooperatives Preemptives

Core 1 Core 2 Core 3 Core 4

Scheduler

Tokyo/2010-03-03/04

4D Server

Operating System



Scheduler

100 クライアント - 2 グローバルプロセス / クライアント　 !

サーバーのツインスレッドが占有するメモリのサイズは?

Tokyo/2010-03-03/04

4D Server

Operating System



Scheduler

100 クライアント - 2 グローバルプロセス / クライアント　 !

サーバーのツインスレッドが占有するメモリのサイズは?

258 MB(W)

300 MB(SL)

200 MB(L)

Tokyo/2010-03-03/04

4D Server

Operating System



Scheduler

100 クライアント - 2 グローバルプロセス / クライアント «Begin SQL» を各プロセスで実行した場合

!サーバーのツインスレッドが占有するメモリのサイズは?

Tokyo/2010-03-03/04

4D Server

Operating System



Scheduler



Tokyo/2010-03-03/04

4D Server

Operating System



Scheduler



458 MB (W)

500 MB (SL)

300 MB (L)


• データベースコンテキスト（トリガ• スケジューラーを理解する• スタック（メモリ）


• データベースコンテキスト（トリガ• スケジューラーを理解する• スタック（メモリ）• パラダイムシフト

Tokyo/2010-03-03/04

廃止予定

Tokyo/2010-03-03/04

廃止予定• 4D誕生から25年が経過 !

Tokyo/2010-03-03/04

廃止予定• 4D誕生から25年が経過 !

• この間に種々のコンセプトは進化した

• OSが変わった, これからも変わり続ける

‣ 68k, PPC, x86, 64Bits

‣ OS9, OSX, Carbon, Cocoa

• 4Dコードの互換性が失われてはいけない

• しかし, そうはいっても...

Tokyo/2010-03-03/04

4D Draw

Tokyo/2010-03-03/04

4D Draw

• QuickDrawを使用している

• Alturaでエミュレーション

• 座標系に整数を使用, フォント番号, 模様パターン, ...

• 現行の画像形式が開けない, 独自のフォーマットを使用

• 4D Draw文書を4Dの外部で編集する術がない

Tokyo/2010-03-03/04

SVG

Tokyo/2010-03-03/04

SVG

• CoreGraphics & CoreText, GDI+を使用

• 標準テキスト形式 (xml)

• 高度なエフェクト: グラデーション, 透明度, レイヤー, 回転, 変形, 組み込み,...

• 4Dピクチャ操作コマンドはすべてそのまま使用できる

• フォームオブジェクトとして表示や操作もできる‣ MiniDraw (v12)

• １月, SVGワーキンググループにIEチームが加入 !

•

Tokyo/2010-03-03/04

4D Open

Tokyo/2010-03-03/04

4D Open

• 4D Openは4D v11でも動作する

‣ ただしインタプリタモードのみ

• さまざまな方法で置き換えられる:

‣ HTTP- DOM Parse XML source( «http://site.com»)

‣ Webサービス

‣ SQLパススルー

‣ 複製と同期 (v12)

http://www

Tokyo/2010-03-03/04

PICT

Tokyo/2010-03-03/04

PICT

• 4DはWindowsでも画像をPICTで保存していた

• 4D v11はPICTが渡されたときだけPICTを使用する

• AppleはPICTフォーマットを廃止する予定

• 4DはAppleに頼ってMacでPICTを解読している

• 4DはAlturaまたはQuickTimeに頼ってWindowsでPICTを解読している

• CONVERT PICTUREを推奨• BLOB TO PICTURE( «.4dblob»)

Tokyo/2010-03-03/04

uickTime

Tokyo/2010-03-03/04

uickTime

• QuickTime はいまや動画処理に注力している技術

• 4D v11はQuickTimeをもはや必要とはしない

• 4D v12はImageIOおよび Windows Imaging Component (WIC) をサポート

• QuickTimeを使用するコマンドは4D v12ですべて接頭辞‘QT’が付き, 廃止予定に‣ QT COMPRESS PICTURE

‣ QT LOAD COMPRESSED PICTURE FROM FILE

‣ QT COMPRESS PICTURE FILE

‣ CONVERT PICTURE, READ PICTURE FILE, WRITE PICTURE FILEで代用

Tokyo/2010-03-03/04

ピクチャ

Tokyo/2010-03-03/04

ピクチャ• 別名で保存:

• インストールされたドライバー次第で, ほとんどのメーカーのカメラ形式をサポート

• 4D Picture形式は複数のフォーマットおよび変形を保存できる独自のコンテナ形式

Tokyo/2010-03-03/04

リソース

Tokyo/2010-03-03/04

リソース• Unicode非対応, リソースの上限は2727個または16MB

• Appleはサポートを中止, Windowsエディタ無し

• テキストはxliff, ピクチャは pngが主流

• フォームエディタとランゲージでxliffとピクチャファイルをサポート

• 4Dはいずれリソースの書き出しが不可能に

• 読み取りは当面できるはずだが, PICTリソースは無理

Tokyo/2010-03-03/04

Tokyo/2010-03-03/04

• 4DのWindows移植に一役買った技術

• 毎回の4Dバージョンアップで少しずつMac2Win依存をなくしてきた

• 互換性のためにいまだ多く依存が残されている:

‣ リソース, PICT, プラグイン

• Mac2Winを使用しているプラグインは, 依存関係を切る,

さもなければ4Dに見切られる運命...

• いまはまだAsifont.mapを使用

Tokyo/2010-03-03/04

昔のルックスSystem 7 Windows 3.11 Mac OS 9 Windows 95

Tokyo/2010-03-03/04

昔のルックス

• QuickDraw および Altura 使用のカスタムコード

• 4D 2004 で廃止予定の対象に

• 4D v13でシステムアピアランスに変換される運命

• 4D v13まで先延ばしにしないで !

System 7 Windows 3.11 Mac OS 9 Windows 95

Tokyo/2010-03-03/04

昔のルックス• 時 ,々エンドユーザーの反応が気になりませんか ?

Tokyo/2010-03-03/04

昔のルックス• 時 ,々エンドユーザーの反応が気になりませんか ?

Tokyo/2010-03-03/04

サブテーブル

Tokyo/2010-03-03/04

サブテーブル• 特殊なリレーションに変換される

• サブテーブルコマンドはすべてまだ動作する‣ 例外 SEND RECORD, DUPLICATE RECORD

• いますぐ廃止される訳ではない

• テーブルへの変換が完了するまでの猶予を設けている

Tokyo/2010-03-03/04

MODIFY SELECTION DISPLAY SELECTION

Tokyo/2010-03-03/04


• 廃止予定ではないけれど, 4Dアプリケーションがユーザーから低い評価を受けてしまう理由のひとつ

Tokyo/2010-03-03/04

Tokyo/2010-03-03/04



Tokyo/2010-03-03/04


‣ リストボックスまたはサブフォームを推奨

• 要件に合うのならばリストボックス（配列・セレクション）を使用 !

• 特殊な必要があり, リストボックスがダメならばサブフォームを使用 !


Tokyo/2010-03-03/04

ラベルエディター

Tokyo/2010-03-03/04

ラベルエディター• 4D 最古のエディターのひとつ

• PRINT OBJECT (v12) はすごく便利 !

• 新しい 4D コンポーネントを現在検討中

4D v12The Next Version

Documents

2010 in-depth-v11