特定のデータベース処理がボトルネックとなっているように思われる場合，クライアント側のリクエストログを活用できるかもしれません。このログファイルは，クライアントからサーバーに送信されたリクエスト情報が記録されています。
SET DATABASE PARAMETER(Client log recording;1)
リクエストログには，さまざまな事例に基づき，パフォーマンスと関係のあることが実証されている情報が記録されています。
v19の時点でリクエストログに含まれているのは下記の情報です。
| フィールド名 | 詳細 |
|---|---|
| sequence_number | オペレーション番号 |
| time | タイムスタンプ |
| systemID | システム識別子 |
| component | モジュール識別子 |
| process_info_index | プロセス識別子 |
| request | リクエスト識別子 |
| bytes_in | 受信バイト数 |
| bytes_out | 送信バイト数 |
| duration | オペレーション全体に要した時間 ms |
| server_duration | サーバーがリクエストの処理に要した時間 μs |
| write_duration | クライアントがリクエストの送信に要した時間 μs |
| task_kind | プリエンプティブスレッドかどうか |
| rtt | ネットワーク通信そのものに要した時間 μs |
リクエスト識別子のニーモニックはGitHubで公開されています。v20では14000番台にRESTリクエストが追加されました。
リクエストログのファイルサイズは，クライアント/サーバー間のネットワークトラフィックが妥当な範囲に収まっているかどうかのバロメーターとみなすことができます。
わずかなバイト数のリクエストが大量に送受信されている場合，通信の回数をもっと抑えるよう，プログラムを見直すことが必要かもしれません。
リクエストの処理に要した時間と通信そのものに要した時間を突き合わせることにより，通信設備やハードウェアのスペックが充分かどうかを見定めることができます。
コオペラティブスレッドのリクエストが相当な割合を占めている場合，プリエンプティブスレッドをもっと活用することでパフォーマンスを向上できる見込みがあります。
リクエストログはサーバー側で記録することもできます。
SET DATABASE PARAMETER(4D Server log recording;1)
v19r5 Hotfix 2では，サーバー側のリクエストログがテーブルに関わるものだった場合，extra項目にテーブル名が記録されるようになりました。
| - | - | - | - | - | - | - | - | - | - | - | - | extra |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 60 | - | - | ‘srv4’ | 5 | 71 | 11 | 4 | 1127 | 34 | c | 1000 | |
| 61 | - | - | ‘INFO’ | 5 | TTF/i | 0 | ||||||
| 62 | - | - | ‘dbmg’ | 5 | 11041 | 362 | 62 | 1132 | 65 | c | 1000 | Table_1 |
上記の例では，[Table_1]のトリガがコオペレティブモードで実行されていることが確認できます。
リクエストログは，クライアント/サーバーのネットワーク通信に焦点をあてたログファイルです。4Dには，他にもさまざまなデバッグツールが用意されています。
公式サイトのダウンロードページには，簡潔な最小動作環境およびソフトウェアとハードウェアの必要環境の詳細のURLが掲載されています。ハードウェアについては，クライアントは2コア以上，サーバーは4コア以上のCPUを搭載しているコンピューターが推奨されています。
Client computers must have a minimum of a 2 core CPU, while servers should have 4 or more cores.
推奨されているCPUコア数やメモリの容量はひとつの目安です。実際には同時接続ユーザー数・アプリケーション設計・データファイルのサイズといった要素を考慮に含める必要があります。
クライアントのコア数として2が推奨されている背景には，アンチウイルスなどのセキュリティソフトの存在が関係しています。多くの企業では，損害保険上の必要事項としてセキュリティソフトをインストールすることが要求されていますが，大抵の場合，バックグラウンドで動作するそのようなソフトはCPUコア1個をほぼ占有するので，4Dを快適に使用するためには少なくとも2個のCPUコアが望ましいと考えられています。
アプリケーションの設定やプロセス処理の方法にもよりますが，4D Serverは，ORDA・DB4D・HTTP・SOAP・SQLなどリクエストをプリエンプティブモードで並行処理することができるので，4コア以上が推奨されています。
v19r7以降，Webサーバーにアクセスするとステータスコード429 Too many requestsが返されることがあります。これは，Webサーバーを外部に公開するライセンスがインストールされていない場合に返されるエラーです。
v19r3以降，4Dには，OAuth2認証を容易にする4D Netkitコンポーネントがプリインストールされています。OAuth2認証は，Microsoft 365のようなWebサービスで採用されています。Microsoft 365の場合，POP3やIMAPプロトコルの 基本認証が廃止されたことに伴い，ユーザー名とパスワードによるログインができなくなりました。
OAuth2認証をするためには，Webサービスのプロバイダーからトークンと呼ばれる情報を受信するためにWebサーバーを開始する必要があります。4D Netkitも例外ではなく，OAuthトークンを受信するためにコンポーネントのWebサーバーを利用しています。クライアント側でOAuth2認証するためには，クライアント側のWebサーバーを使用します。
v19r7以降，4D NetKitでWebサービスのOAuth2認証ができるようにするため，Webサーバーを外部に公開するライセンスがインストールされていなくても，1分間に数回の制限内でHTTPリクエストが処理できるよう，仕様が見直されています。この状況でWebサーバーを外部に公開することはライセンスで許可されていません。限度を超えたリクエストを受け付けた場合，サーバーはステータスコード429 Too many requestsを返します。
v20では，クライアント/サーバー通信テクノロジーのアップグレードが計画されています。次世代のネットワークレイヤーは，現在公開中のベータ版で試験的に有効にすることができ，v20 LTS（Long Time Support）の正式リリースでは全面的に無効化され，v20 Rバージョンで選択的に有効化できるようになります。その後，v21で標準のネットワークレイヤーが切り替わる予定です。
この記事では，次世代ネットワークレイヤーについて説明します。
初期の4D Serverは，ネットワークコンポーネントをインストールすることにより，IPX/SPX・TCP/IP・ADSPいずれかのネットワークプロトコルで4D Clientから4D Serverに接続することができました。4D Client以外のアプリケーションから4D Serverに接続するための4D Openも同じネットワークコンポーネントを使用します。その後，v2003ではプロトコルがTCP/IPに一本化され，本体に組み込まれたことにより，コンポーネントを別途インストールする必要がなくなりました。
v11 SQLでは，Unicodeモードや同時接続クライアント数の増加といった課題に対応し，通信レイテンシーをできるだけ抑えるため，TCP/IPネットワークレイヤーが全面的に新しくなりました。この世代のネットワークレイヤーは，下記のような特徴を備えています。
19813，後者は19814クライアントがサーバーに接続すると，通信用の主要なソケットを維持するためのアプリケーションプロセス Main process がクライアントとサーバーの双方で作成されます。同じようにクライアントが新規プロセスを起動し，サーバーにアクセスしようとすると，適宜，サーバー側にもユーザープロセスが作成されます。終了したプロセスはTCP接続を再利用できるようにしばらくプールされますが，やがて破棄されます。なお，クライアントがサーバーに接続すると，サーバーからクライアントにメッセージを送信するためのクライアント管理プロセス Client manager process も作成され，専用のソケットが開かれます。クライアントは内部タイマープロセス Internal timer process でこのソケットを定期的にチェックします。アプリケーションサーバーとは，ユーザー認証・リソース管理・ストアドプロシージャー・命名セレクション・セット・サーバー側プロセス変数に対するアクセス・サーバー管理・デザインモードのオブジェクトロックなど，全般的なクライアント/サーバー通信に使用されるプロセス群の総称です。
今では旧式ネットワークレイヤーと呼ばれるこのテクノロジーは，従来のクライアント/サーバーと比較した場合，TCPパケットのサイズがおおきく，数つまり頻度が少ない傾向にあります。細かい設定は，データベースパラメーターつまりデータベース設定で調整することができます。特に重要なのはクライアント/サーバーの接続タイムアウトです。
クライアントは，タイムアウトの1/3が経過するたび，いわゆる ping を送信します。サーバーとの通信に失敗した場合，ネットワーク接続に障害が発生したものと判断し，エラーが返されます。
上記のタイムアウトはクライアント/サーバーアプリケーションの通信つまりポート番号19813に適用されます。データアクセスには適用されません。19814ポートのソケットは常に開かれた状態であることが前提なので，ルーター機器などが無活動のソケットを閉じるようになっている場合，しばらくのアイドル時間を経てからクライアントがサーバーのデータベース（DB4DまたはSQL）にアクセスするとエラーが返される恐れがありました。アイドル時間タイムアウトは，データベースパラメーターで調整することができます。
v15では，旧式ネットワークレイヤーの弱点を克服し，スリープ検出やシングル・サイン・オン（クライアントはログイン画面を表示せず，Windowsのログインアカウントでサーバーに接続する）といった要望に応えるため，改良されたTCP/IPネットワークレイヤーが利用できるようになりました。ServerNetとも呼ばれる新ネットワークレイヤーを有効にすると，さまざまな先進的な機能が利用できるようになります。
新ネットワークレイヤーでは，前述したデータベース設定に関係なく，クライアント/サーバーの接続タイムアウトが「なし」となります。
ServerNetは，当初，Mac 64-bit版では必須，Windows 32-bit版では任意のデータベース設定でしたが，v17以降，Mac 64-bit版でも旧式ネットワークレイヤーが選択できるようになりました。
旧式ネットワークレイヤーは豊富な実績があり，長年，世界中の4D Serverで使われてきましたが，1個の接続に要するスレッド数が多く，全体として多くのメモリを消費する設計でした。たとえば，サーバー側で1000プロセスを管理するためには4000以上のスレッドが必要です。コンテキストを切り替えたり，メモリを確保したり，スレッドを作成したりするたびに多少の遅延が発生します。特にv11からv13のMac版は32-bitアプリケーションゆえに利用できるメモリが限られていたため，サーバー側のプロセススタックを少しでも節約できるよう，データベースパラメーターが用意されました。
旧式ネットワークレイヤーは長年の保守によって高度に複雑化し，大規模なシステムだけで発生するような特殊な現象を調査することが困難な状況になりつつあったので，v14のRバージョンではすっきりした設計の新ネットワークレイヤーが開発され，漸進的に改良されることになりました。
新ネットワークレイヤーは，軽量かつ高性能を目指して開発されましたが，処理の内容次第では，旧式ネットワークレイヤーのほうがパフォーマンス面で優れていることがあります。とはいえ，旧式ネットワークレイヤーよりも詳細な診断ログを記録するように作られていることも手伝って，バージョンを追うごとに安定性と速度が向上し，v19のRバージョンでは，非常に高い完成度に到達しました。
では，なぜ再びここでネットワークレイヤーを見直すことになったのか，と疑問に思うかもしれません。
上述したように，4Dのネットワークレイヤーは，初代（v3からv2004）・旧式（v11からv15）・ServerNet（v15からv19）いずれもTCP/IPプロトコルをベースに4Dが独自に開発したものです。一方，業界ではTCPを使用しない，QUICが注目を集めています。
4Dデベロッパーの頭を悩ませてきたエラー（ヌル終点・接続エラーなど）のほとんどは，TCPソケットの仕様から切り離せないものです。そのため，不安定なネットワーク環境でも簡単には切れないクライアント/サーバー環境を構築するために実績の豊富なQUICが4Dのネットワークレイヤーに採用されることになりました。ServerNetと同じように，段階的に改良を重ねられるよう，移行期間が設けられます。
QUICはネットワーク障害に強く，TLS 1.3以上の暗号化で保護されていながら，効率的で高速である，という特徴を有しています。これまでのように4D側で複数のポート番号と多数のソケットを開いたままにして使いわけるのではなく，単一のUDPポート（やはり19813）を介してすべての通信をするというシンプルな設計も魅力です。v20のベータ版ではQUICネットワークレイヤーをプレビューすることができますが，運用では安定したServerNetを使用することが推奨されています。v20のLTSでQUICが無効化されるのはそのためです。QUICネットワークレイヤーは，v20のR3ないしR5から利用できるようになる見込みです。
関連記事:
V20 QUIC network layer: a successor to the “New” Network layer
VP Convert from 4D Viewは4D Viewプラグインで作成したドキュメントをView Proスプレッドシートに変換するコマンドです。フィールドに対する単純な参照は対応するView Proスプレッドシートのフォーミュラに変換されますが，文字列とフィールドを組み合わせたフォーミュラは変換されません。これは仕様です。
ハイライトボタンは，バイナリモードにだけ存在する旧式のフォームオブジェクトです。ハイライトボタンが配置されたフォームをプロジェクトモードに変換した場合，ハイライトボタンは透明ボタンになります。ボタンにヘルプTipsが設定されている場合，自動的に On Mouse Move イベントが有効となることにも留意してください。透明ボタンは画面にレンダリングされないため，ヘルプTipsを表示するためにはマウス移動イベントを有効にする必要があります。これは仕様です。
Mac版の4D v19は，Universal 2バイナリ形式で提供されており，x86_64とApple Silicon（ARMアーキテクチャ）のどちらでもインタープリター版のストラクチャをネイティブアプリとして実行することができます。
4DのコンパイラーはIntel（AMDアーキテクチャ）のコードを生成するように設計されていますが，MacにXcodeがインストールされていれば，メソッドのソースコードを clang コンパイラーに生成させることにより，Apple Siliconターゲットのアプリケーションをビルドすることもできます。
clang コンパイラーを利用してApple Siliconターゲットのコンパイルが実行できるのは，プロジェクトモードだけです。バイナリモード，つまり .4DB というファイル拡張子を持つストラクチャファイルをXcodeでコンパイルすることはできません。
互換性のために残されているバイナリモードでアプリケーションを開発している場合，データベースをプロジェクトモードの変換するか，IntelターゲットのアプリケーションをビルドしてRosetta 2で4Dを起動するか，コンパイルせずにインタープリターモードでアプリケーションを運用するか，よく検討した上で決定することになります。一旦，変換したストラクチャをバイナリモードに戻すことはできません。
初期の4Dはコンパイルすることにより大幅な速度の向上が望めましたが，現在ではインタープリターモードでも快適に動作しますので，さほどパフォーマンスに差はないと考えられています。
4DはRosetta 2でサポートされていない特殊な実行ファイルではありませんが，AppleはRosetta 2トランスコーダーの詳細を公開していないため，RosettaモードでIntelやApple SiliconネイティブのMacと違う振る舞いをする可能性がないとは言えません。問題があるとすれば，浮動小数点演算など，CPUに対する直接的な命令の実行でしょう。たとえば，4Dで0による整数除算（%演算子）を実行した場合，通常はエラーが返されませんが，Rosettaコンパイルモードではエラーが返されます。0による除算は正しい結果が定義されていないので，Rosettaの実装による違いであり，4Dの不具合ではありません。なお，コンパイルの対象となる演算子を記述せず，同等の演算をするMod関数を実行すれば，インタープリターモードと同じ振る舞いになります。これは仕様です。