2017-05-24

WebDirect は 16 で実用段階に近づくか? ― JMeter による WebDirect 14/15/16 比較

 FileMaker 16 が 2017 年 5 月 10 日にリリースされました。 この新バージョンで小社が注目しているのは

   1.WebDirect 16 の実行速度と安定性の向上
   2.FileMaker  のSQLデータソース用帳票ツールとしての利用

の2点です。今回は上記1について調べてみました。

 FileMaker Server 13 で搭載された WebDirect (WD)は、当初はサークルアイコンが出っ放しになった末に無応答になるなど、導入を躊躇させる機能でしたが、リリースを重ねるごとに安定性が向上しているという感じはします。 そこで、今回は若干の期待をしながら FileMaker Server 16 の WebDirect のパフォーマンステストを行いました。


 前回の WebDirect のパフォーマンスに関する記事は、こちらをご参照ください。


 今回も、前回と同様に Apache JMeter (以下、JMeter)というパフォーマンステストツールを使用し、WebDirect (WD)16 のパフォーマンスを調べました。
 以下にその内容をレポートします。前回の実験で使用した WD14 および WD15 のデータもともに掲載してありますので、WD の採用を検討されている方の参考になれば幸いです。

テスト内容と結果


 今回のテストでは、小社製品「FMEasy在庫 IWP/WD R1.5」を使用し、出庫伝票を作成するスクリプトを作成。JMeter によりこのスクリプトを 25 のセッションで 10 回ずつ実行し、その所要時間を測定するとともに、CPUの占有状態を観察しました。 また、このテストは  WD 16 で行うとともに、サーバのリソース(コア数とメモリ)を増やすことにより、パフォーマンスがどの程度改善するかも測定しました。

仮想サーバ構成


 CPU: 3.0Ghz
 コア数/メモリ: 1core/2GB、2core/4GB、4core/8GB の3パターン
 Windows Server 2012 R2 (64bit)

JMeterシナリオ


 JMeter により、「FMEasy在庫 IWP/WD R1.5」の出庫伝票を1つ作成後にログアウトするスクリプトを以下のシナリオに基づき実行。 

 Threads: 25
 Loops:10
 Ramp-up:1sec
 Pause: 1sec or 1.5 sec


注:
  • WebDirect 14 および WebDirect 15 のテストデータは前回計測時のものを使用しています。
  • Pause を設けずにシナリオを実行すると、ログアウトを待たずに次々にセッションが実行され、最大同時接続数25を超過するエラーが発生して伝票作成に失敗するため、WD15/WD16 では 1 秒、WD14 では 1.5 秒 の Pause 時間を設けました。両者で 0.5 秒の差があるのは、WD14 を 1 秒で設定すると、同様のエラーが多数したためです。
  • シナリオ実行後は出庫伝票が 250 個作成されていることを目視で確認しています。未作成レコードがある場合、その数を下表の「Fails」列に記載しています。

テスト結果と考察

WD 14、WD15 及び WD16 出庫レコード作成時のパフォーマンス(Fails は作成に失敗したレコード数)

 過去の計測では、エラーによりレコードが作成されないことがありましたが、WebDirect 16 では連続アクセスを行ってもエラーの発生はありませんでした

Peformance comparison graph on CPU cores and memory

※総評

 WD16 は WD15 に比し、2%~35%、実行速度が向上しています。サーバリソースの割り当てを増やすと、その差は顕著になります。
1core/2GBでは WD16 と WD15 間で実行速度の差は 2% とほとんど改善は見られませんでしたが、1core/2GB から 2core/4GB に増やすと 24%、 2core/4GB から 4core/8GB に増やすと35%改善しました。 コア数/メモリの割り当てがチューニングのキーとなる可能性があります。
 ただ、前回テスト時と同様に、リソース割り当てを増やすに従って、その改善率は徐々に鈍化するものと推定されます。
 
※ CPUの占有率

 以下の図は JMeter 実行時の CPU 占有率です。 1コアの場合、CPU を使い切ってしまうことが多々ありました。やはり、CPU 占有率が 100%になるような状況は避けたいです。リソースを増やすに従い、CPU の使用率は下がります。



WebDirect 16


1 Core / 2 GB RAM
WD16 のときと同様に、CPU 占有率が 100% に達する状態が続く。しかも長い。よって同時アクセスユーザが集中する可能性のあるサーバは要注意

2 Core / 4GB RAM
WD15 に比しCPU占有率が高くなっているが、その分占有時間は短くなっている


4 Core / 8GB RAM

WD15に比しCPU占有率が高いが、その分占有時間は短くなっている



WebDirect 15


1 Core / 2 GB RAM
CPU 占有率が 100% に達する状態が続く。同時アクセスユーザが集中する可能性のあるサーバは要注意

2 Core / 4GB RAM


4 Core / 8GB RAM



WebDirect 14

1 Core / 2 GB RAM
長時間にわたり高負荷状態が発生。WD15 や WD16 に比べると処理により多くのサーバリソースを消費することがわかる。

2 Core / 4GB RAM


4 Core / 8GB RAM


まとめ

FileMaker Server 13 がリリースされた頃の WebDirect は動作が不安定で、とても実用に耐えないと評価しましたが、今回は25台の仮想マシンから計250のレコードを一斉作成するテストを5回実行しても一度もエラーが発生しませんでした。 WebDirect は運用に耐えうるレベルに達しつつあるというのが今回の実感です。
 また、WebDirect からの PDF 出力も可能となりましたので、 FileMaker Pro クライアントの代わりに WebDirect を導入するという選択肢も視野に入ってきたように思います。

 ただし WebDirect と数多あるブラウザとの互換性の問題は依然存在しますし、ページをリロードすると画面が初期状態に戻ってしまうという現象も依然として発生します。
 また、WebDirect には不向きな処理(例:バッチ処理)を実行した場合に無応答状態になる可能性も解消したとは言い切れません。 WebDirect の設計に当たっては、通常処理とサーバサイドスクリプトに割り当てる処理の切り分けが重要になるかも知れません。
 WebDirect のクリティカルなシステムへの適用は、十分な設計とテストが必要と思います。

補足情報:拡張アクセス権限の変更について

 FileMaker Server 16 の WebDirect 環境で、 URL にスクリプトを指定して実行する場合は、当該のアカウントの拡張アクセス権限で「FileMaker WebDirect によるアクセス(fmwebdirect)」に加え、 「URL による FileMaker スクリプトの実行を許可(fmurlscript)」を有効にする必要があります。


 このオプションが有効になっていないと、実行時に以下のような権限不足エラーが発生します。


 不特定ユーザが使用する環境においては、この辺りのセキュリティに配慮してプログラムしないといけませんね。



(亀)

2017-04-25

太古の FileMaker システムを延命させる!

 小社では 「売上猫くん 4.0」という自社製パッケージ製品(一部改変)をもう20年程、社内の見積・売上・請求管理システムとして使用しています。 「売上猫くん」は初期には FileMaker 3/4 により開発されたものです。 この太古のシステムは現在、  仮想マシン(Windows Server 2008)上のFileMaker Server 5.5 で公開され、Windows 10 を含む最新のWindows 機上のFileMaker Pro 5.5/6 から毎日アクセスされて使用されています。
 小社同様、FileMaker 5.x/6.0 でシステムを運用している企業・組織は一定数あり、当方の客先にも何社かはそのようなところがあります。
 このような FileMaker のレガシーシステムを運用する場合、まずネックとなるのがハードウェアの老巧化や故障によるリプレイスです。 本稿では「FileMaker レガシーシステムの仮想化による延命方法」を小社の客先である某社を例にご紹介します。

1. 某社の状況

1998年: 某社より生産・購買・販売・在庫管理システムの開発業務を受注。FileMaker 4 により開発を開始。数ヶ月後に首尾よくリリースに漕ぎ着ける。某社本社の Macintosh 上に FileMaker Server 5.5 を配置し、NTTの専用線  Digital Access による WAN を介して複数拠点で運用を開始。

2001年: FileMaker 5.5 へアップグレード。fmj から  fp5 へのファイル構造の変換が伴うアップグレードにも関わらず、難なく終了。 この際、サーバを Windows Server 2000 に変更。

2008年*1: Windows Terminal Service (後のRemote Desktop Service)を導入し、FileMaker Pro 5.5 をインストール。拠点のユーザはこのサーバ上の FileMaker クライアントを実行することにより、アプリの実行速度を改善。この際、FileMaker Serverを運用するサーバ機も Windows Server 2008 に変更(参考記事)。さらに、ネットワークの高速化とコスト低減を目的に Digital Access から インターネットVPN へ変更。  インターネットVPNへの変更に伴うセキュリティ上のリスクへの備えとして、SonicWALL による IPS 、Gateway Antiviurs 等も併せて導入。

導入以来、数多の仕様変更を繰り返しながら、現在もFileMaker 5.5 の環境で運用中。

*1
2008年当時、小社内で Windows Server 2008 と FileMaker Server 5.5 の組み合わせによる運用実績はあったのですが、このようなレガシーシステムの運用はベンダーによる動作保証の対象外となることを事前に客先に十分説明しなければなりません。 レガシーシステムの延命は客先のリスクに関する理解と許容が重要だと思います。

2. さらなる延命へ

2008年に導入した RDSサーバですが、経年劣化によるリプレイスを検討するように、客先に数年前からお願いしていたところ、先ごろ、ようやくリプレイス案を出すように求められました。 ただ、運用実績のある Windows Server 2008 は既に発売中止になっていました。そこで以下のような図と共に提案書を客先に提出しました。

仮想環境はWindows Server 2012/2016 Standard 付属のHyper-V(ゲストOSが2ライセンス付属)

A案は単純リプレイス型ですが、新サーバを導入し、そこに現行のOS(Windows Server 2008)をインストールし、RDTアカウントやFileMakerが動作する環境を新たに構築し直す、というものです。 問題となるのは、前述のように Windows Server 2008 に公式対応するサーバ機が2017年現在ほとんど存在しないので、それを覚悟の上での実装となります(参考:Microsoft社のサポート期限一覧)。

B案は現行サーバを P2V (Physical to Virutal)し、これを Hyper-V 2.0 で運用するというものです。これが上手くいくと 旧サーバのハードディスク情報をそのまま仮想マシン化でき、OSやアカウント情報の再構築・再設定が不要になるので、大変便利です。 半面、まったく異なるハードウェア環境へ移動することになるので、各種ドライバでエラーが発生したり、悪くすると初回起動時にブルースクリーンが表示されたりします。 安定運用期に入るまで気をぬけません。

C案は 新規にWindowsサーバを導入、ゲストOS も新たに作成し、その上にRDTアカウント等の再度設定しなおすものです。ゲストOS上での作業はほとんどA案と同様になります。P2Vに比べハードウェアの差異によるエラーやブルースクリーンやらの可能性はほぼなくなりますが、すべて一からの作業となります。

 提案書と概算見積をご提示した後に打ち合わせをしました。結果、サーバ故障時やリプレイス時に仮想マシンであれば迅速に復旧可能であることも勘案し、Windows Server 2016 を使用したB案で進行することになりました。ただ前述のように P2Vが失敗するリスクがあることをご説明し、B案不首尾の場合は、A案、C案、さらには Windows Server 2016 の 2012 へのダウングレード(D案*2) もバックアップとしてご提示しました。

*2
D案の提案理由は  SATO のあるラベルプリンタが Windows Server 2012 へは公式対応している一方、Windows 2016 に非対応であることによります。重要な周辺機器との互換性もレガシーシステムの延命を行うときには“要注意”となります。

3. テスト環境での実装

新しいサーバ機の納品までしばらく時間があるため、客先の旧サーバを予め P2V してVHD(X)にし、当方の Windows Server 2016 の Hyper-V に入れ、事前にテストを行いました。仮想マシンを起動するとエラーイベントが複数発生していたので、一つ一つ潰していきました。 次に FileMaker Pro 5.5 (以下、FM5.5)を起動してテストを実施。 下図のようにクライアントPCから仮想サーバにRD接続。 FM5.5 を使用し FileMaker Server 5.5 (以下、FMS)上の12万件のデータが入った郵便番号ファイルを開き、ソートを実行・・・ 「ん? 」、なんかかなり遅い感じ。

確認のため、仮想サーバではなく、別の物理マシンのRDS から郵便番号ファイルにアクセス(クライアントPC→物理マシンRDS+FMP→FMS)すると、なんと3倍!速い。 クライアントPC→Win Server 2016 RDS+FMP→FMSで実行してもやはり3倍速い。

 ならば、仮想サーバ上に郵便番号.fp5 を配置して、ネットワークを介さずローカルで実行するとどうか? 一瞬 = 数秒~10秒程度!で終了してしまいます。 ということで、仮想サーバの通信速度(上図の「FMP⇔FMS接続」)に問題があることが判りました。 実はここからがすごく大変で、 「Hyper-V ゲストOS 遅い」や「Hyper-V Guest OS slow」などをキーワードに、数日間、ググって試す、ググって試すを繰り返しました。 ググってまず最初に出てくるのが、NICの仮想マシンキュー(VMQ、Virtual Machine Queue)を オフ にせよ、というもの。これは内外のいろいろなところで書かれており、小社の別のHyper-V環境下のゲストOSでは劇的な効果があったのですが、今回の仮想マシンについては全く効果無しでした。 NICの「IPV4チェックサムオフロード」をオフにしろ、という記事も多く見かけましたがこれもダメ。
NICの設定は、ホスト側からだけではなく、仮想マシンからもいじってみましたがうまくいかず。
万策尽きたか、と思ったところで、突然光明が差しました。 それは、「レガシーネットワークアダプタ」の使用(下図)。



 仮想マシンのネットワークアダプタを作成する際、「ハードウェアの追加」を選択。この時、通常は「ネットワークアダプタ」が推奨されますが、ここで「レガシ ネットワーク アダプター」を図のように選んで“追加”します。 これを行うことにより、

ping -l 60000 hostname

の応答時間も劇的に改善し、12万件の郵便番号ソートも劇的に速くなりました。

 今回のゲストOSは Windows Server 2008 で、このOSは Hyper-V の「統合サービス」に対応しているので、上図では「ネットワーク アダプター」を選択するのがセオリーだと思うのですが、、、
ネットで調べてもレガシはオバーヘッドが多いので、「ネットワークアダプター」を使いなさいという記事しか見当たらりませんでしたが、レガシーのままテストを続行することにしました。

尚、上記の記事に関する後日談はこちらをご覧ください。


土屋企画では、FileMaker レガシーシステムの延命、拡張、仮想マシンへの移行に関するご相談を請け賜わっております。ご希望の方はこちらからお問い合わせください。



(土屋)


追記
「売上猫くん3.0」は1997年に FileMaker Pro 3 により開発されたものですが、 いまだにご愛用頂いているお客様がいらっしゃいます。 ただ、ハードウェアの老巧化の問題があるのでできる限り新バージョンへのアップグレードをお勧めしてます。 それはそれとして、 FileMaker Pro 3/4 のシステムを Windows NT 4.0 の仮想マシンで運用するというのは、実際やったことはありませんが、チャレンジしてみたい気もします。



■ FileMaker 5/6等レガシーシステム関連記事
下記記事のレガシー延命スキームの実施と結果について。

Remote Desktop Server/FileMaker Pro 5.5 搭載の Windows Server 2008 物理マシンを P2Vし、Hyper-Vに移行することにより、レガシーシステムの延命を図る。

Android/iOS に Remote Desktop Client を載せて、FileMaker Go のようなことをしてみます。
 
今なお輝くFileMaker 5.5/6(16/05/23投稿)
レガシーFileMaker の意外な利点。




参考リンク:
今なお輝くFileMaker 5.5/6
物理マシンを Hyper-V 仮想マシンに移行する(P2V)
Performance Tuning for Hyper-V Servers
Hyper-V network adapter differences
Windows Server 2012 Hyper-V の SR-IOV 構築手順 (1)

2017-01-23

Google サイト(Google Sites)をバックアップする方法

 Google サイトを使っていらっしゃる方は、サイトのバックアップをどうするか悩むところかと思います。

google-sites-liberation で公開されているツールは動かない


  ツールの最新版は、2011/04/27 で google-sites-liberation-1.0.4.jar  の公開が終わっています。

google-sites-liberation で公開されているツールの一覧

  しかしながら、google-sites-liberation-1.0.4.jar を実行すると、以下の認証エラーが出ます。

google-sites-liberation-1.0.4.jar を実行すると表示される認証エラー

GitHub からツールの最新版をダウンロードしてバックアップする


  google-sites-liberation - issue #107 (ソースは英語)を確認すると、https://github.com/sih4sing5hong5/google-sites-liberation の方で開発が続行しているので、そちらを確認します。


 操作手順は次のとおりです。

 1. Google Sites Import/Export Tool のセクションからツールをダウンロードします。
 最新バージョンは 1.0.6 です(2017/01/23 現在)。

Google Sites Import/Export Tool のダウンロード

 2. google-sites-liberation-1.0.6-jar-with-dependencies.jar がダウンロードされますので、ダブルクリックで実行します。
 実行にあたっては事前に Java をインストールしておく必要があります。

 
Google Sites Import/Exportツール


 3. 必要事項を入力してから、“Get a token from browser” をクリックします。
 すると、google がユーザ許可を求めるページが表示されますので、“許可”ボタンをクリックします。
 ※事前に Google アカウントにログインしておく必要があります。


google-sites-liberation のアクセスを許可する

 4. トークンが発行されますので、クリップボードにコピーします。

表示されたトークンをクリップボードにコピー

 5. コピーしたトークンをツールに貼りつけてから、“Export from Sites” をクリックすると、バックアップが始まります。


 ※当然のことながら、トークンには有効期限があります。トークンが無効になった場合は、“Get a token from brower”をクリックすることによって、トークンを取得しなおしてください。

 6. Export Complete が表示されたらバックアップ完了です。



 その他のバックアップツールとして、弊社では WinHTTTrack を使用していますが、このツールの使い方については、また機会をあらためてご紹介したいと思います。