　FileMaker って、、、あれかなぁ

2015-12-11

iSCSI を利用したFileMaker Server の冗長構成を考える

　先日の記事で、FileMaker Server 14 オリジナルのスタンバイサーバ機能のテスト環境構築方法についてご紹介しましたが、このスタンバイサーバ機能には、以下のような問題点があります。

プライマリからスタンバイサーバへの切り替えはコマンドライン入力が必要で面倒で、誤操作が発生する可能性がある
前回保存以降（0～99分間）のデータが失われる

　そこで今回は、上記のスタンバイサーバ機能の代わりに、プライマリ/スタンバイサーバでiSCSIディスクを共有するように設定し、障害時にはサーバ切替を行う冗長構成を考えてみました。

尚、本稿でもプライマリサーバの代替機という意味でスタンバイサーバという言葉を使用しています。前稿のFileMaker Server 14 オリジナルのスタンバイサーバ機能と混乱しないようにご注意ください。

注意点：

　本記事でご紹介する操作は、動作を保証するものではありません。
　実運用前に社内で入念な動作検証を行い、お客様の責任で導入をお願いします。

　前回構築した仮想マシン二台を流用した iSCSI ドライブ共有モデルがこちらになります。

iSCSI ドライブの共有によるデータベース公開モデル
平常時はスタンバイサーバはiSCSIドライブには接続せず、プライマリサーバがダウンした時にのみ接続する

iSCSI ターゲットに配置されたデータベースファイルを FileMaker Server で公開することによって、緊急時にはスタンバイサーバから同じデータベースファイルにアクセスできるようにします。
　※スタンバイサーバ側は、初回導入時にプライマリサーバと同様に iSCSI ドライブ内のデータベースを公開できるように設定します。設定後に iSCSI ドライブを切断するため、上図では接続状態を黄色の矢印で示してあります。

プライマリサーバの設定：

　iSCSIターゲット上でデータベース専用ドライブを作成し、プライマリサーバ上にマウントします（下図のEドライブ）。

　このとき、FileMaker Server 14 アプリケーションはCドライブにインストールし、データベースファイルはすべて iSCSI ドライブ（Eドライブ）に配置します。

　たとえば、下図のように iSCSI ドライブを E: ドライブとしてマウント。その中に FmData フォルダを作成して、この中に FileMaker データベースファイル群を配置します。

次に FileMaker Server Admin Console を使用し、上記で作成したデータフォルダが公開されるようにそのフォルダのパスを指定します。

　下図では、filewin:/E:/FmData/ が公開されるように設定しています。
　また、データベースファイル破損時に備えて、バックアップはローカルディスク上に取っておきます。

スタンバイサーバーの設定：

　プライマリサーバで iSCSI を切断し、FileMaker Server を停止させます。
　プライマリサーバの設定内容と同様にスタンバイサーバの設定を行います。

　※ プライマリサーバの FileMaker Server の動作競合や、iSCSI ディスクへの書き込みエラーを防止するために、スタンバイサーバの設定が終わったら FileMaker Server を停止させて iSCSI 接続を切断しておきます。
　iSCSI の切断後は、スタンバイサーバをシャットダウンします。

正常時の操作

　普段はプライマリサーバのみ稼働させておきます。

プライマリサーバ稼働時の iSCSI 接続状態

緊急時の操作

　プライマリサーバのメンテナンスが必要になったり、プライマリサーバに障害が発生したりした場合は、FileMaker Server を停止させて iSCSI ドライブへの接続を切断します。

　そして、スタンバイサーバから iSCSI ドライブへ接続後に、FileMaker Server を起動します。

スタンバイサーバ稼働時の iSCSI 接続状態

ポイント：
　― FileMaker Server 14 のサーバ切替コマンド操作が不要な分、サーバのダウンタイムは短縮できますが、プライマリサーバの iSCSI 切断、スタンバイサーバの iSCSI 接続と FileMaker Server 起動までの操作は手動作業になります。

　― スタンバイサーバはプライマリで運用していたファイルを直接引き続くため復旧時にデータロスは発生しませんが、iSCSIターゲット（ディバイス）の堅牢性が要求されます。RAID6やRAID10などの採用を検討してください。

　― FileMaker Server 14 以前の FileMaker Server にも応用できます。

とっても重要：

　フルバックアップ及びプログレッシブバックアップにより作成されるバックアップファイルは iSCSI ディスク上ではなく、ローカルディスク及び外部メディアに取ることをおすすめします。

　これにより、iSCSI ターゲット自体が故障した場合に、ローカルディスクにあるバックアップから復旧作業を行えます。
　また、ローカルディスクも同時に損傷しまった場合にも、外部メディアから復旧する手段が残ることになります。

【関連する土屋企画の講習】
FileMaker Server とバックアップ(対象者：中級、5時間×1日)

（亀）

2015-12-09

Hyper-V VMを使用しFileMakerスタンバイサーバーのテスト環境を構築する

　FileMaker Server 14 でスタンバイサーバーが導入されたことにより、システムメンテナンス時や障害時にもすみやかに FileMaker データベース作業を再開できるようになりました。

　スタンバイサーバー - 概要

　プログレッシブバックアップを利用した現用系（プライマリ）と予備系（スタンバイ）のサーバ切替が可能になった分、突然のデータロスの可能性を低減できることは大きいと思います。

　しかしながら、切替制御が自動でないため、人為作業がどうしても発生してしまう点や、緊急時に FileMaker Server 管理者が対応不能の場合に作業が一時中断してしまう点などの問題は残りますので、緊急時の作業規則をあらかじめ社内で決めておくことが大切です。

　今回は、Windows OS で FileMaker Server 14 のスタンバイサーバー機能の動作検証を行いたい方のために、スタンバイサーバーのテスト環境を Hyper-V の仮想マシンを使って手っ取り早く構築する方法をご紹介します。

Hyper-V 上の仮想マシン（VM）のイメージ ― 1台のホストOS上で複数のVMを運用する

準備するもの

1. Hyper-V サービスがインストールされたコンピュータ 1 台
　今回は Windows Server 12 を使用しています。

2. FileMaker Server 14 が動作する Windows Server ライセンス 2 つ
　今回は Windows Server 2008 R2 を使用しています。

3. FileMaker Server 14 ライセンス 1 つ
　スタンバイサーバーを構成する場合、必要な FileMaker Server 14 のライセンスは1つのみです。

Hyper-V 環境の構築方法

1. 一台めの仮想マシンを作成してから仮想ハードディスクを接続します。
　その後、Windows Server OS と　FileMaker Server 14 をインストールし、必要なデータベースファイルを Data/Databases ディレクトリの中に入れておきます。

新規仮想マシンと Windows Server OS および FileMaker Server 14 のインストール

ポイント：
　― Windows Server の IP アドレスを正しく設定し、Windows 認証を済ませておきます。
　― FileMaker Server 14 をインストールしたら、すぐにプログレッシブバックアップ設定をしておきます。

　このとき、プログレッシブバックアップ先のパス名の指定を忘れないようにしてください。
　上図では便宜的に filewin:/C/FMSProgBkup/ を指定してあります。

2. 一台めの仮想マシンをシャットダウンします。
そして、仮想マシンから仮想ハードディスクを削除（切断）します。

仮想マシンから仮想ハードディスクを切り離す

3. 仮想ハードディスク1 (VHD1) を複製して仮想ハードディスク2(VHD2=スタンバイサーバー用VHD）を作成します。
Windows Server OS と FileMaker Server 14 がインストールされた状態の仮想ハードディスクを複製するため、インストール作業の二度手間を大幅に省くことができます。

仮想ハードディスクを複製する

4. 一台めの仮想マシンに仮想ハードディスク1(VHD1)を再接続し、無事に起動してきたら、二台めの仮想マシンを新規作成し、仮想ハードディスク2(VHD2)を接続し、同様に起動します。

仮想マシンを新規作成して、二台の仮想マシンを稼働させる

ポイント：
　― Active Directory に参加しているサーバを複製した場合は、二台めのサーバはドメインに参加できなくなります。
　このため、一旦ローカルログインし、IP アドレスの変更、コンピュータ名の変更、ワークグループへの切り替えを行ったあとで仮想マシンを再起動し、再度 ActiveDirectory に参加するようにする必要があります。

参考記事：ドメインにログインできなくなって泣かされる

　― Windows OS は新たに仮想ハードディスクを接続すると、Windows 認証作業が必要になります。
　　ボリュームライセンス利用者の場合は、「自動ライセンス認証が始まるまで XX　日です。今すぐ行う場合はここをクリックしてください」をクリックし、指示どおりに操作します。

　シングルライセンス利用者の場合は、「プロダクトキーの変更」をクリックして、二台めの Windows ライセンスを入力します。

　― FileMaker Server 14 のプログレッシブバックアップの設定はプライマリサーバと共通になるので作業は不要です。FileMaker Server に付ける名前だけ変更すれば OK です。

FileMaker Server 14 スタンバイサーバーの設定方法

1. プライマリサーバの公開済データベースを全部閉じます。

　コマンドプロンプトから以下のコマンドを入力します。

fmsadmin standby connect スタンバイサーバーの名前または IP アドレス

　接続およびログインに成功すると、8桁のセットアップコードが表示され、待ち状態となります。
　このセットアップコードをメモしておきます。

2. スタンバイサーバー側でコマンドプロンプトを開き、以下のようにセットアップコードを入力します。

fmsadmin standby accept XXXXXXXX

ログイン成功後、スタンバイサーバー切替のメッセージが出るので y を選択後、ログインします。

3. プライマリサーバに戻り、待ち状態のコマンドプロンプトで Enter キーを押すとスタンバイサーバーへの接続が完了します。

ポイント：
　― スタンバイサーバーでセットアップコードを入力して受理されたものの、セットアップコードが不正だった場合は Enter キーを押すとエラー終了になります。この場合は、手順 1. のコマンド入力からやり直してください。

4. プライマリサーバのコマンドプロンプトで、以下のコマンドを入力します。

fmsadmin standby update

　ログイン成功後、プライマリサーバのデータベースがスタンバイサーバーの公開データベース環境にコピーされます。

5. プライマリサーバのデータベースを再度公開します。

　すると、プライマリサーバとスタンバイサーバーのデータベース同期が行われるようになります。

　このとき、スタンバイサーバーの FileMaker Server Admin Console を開こうとすると、以下のように待機状態であることが確認できます。

　スタンバイサーバーのさらに詳しい設定方法および、スタンバイサーバーの動作確認方法（メンテナンス時、障害発生時のサーバ切替）は、FileMaker 社の公式動画がおすすめですので、ご覧になってみてください。

おまけ： FileMaker Server 14 プライマリサーバとスタンバイサーバの同期関係を解除する方法

　これまで、FileMaker Server 14 でプライマリサーバとスタンバイサーバーで同期が取れるように設定しましたが、逆に同期を解除したいという要望も出てくることでしょう。

　そのようなときは、プライマリサーバ側でコマンドプロンプトより以下のように切断コマンドを入力します。

fmsadmin standby disconnect

　本当にスタンバイサーバーを切断してよいかと聞いてきますので、y を選択し、ログインすると、スタンバイサーバーとの接続が切断されます。

　これにより、今までスタンバイサーバーだった FileMaker Server 14 はスタンドアロンサーバとして動作するようになります。

以上

（亀）

FileMaker バックアップ関連記事：

データベースのバックアップ方法
FileMaker Server のプログレッシブバックアップ機能の考え方と使い方

Hyper-V 関連記事：

Hyper-V の仮想マシンの移行方法（エクスポート＆インポート）
Hyper-V の仮想マシンのエクスポート時の注意点
物理マシンを Hyper-V 仮想マシンに移行する（P2V）
Hyper-V のゲスト OS を起動しようとすると、「一般のアクセスが拒否されました」というメッセージが表示される
計画停電対策(1) --- ノートPCサーバとHyper-Vで乗り切る

【関連する土屋企画の講習】
FileMaker Server とバックアップ(対象者：中級、5時間×1日)

2015-06-25

新WebDirectのパフォーマンスについてあれこれ

　FileMaker 13 の WebDirect (以下、WebDirect 13) と比べ、FileMaker 14 の WebDirect (以下、WebDirect 14) のパフォーマンスはどれだけ向上したのか？実用に耐えるレベルになったのか？
　WebDirect 14 の導入を検討するにあたり、これはとっても気になるところです。

　FileMaker 社の公式サイトでは、WebDirect の起動スピードは以前より 25% 向上していると謳ってはいます。また、独自にパフォーマンスの比較検証を行って公開している方（会社）もおいでで、そうした情報はとっても貴重です。

　ということで、パフォーマンスについて情報を公開している方の情報を例によって渉猟してみました。　（あと、人様の情報を紹介させて頂くだけでは申し訳ないので、弊社でも WebDirect のパフォーマンスの検証をしてみました。）

米国 FileMaker 社（パートナー）が公開している YouTube ビデオ

　かの有名な Richard Carlton Consulting Inc. の FileMaker Training Videos Channel という動画です。

　WebDirect関連のビデオでは「第一部：FileMaker WebDirect 14 のご紹介」、「第二部：WebDirect の最適化方」の 2 本が公開されていますが、その中からパフォーマンスに関する情報を拾って要約しました。

「第一部：FileMaker WebDirect 14 のご紹介」　Introduction to FileMaker WebDirect 14

　WebDirect がモバイル対応になったことを中心に、パフォーマンス面も向上していることについて触れています。

パフォーマンスに関する重要ポイント（リンクはタイムスタンプ）：

11:30 今回のリリースで WebDirect の全面書き換えが行われたことにより、実行速度が格段に向上している。
13:40 WebDirect 14 によるレコード移動時の表示速度デモ
15:13 WebDirect 13 vs WebDirect 14 レコード移動速度比較
16:54 WebDirect 14 のタブキー操作によるレイアウトフィールド移動は、WebDirect 13 に比べると 2倍は速くなっている。
20:02 デスクトップ版 WebDirect 14 は、 WebDiredt 13 に比べると 2-3 倍動作が速い。Android モバイルに至っては 10-20 倍速くなっている！（WD13はAndroidには正規対応していないのですが、Richardさんは独自の方法でチェックされたようです。但し、この部分は動画にはありません。）。
27:28 WebDirect は ChromeBook の動作保障をしていないが、自己検証ではサクサク動いた。

（動画は英語）

　特に　15:13 あたりの WebDirect 13 vs WebDirect 14 レコード移動速度比較実験は必見！
　ウィンドウを左右に並べて比較しているので、速度が向上していることは一目瞭然にわかります。

「第二部：WebDirect の最適化」　Optimaizing Solutions for FileMaker WebDirect 14

　2013年の Richard Carlton Consulting Inc. の FileMaker 13 WebDirect Overview and Optimization Presentation と基本的な流れは同じですが、 WebDirect 14 に関する情報にも触れられています。

パフォーマンスに関する重要ポイント（リンクはタイムスタンプ）：

17:55 *.fp7 ファイルを FileMaker Pro 14 フォーマット(*.fmp12) に変換した直後のレイアウトサイズは 850kb。
これを予め登録した共有スタイルで最適化させると 425kb までサイズダウン。
サイズが約半分ということは、転送速度が約2倍になっているといえる。
18:49 FileMaker Pro 14 に付属のストーンテーマのスタイルを極力いじらずに同様のレイアウトを作成した場合は、225kb までスリム化できた。
19:55 WebDirect 13 で共有スタイルで最適化したレイアウトサイズは 480kb だったが、 WebDirect 14 で同様の作業を行うと 425kb で、約15% スリム化されていることがわかった。

（動画は英語）

　今回は WebDirect のパフォーマンス比較がわかるところのみを中心にご紹介していますが、ビデオの中では以下のようなことにも触れています。

WebDirect 13 の最適化ビデオと重なる情報は省いてあります。より詳しい情報をご覧になりたい方は、FileMaker 13 WebDirect Overview and Optimization （英語）をご覧いただくか、弊社記事 WebDirect 開発の勘どころをご覧ください。

画像について

　ｊpeg, png などの画像利用は最小限にする。
　FileMaker Pro 14 には軽量の SVG ビルトイン画像（glyph）が用意されているので、これを使ってボタンアイコンを装飾することを検討。
　※SVG = スケーラブル・ベクター・グラフィックス

タブ・スライドコントロールについて

　タブ、スライドコントロールの使用もできるだけ避ける。
　必要のない情報をロードさせないのが基本。
　タブコントロールを配置するれば、裏でタブ上のすべての情報がロードされることに注意。

ポップオーバーについて

　FMP13 で導入されたポップオーバーも要注意。
　ブラウザに別ウィンドウを表示させる代わりに使えるが、多用は避けること。
　裏であらかじめすべてのポップオーバーデータをロードすることには変わりはない。

スクリプトトリガについて

　WebDirect 側にはスクリプトエンジンが搭載されていない。
　このため、イベントが発生するたびに FileMaker Server にアクセスして処理を決定する。
　当然、スクリプトをトリガさせるイベントがたびたび発生すれば、その分のトラフィックが増加する。
　このトラフィックコストはできるだけ少なくした方がよい。

FileMaker WebDirect 14 のパフォーマンス最適化については、「FileMaker 14 WebDirect ガイド」の 14 ページ「ステップ 3: パフォーマンスの最適化」（PDF）にヒントが掲載されています。こちらも併せて読むと、参考になると思います。

土屋企画による WebDirect パフォーマンス検証

小社でも『FMEasy在庫 IWP/WD R1.5』という製品を使い、社外と社内の2つのサーバでテストをしていました。

■実行環境
社外：米国某ホスティングサービス(VM/共用タイプ)、16 GB RAM/Xeon E5 4 cores
社内：自社サーバ（VM/占有タイプ）、4GB RAM/core i7（4プロセッサ割り当て）
FileMaker Server： Ver14.0.2（サーバ1/サーバ2共に）
使用ブラウザ：主としてIE10、IE11
注：VM＝仮想マシン

■テスト内容
　予め、連続ビュー、連続更新、出庫伝連続伝票作成、という3つのループスクリプト（後述）作っておき、5～10個のブラウザウインドウからこれらのスクリプトを実行しています。
　で、こんな感じになります。

　上図は、1台のPC上で10個のIE10ブラウザウインドウを開き、ループスクリプトを実行していますが、Remote Desktop （RDT）で複数のセッションを開き、それぞれのセッションで1～複数のブラウザウインドウを開いてループスクリプトを実行というテストも行っています。
　後述の「■テスト」の項では、＜社内/1PC/複数ブラウザ＞、＜社外/複数RDT/1ブラウザ＞などと表記しますが、前者は社内サーバに1台のPCから複数のブラウザウインドウを起動しアクセス・テスト、後者は社外サーバに複数のRemote Desk Top から1つのブラウザウインドウを起動してアクセス・テスト、を表しています。

■ループスクリプトの内容
1. 連続ビュー
上図の出庫画面で先頭レコードから1件づつ後方へ移動していく。移動直後に0.2～1秒ポーズし、50～100件目に到達したらメッセージを出して終了する。

2.連続更新
上記の連続ビューと基本は同じだが、移動直後に備考フィールドに実行時の日時を追記する。

3.連続伝票作成（クライアントサイド）
出庫伝票形式のデータを連続して100件作る。といっても、1出庫レコードには25の出庫明細レコードが付属しているので、このスクリプトを1回実行すると、出庫レコード100件+出庫明細レコード2500（25明細×100）件、計2600のレコードが作成される。

4.連続伝票作成（サーバサイド）
仕様は上記4同じだが、サーバサイドスクリプトで実行。

■テスト
1.連続ビュー　＜社外/1PC/複数ブラウザ＞
10個のIE10ブラウザウインドウで連続ビューを実行し、すべてのブラウザでエラーなく成功。

以下の動画は、撮影の都合上、6つのブラウザで実行しています。

2.連続更新
2-1　連続更新　＜社外/1PC/複数ブラウザ＞
10個のIE10ブラウザウインドウで連続更新を実行し、全てで成功。但し、上記1よりは時間がかかる。

2-2　連続更新による影響　＜社外/複数RDT/1ブラウザ＞
6つのRDTで1つのブラウザを起動し、それぞれで連続更新スクリプトを実行させた後、ローカルでブラウザを起動し、テスト実行者が手動によりレコード移動や入力を行いました。　これは、他のユーザが入力作業をしていると、どのような影響を受けるかシミュレートしたものです。結果は以下の通りです。

6つのRDTの連続更新は時間はかかるもの成功します。
ローカルのブラウザでは入力は成功するものの、レコード移動ボタン（＞アイコン）を数回クリックすると、サークルアイコンが現れ操作ができなくなる現象が頻発します。数分待つと画面が表示されますが、これでは実用に耐えないレベルです。

2-3　連続更新による影響　＜社内/複数RDT/1ブラウザ＞
上述の2-2 と同様テスト内容を社内サーバで実行したときの模様です。

今回は、ローカルで新規レコード入力操作中にサークルアイコンが現れ、その後 15 分経過しても状況が変わらなかったため、テストを中断しました。
このサークルアイコンが現われ操作不能になる現象は今回のループテスト実行中に何回も発生しました。　サーバ性能を上げるとこの現象は緩和されるのかもしれませんが、性能を上げたとしても FileMaker Pro 並みの安定運用を行うのは厳しいのではないかと思われます。

2-4　連続更新を24セッションで実行＜社内/複数RDT/複数ブラウザ＞
4つの RDTクライアントでそれぞれ5つのIE10ブラウザウインドウを開き、さらにローカルで4つのIEブラウザウインドウを開いて（計24セッション＝4×5+4）て連続更新スクリプトを実行。成功したのは24セッション中9、残りの15セッションはサークルアイコンが出現し制御不能に。

3.連続伝票作成（クライアントサイド）　＜社外/1PC/1ブラウザ＞
1つのIE10ブラウザウインドウで成功。所要時間は43秒。但し、再度実行すると、ブラウザが反応しなくなる（下図）。

4. .連続伝票作成（サーバサイド）　＜社外/1PC/1or 5ブラウザ＞

1つのIE10ブラウザウインドウで数秒で成功。~~但し、実行直後から全くブラウザが反応（上図と同様）しなくなることがある~~。
バグを修正したところ、上記打消し線部の問題は解消。　5つのブラウザウインドウ上で本スクリプトを同時実行したところ正常終了。さらに、続けて5つのブラウザで同スクリプトを実行したところ、こちらも問題なく終了。
※バッチ処理は実行速度と安定性から、利用可能であればサーバサイドスクリプトを利用するのが良い

※　今回のテストを通じて思ったこと　―　WebDirect導入時の注意点

複数のブラウザでループスクリプトを実行しても（動作は遅くても）比較的に安定して動作する。
ユーザが＜や＞（レコード間移動）ボタンを手動で実行すると、サークルアイコンが延々と表示され、場合によっては操作不能になことがある。＜や＞　を連続押しすると、この現象は高い頻度で発生する。
レコードの連続作成スクリプトをクライアントサイドで実行すると、そのスクリプトは正常に終了したにも関わらず、次の操作が不能になる（サークルアイコンが出っ放し状態）になることがある。
サーバサイドスクリプトが実行できる状況であれば、使う

上述のように上記のテストは海外のサーバを使用して行っていることにご注意ください。上記2の現象に関し、WinMTR の結果をホスティング会社に送付し問い合せたところ、「some severe packet loss and latency from you location in Japan to our location」とのことでした。　ただ、サークルアイコン出っ放し状態の時でも、FileMaker Pro によりサーバにアクセスして＜あるい＞をクリックすると、速度は遅いものの正常に動作すること、社内サーバを使用してもサーバへの負荷を高めるとサークルアイコン出っぱなし現象が発生することからみて、WebDirect にはまだ問題があると思います。
　~~尚、小社のLAN内のWebDirect環境では、ブラウザの　＞または＜　ボタンを連続押ししても、上記の問題は発生していません。~~

　以上のことから、WebDirect の導入に際しては、サーバ性能（メモリ/CPU）に加え、ネットワーク環境にも十分注意を払う必要があります。実際の運用環境にできるだけ近い環境を用意し、事前に十分なテストを行うことも必要でしょう。　またテストを行う際も精度の高いプロトタイプを用意し、十分な実行速度が確保できるかもチェックしたいところです。ブラウザ上の＜と＞（ナビボタン）を非表示にしたり、短い間隔で連続実行できないようにするなどの工夫も必要かもしれません。　導入担当者または開発者は、サークルアイコンの地雷を踏まぬよう、十分注意しましょう。

注：
「社内サーバのスペックが低すぎるのがサークルアイコンの原因だろ？」とお思いの各位、御尤もです。メモリたっぷりなサーバを調達してテストしてみたいです。　ただ、サーバ性能が低いにしても、サークルアイコン出っぱなしはオカシイと思います。

WebDirect のパフォーマンスに関するその他の情報

　バージョン間での WebDirect パフォーマンス比較を実際に行っている開発者は残念ながらまだ少ないようです（公式サイトの 25% 速度アップについて言及していらっしゃる方は多いでのですが）。

　そんな中、米国の FileMaker Forum ではいくつかのスレッドで WebDirect のパフォーマンスに関する情報がみつかりました。
　リンク先は英語ですが、スレッドの紹介程度に要約を載せておきます。

1. FileMaker Server 14 & WebDirect Performance

　NickLightbody という方が WebDirect 1ユーザあたりの消費メモリを計測して表にされています。
　こちらのスレッドでは、3 WebDirect ユーザの場合は 100MB の RAM　を消費し、 30 ユーザでは 1 GB の RAM を消費することを挙げたうえで、独自の計測結果も公開されているのでとても参考になります。　すばらしい！　＼(＾o＾)／

2. FMS 14 WebDirect Performance?

　WebDirect 14にアクセスしたところ、ロード中のアイコンが出っぱなしになり、10～20 秒後にログイン画面に戻ってしまうという現象が発生。

　ちなみに、当方でも同じ現象に遭遇したことがあります。
　ホスティング会社にこの件について問い合わせたところ、FileMaker Server 13 から発生している既知の現象で、この現象が発生した場合は、FileMaker Server を再起動しないとどうにもならないとのことでした。
　また、この現象はいまのところ FileMaker Server 14 でも発生しているので、今後のアップデートが望まれるところです。　早く出さんかいヽ(`Д´)ﾉ

　その他の WebDirect 関連記事を読む

（亀）

登録: 投稿 (Atom)

メニューバー