ラベル FileMaker Server の投稿を表示しています。 すべての投稿を表示
ラベル FileMaker Server の投稿を表示しています。 すべての投稿を表示

2016-06-06

API 別/サーバ別FileMaker カスタムWebパフォーマンス比較

 FileMaker で カスタムWeb を構築する場合、どの API が一番高速なのか、と疑問を持たれてきた開発者の方も多いかと思いますが、小社もその一員です><。「FM社がバンドルしてるんだから FileMaker API for PHP なら、まぁ、間違いないだろう」位のノリでそれを採用してしまったりとか。FileMaker API for PHP(以下、FM API for PHP) や FX.php なら、ネット上の情報量も多いですし。
 そんな折、FM API for PHP を使用してWeb システムを構築していたわけですが、JMeter で想定される最大負荷をかけたところ、Web サーバがダウンしてしまうことがありました。 幸い、実運用ではそのような状況には今のところ陥っていないのですが、「これは一度、4つの API で比較テストしておこう」ということになり、今回、その運びとなりました。 また、同テストを FileMaker Server 12 と 15 でも実施しました。以下にその方法と結果を公開いたします。 1ユーザによる郵便番号データの検索と表示という限られたテストなのですが、多少なりとも参考になればウレシイかも、です。

1. テスト方法

全国の郵便番号データを入れた FileMaker データベース(今回は弊社製品『FMEasy在庫』の郵便番号テーブル)を用意し、FileMaker Server 12 と 先月リリースされたばかりの FileMaker Server 15 でそれぞれ公開。
 このデータベースにアクセスして郵便データを検索するための簡単な php ページを作成しました。

 たとえば、FileMaker API for PHP で「北海道」を含む郵便データを検索するときのイメージはこのようになります。

検索実行中!



 そして下図が実行結果となります。
 FileMaker API for PHP による「北海道」郵便データ検索結果は 8242 件(データはかなり古いので、最新のデータでは違う結果が返ると思います)で、このレコードを取得してくるのに 2.9935 秒かかったことがわかります。



2. テスト結果

FileMaker Server 12 と 15 を使用し、それぞれのサーバ上で XML、FileMaker API for PHP、fx.php、POD(ODBC) の 4 種類の API を使って 10 回ずつ「北海道」の検索を実施しました。
 その測定結果は次の通りとなりました。



 FileMaker Server 12 と 15 のバージョン間の比較では、FileMaker Server 15 のパフォーマンスが約30% 良い結果となりました。

 パフォーマンス平均をグラフ化すると、このようになります。

API 別 FMS15 vs FMS 12 パフォーマンス比較


 次に、API の比較ですが、本テストに限っては、PDO が圧倒的に高速でした。北海道に属する全8242レコードの検索・描画の最高速は 0.938秒。 正直、FileMaker の ODBC を介したアクセスは使い物にならない、と過去の経験から思い込んでいたので(その記事がこちら)、この結果は驚きでした(FMさん、御免なさい r( ̄_ ̄;))。 また、2つの php ライブラリでは、FX.php がほんの少し有利で、php ライブラリと 生XML の比較では、生XML が約40% 高速となりました。


 php ライブラリは、Web プログラマにとって扱いやすいというのがメリットですが、処理が関数化されていることによって、その分サーバのパフォーマンスが相当程度犠牲になっているようです。
少ない人数の運用では何ら問題が無かったのに、ユーザ数が増えた途端に業務に支障をきたすようになった、みたいな時は、DBへのクエリやコードの見直しに加えて、XML や PDO への乗り換えも選択肢になるかもしれません。


参考サイト:
FileMaker×PHPで作る、簡単・便利なWebアプリ ― とっても力作なサイト

過去記事:
ODBC ドライバ DataDirect SequeLink を使って FileMaker Pro にアクセスしたときの問題点


(亀)

2016-05-23

今なお輝くFileMaker 5.5/6

FileMaker 5.5/6の環境を新サーバへ早急に移行する必要がある方へ

FileMakerのWindows OSとの互換性や注意点などをこちらの記事にまとめました。
(2021/07/25 NuckyT)

 今なお輝くFileMaker  5.5/6! その理由は以下の通りです。

1. OS上位互換性

当社の経験上、FileMaker Pro 5.5/6(以下、FM5.5/6) は最新の Windows OS ― Windows 7/8/8.1/10で、FileMaker Server 5.5(以下、FMS5.5) は Windows Server 2008/2008R2/2012/2012R2 で動作します。また、FMP5.5/6 のマルチユーザライセンスを Windows Server のリモートデスクトップサーバ上に配置すれば、遠隔地からでも FMS5.5にアクセスして快適にFMを使用できます。
当社の取引先では、2台の Widnows Server 2008 を2008年に導入し、1台に FMS5.5 を、もう1台(Remote Desktop サービスライセンス×10ユーザ付)に FMP5.5(マルチユーザライセンス) をインストール。2016年5月現在、20ユーザがこのシステムを利用しています。
ちなみに、FM5.5のリリースが2001年。最終のアップデートがリリースされてから約15年が経過した2016年現在でも最新のOS上で普通に動作する FileMaker 5.5/6 は驚異的ですらあります。
(追記:2020年3月現在稼働中)

注:
  •  2019年3月現在、当方及び取引先の Windows 10 機で FMP 5.5/6 が起動・動作することを確認しています。
  • 当社ではブログのコメントにより寄せられるレガシー FileMaker の動作情報を歓迎致します。それらの情報は参考にさせて頂き、当ブログに反映させて頂くことがあります(19/3/13追記)。
  • FMS5.5 は環境によっては問題が起こることもあります。当方で遭遇した現象としては、Dell PowerEdge T105 のハイパーバイザ上の仮想マシン(Windows Server 2012R2 )では、 FMS5.5 は問題なく動作していましたが、PowerEdge R330 のハイパーバイザ上の仮想マシン(Windows Server 2012R2 )に FMS5.5 を新規インストールした後にFMS の コンソールで「ファイルメーカー Server」を右クリックして「プロパティ」を選択するとコンソールがクラッシュする、ということがありました。 この時、正常稼働している PowerEdge T105 上 の仮想ディスク(VHD)を丸ごと PowerEdge R330 にコピーして仮想マシンを再構成したところ、コンソールで「プロパティ」を選択することができました。R330 上に新規インストールした FMS5.5 を動かすべくいろいろ試してみましたが成功せず。 本現象は両PowerEdge のビデオドライバの差異に起因するものかと疑っています。
Windows 10 上の FMP5.5 によりデータベースを起動


2. 低コスト性


これが第二の理由です。 どの位、システムの総コスト(TCO)が安いのか、FileMaker 15 の FLT との比較で試算した結果が下記です。
  • FMP5.5@¥35000× 20ライセンス+FMS5.5 ¥130,000×1台=¥830,000
  • FileMaker 15 FLT 20ユーザライセンス)@¥285,000×15年=¥4,275,000

何と FM5.5のコスト は FLTのそれに比し、 5分の1以下。これまた、驚異的です。今後、Windows 10 と Windows Server 2016でも安定運用できそうな予感が…。 そうなるともう10年はかるーく生き残りそうです。

[19/03/17追記]
2019年3月現在、当社環境では Windows 10 上の FMP5.5/6 により開発・運用を行っています。また、複数の取引先に納品した FMP5.5/6 及び FMS5.5 によるシステムが、Windows 10 を含む新しいOS上で稼働しています。 仮想マシンや P2V、Remote Desktop を使用すれば、今後10年以上、レガシーFileMaker によるシステムは運用可能と思われます。


3.高速性


最新の FileMaker は最新のマシンで起動させてもかなりモッサリ。 一方、FMP5.5/6 を最新のマシンで起動させた時の速いことと言ったら… お暇なら古いPCと最新のPCで実行速度を比較してみてください。

FileMaker のOS互換性やFM製品間の互換性、さらにライセンスポリシーも迷走する昨今、機能的には遥かに劣る FM5.5/6 が輝いて見えます。 次回は、そんな  FM5.5/6 のアプリを iOS や Android で利用してみます。


そのアップグレード、ホントに必要?

  FileMaker は Ver5.5/6 以降、様々なアップグレードがなされてきました。
大きいところでは、
  • データベーススキーマの変更(アプリとデータの分離が可能に)
  • イベントによるスクリプトトリガ
  • データベース容量の拡張
  • アカウント機能追加(スクリプトによるアカウントの新規作成・管理)
  • マルチウインドウ対応とウインドウの制御
  • サーバサイドスクリプト
  • PDF出力
  • ESSによるSQLデータソース(RDBMS)との連携
  • WebDirect(FMアプリをそのままWebアプリ化)
  • カスタムWeb機能の充実(XML/PHP/REST対応)
  • iOS対応
  • テーマ・スタイル/タブ機能等レイアウト機能の改善
  • デバッガの改良
が挙げられます。現在、それぞれ重要な機能となっており、大きな恩恵を得ているユーザや開発者も多いでしょう。
一方、巷には、機能的なアップグレードを必要としない、或いはアップグレードが費用対効果に見合わないシステムが数多あります。 たとえば、NTT東日本の「ひかり電話設定サイト」(下図)、このサイトでは電話転送の設定を行うのですが、ここのユーザインタフェイスはこの10年程、ほとんどまったく変化がありません。


また、Googleの運営する Blogger ― 当ブログもこれを利用しています ―、このブログ投稿管理サイトも“ユーザインタフェイス的には十数年、あまり変化がありません。

上記の2サイトは、ユーザサイドから見れば改善の余地がありますが、運営企業は費用対効果が低い」、あるいは「プライオリティが低い」とみなしてか、少なくともユーザインタフェイスのアップグレードにはあまり熱心ではないようです。

かく言う小社も、顧客管理・請求書発行業務は「売上猫くん4.0」という FM4.0 で作成した自社システムを FM5.5 によりアップグレードし、一部簡単な機能を追加した後は、ほぼ20年間そのまま使用しており、今後も使用を続ける予定です。

FileMaker 5.5/6 で現在も稼働する小社の基幹「売上猫くん 4.0」

Amazonの通販サイトや AWS、 YouTube、Google Map、Google Analytics のように持続的なアップグレードが企業競争力と収益の源泉となるようなシステムは星の数ほど存在します。 一方、レガシーシステムであっても十分に役割を果し、今後も大規模なアップグレードを予定しないシステムも多く存在するのです。

本ページは現在でも多くのアクセスがあり、レガシーFMへの関心がいまだに高いことがうかがえます。システムをアップグレードするか、延命するかについては、業者やベンダーの情報を鵜呑みにせず、そのアプリの性質や将来像、費用対効果、双方のリスクを踏まえて意思決定するのがクレバーな企業なのだ、と思うのです。

(19/03/27追記 NuckyT)


(土屋)


追記
些細な変更にすらリスクは伴います。重要なシステムであればあるほど、そのまま使いたい。 アジャイルでリファクタリング…って何? 触らぬ神に祟りなし。
米軍の核兵器運用システムでいまだに8インチフロッピーディスクを使う理由について、ペンタゴンは「…現在も機能しているため」と言っています(米軍、核兵器運用に今も8インチフロッピー使用)。

2020/02/04 追記:
米軍、核ミサイル運用でのフロッピーディスク使用をようやく停止との報道
The US nuclear forces’ Dr. Strangelove-era messaging system finally got rid of its floppy disks (英語)
2019年にフロッピーディスクがようやく廃止されたとのことですが、約50年前のテクノロジーを延命運用できるとは、さすが米軍。


■ FileMaker 5/6等レガシーシステム関連記事

正月休み明け、仮想マシン上の FileMaker Server 5.5 バックアップが失敗していた(22/01/25投稿)
仮想マシンの外部ディスクでI/Oエラーが出た際の復旧方法

まだまだいける FileMaker 5.5/6 ― レガシーFileMaker の延命 2021 ―(21/07/24投稿)
レガシーFileMaker とOSの互換性、移行時の留意点について

IIS6 + FileMaker Web コンパニオン構成の Web サーバ機で TLS1.2 が動作するようにリバースプロキシを設定する (20/07/06投稿)
TLS1.2 非対応の IIS6 に Web ブラウザアクセス時に警告メッセージが出ないようにする

太古の FileMaker システムを延命させる! ― 後日談FileMaker(17/09/07投稿)
下記記事のレガシー延命スキームの実施と結果について。

太古の FileMaker システムを延命させる!(17/04/25投稿)
Remote Desktop Server/FileMaker Pro 5.5 搭載の Windows Server 2008 物理マシンを P2Vし、Hyper-Vに移行することにより、レガシーシステムの延命を図る。

FileMaker 5.5/6 をモバイルで使う(16/05/25投稿)
Android/iOS に Remote Desktop Client を載せて、FileMaker Go のようなことをしてみます。

今なお輝くFileMaker 5.5/6(16/05/23投稿)
レガシーFileMaker の意外な利点。

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で乗り切る


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

パフォーマンスに関する重要ポイント(リンクはタイムスタンプ):
  1. 11:30 今回のリリースで WebDirect の全面書き換えが行われたことにより、実行速度が格段に向上している。
  2. 13:40 WebDirect 14 によるレコード移動時の表示速度デモ
  3. 15:13 WebDirect 13 vs WebDirect 14 レコード移動速度比較
  4. 16:54 WebDirect 14 のタブキー操作によるレイアウトフィールド移動は、WebDirect 13 に比べると 2倍は速くなっている
  5. 20:02 デスクトップ版 WebDirect 14 は、 WebDiredt 13 に比べると 2-3 倍動作が速い。Android モバイルに至っては 10-20 倍速くなっている!(WD13はAndroidには正規対応していないのですが、Richardさんは独自の方法でチェックされたようです。但し、この部分は動画にはありません。)。
  6. 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 に関する情報にも触れられています。

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

(動画は英語)

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

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

画像について 


 jpeg, 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導入時の注意点

  1. 複数のブラウザでループスクリプトを実行しても(動作は遅くても)比較的に安定して動作する。
  2. ユーザが < や > (レコード間移動)ボタンを手動で実行すると、サークルアイコンが延々と表示され、場合によっては操作不能になことがある。 < や > を連続押しすると、この現象は高い頻度で発生する。
  3. レコードの連続作成スクリプトをクライアントサイドで実行すると、そのスクリプトは正常に終了したにも関わらず、次の操作が不能になる(サークルアイコンが出っ放し状態)になることがある。
  4. サーバサイドスクリプトが実行できる状況であれば、使う
上述のように上記のテストは海外のサーバを使用して行っていることにご注意ください。上記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 でも発生しているので、今後のアップデートが望まれるところです。 早く出さんかいヽ(`Д´)ノ


(亀)