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

2016-11-17

Slim フレームワークの REST による FileMaker データベースへのアクセス

 FileMaker では API for PHP、FX.php、XML、ODBC を介して Webプログラミングを行うのが通常ですが、昨今巷で REST なる言葉を聞くようになりました。 そこで今回は REST を使用した FileMaker DB アクセスにトライしてみました。

 開発環境は以下のとおりです。

Slim フレームワークを使った REST 構成で FileMaker Server にアクセス

 ご覧のように、Microsoft IIS  Web サーバに FileMaker Server 15 と PHP をインストールしたうえで、 Slim フレームワークをインストールしています。


REST についてモヤモヤっとしがちなところ


  REST (REpresentational State Transfer) とは、サーバ上の情報(リソース)に対し、一意の URI を提供するためのアーキテクチャ(仕組み)です。 
 この 一意の URI と、Web クライアントから渡ってきた HTTP メソッドの組み合わせにより、リソースを操作します。

メソッド処理
GET取得。idempotent
POST新規作成。not idempotent
PUT更新。idempotent
DELETE削除。idempotent (限定的)

 表中の idempotent は冪等(べきとう)性を指します。これは、何度操作しても同じ結果が返ってくるという意味です。これはステートレスという、REST の特徴になっています(ステートレスについては後述します)。

 idempotent について例を簡単に示します。

 GET メソッド  --- Amazon でたとえば PlayStation 4 Pro という商品の情報を得るためのGET リクエストは、https://www.amazon.co.jp/dp/B01LRHPUZ4/ です。

 これは固有の URI として一般公開されているため、Web ユーザがこの URI に何度アクセスしても、このリンクが存在するかぎりは同じ商品にたどりつくことを意味します。よって、この処理は idempotent (冪等性がある)となります。

 POST メソッド ---  Amazon の例でたとえると、出品者が Amazon に商品情報を追加したいときの URI は専用のものを使いますが、その URI だけでは、追加された商品(リソース)にたどりつくことができません。
このため、この URI そのものはリソースの一意性を保障できないため、not idempotent (冪等性がない)となります。
 
 PUT メソッド ---  特定のリソースを更新しますので、この URI は idempotent (冪等性がある)となります。

 DELETE メソッド --- 削除処理が完了するまでの間はリソースの URI は有効なため、 idempotent (冪等性がある)ですが、削除が完了するとそのリソース自体が消滅するため、not idempotent (冪等性がない)になります。これが限定的に idempotent とな理由です。


 アクション部分は HTTP メソッドで指定し、URI 各項目を名詞で表現するというルールを実装することによって、URI の一意性がもたらされます。
 また、実際の操作を実行するファイル名や引数名の隠匿性も高くなります。

ステートレスとステートフル

 REST の特徴としてステートレスな通信であることが挙げられます。
 しかし、Web アプリケーションの目的によっては、ステートレスですべての要求がまかなえない、つまり REST だけではシステム設計に無理が出てくることもあります。

 以下に例を示します。

 ニュースサイトでニュースを見るとき、見たいニュースのリンクをクリックすると、ニュースの内容が表示されたら処理は完結します。ユーザが今の時点まで どんなニュースを見てきたかという処理の流れについてはサーバは関知しません。 このような通信はステートレスであるといいます。

 ユーザが条件を指定するというパターンでは、Google Map サービスが良い例となるでしょう。
 住所を入力すれば、その住所の地図が即座に表示されますが、Web サーバはユーザとのやり取りを保持しません。しがたって、この通信もステートレスです。

 それでは、オンラインでショッピングカートに入れた商品を買う場合はどうでしょうか?
 ユーザは購入内容の確認からクレジットカード決済の処理にいたるまでの一連の処理をサーバと対話形式で行っていく必要がありますね。処理が完了するまで、サーバはユーザとのやりとりを保持しますので、この通信はステートフルになります。


 REST に関する参考リンク:

REST [WikiPedia]
CHAPTER 5 Representational State Transfer (REST) [REST を提唱したロイ・フィールディングの博士論文] 英語


Slim フレームワーク を使った REST 環境の構築


 Slim フレームワークは、REST 対応の軽量 PHP フレームワークです。
 HTTP メソッド別の処理のルーティングがあらかじめ想定されているため、比較的少ないコード量でデータベースアクセスルールと応答処理の実装ができます。

 インストール方法は公式サイトをご覧ください。

 Slim フレームワーク 公式サイト[英語]


Microsoft IIS 向け REST 構成のためのルート URL 書き換え


 Apache の .httaccess 書き換え方法は割といろいろなところで見つかりますが、IIS 向けの情報があまりないようですので、まとめてみました。
 
 たとえば、Web アプリケーションのルートディレクトリが inventory のとき、出庫ID=123 の商品を照会するための index.php へのアクセスはこのようになるでしょう。

 http://hostname/inventory/index.php?act=outgoing&id=123

 REST 構成の URI は、スラッシュで文字列を区切った形式となります。
 このため、GET リクエストを発行するユーザに提供する URI は以下のようになります。

 http://hostname/inventory/outgoing/123

  上記の赤色の URI は、本来は http://hostname/inventory/index.php ですが、これを http://www.hostname/inventory/ と書き換えることによって、ユーザに index.php ファイルを通知しないようにするとともに、後続のスラッシュで区切られた文字列をそのまま index.php に通知するように URLを書き換える必要があります。

  http://hostname/inventory/index.php
 ↓
  http://hostname/inventory/


【操作手順】
  1. あらかじめ、ユーザに公開する inventory ディレクトリを wwwroot 配下に作成しておきます。
  2. Windows Server のインターネット インフォメーション サービス(IIS) マネージャを起動します。
  3. 左ペインで、ユーザに公開する inventory までディレクトリを展開し、「URL書き換え」アイコンをダブルクリックします。

    inventory ディレクトリの「URL書き換え」アイコンをダブルクリック

     「URL 書き換え」ペインが表示されますので、右ペインのメニュー項目より「規則の追加...」リンクをクリックし、「受信規則と送信規則」のセクションの中から[ユーザフレンドリ URL]を選択して“OK”ボタンをクリックします。

    ユーザーフレンドリ URL を選択


  4. 「ユーザーフレンドリ URL を有効にする規則の追加」ダイアログが表示されますので、[動的 Web アプリケーションで使用される内部 URL の例を入力してください]のボックスに、index.php への URL をフルで入力します。
    たとえば、下図のように入力します。




    [Web サイト訪問者のブラウザーに表示される、タイプするパブリック URL の例を選択してください]の項目は、ここでは無視してください。
  5. 受信規則の URL 書き換えリストに、前述の規則が追加されます。この規則をダブルクリックします。
    今追加した規則をダブルクリック

    URL 書き換えの詳細ペインが表示されます。
    [パターン(T)]のボックスには、^inventory/index.$ という記述になっていますが、これを ^(.*) という記述に書き換えます。

    受信規則のパターンの書き換え

     つぎに、画面下部の「アクション」のセクションで、URL書き換えの不要な文字列を取り除きます。現在、inventory/index.php という記述になっていますが、これを index.php という記述に変更します。

    アクション URL の書き換え


    ここまで終わったら、右ペインの「適用」リンクをクリックすることによって、修正を反映させます。
    この規則は、inventory ディレクトリの中に、web.config という xml 形式のファイルで保存されます( Apache でいう .htaccess ファイルに相当するファイルです)。
  6. アクセステストしてみましょう。

    ためしに、Hello World! と記述した html ファイルを index.php という名前で保存し、inventory ディレクトリに配置します。

    このファイルに、以下のリンクパターンでアクセスしてみましょう。

    http://hostname/inventory/
    http://hostname/inventory/outgoing/
    http://hostname/inventory/outgoing/123

    このように、各パラメータを渡したときにも、ページが見つからないというエラーが返ってこなければ、URL 書き換えは成功です。


    パラメータ別に所定の処理が動作するようにするには、Slim フレームワーク側でそれぞれのパラメータを受け取るようにコード記述を行います。


Slim フレームワークで FileMaker に接続するためのコード記述例


 ここでは、Slim フレームワークから FileMaker データベースに PDO(ODBC) 接続し、GET 要求されたデータを返すためのコード記述例を簡単に説明します。

 ユーザに公開するための出庫データ取得用 URI の形式は以下を想定します。

  http://hostname/inventory/outgoing/123

 赤で示した部分は、URL 書き換え設定を行った URI です。つまり内部的には http://hostname/inventory/index.php にアクセスすることになります。

 outgoing/123 は パラメータ1/パラメータ2 という並びになりますので、ここではoutgoing(出庫)と123(ID)という、2つのパラメータを取ることになります。

 
【コードの記述】

  ここでは、Slim フレームワーク公式サイトにあるコード記述方法にできるだけ沿った形でコード例をご紹介します。

  1. 接続情報の事前設定をします。

     以下は、ローカルホストの FileMaker Server 15 で公開中のデータベースファイルへの接続情報となります。
     将来的にこの接続設定を複数のファイルで使いまわしたい場合は、以下の部分を外部ファイル化( config.php など)しておいて、実装時にインクルードするとよいでしょう。

    <?php

        $config['displayErrorDetails'] = true;
        $config['addContentLengthHeader'] = false;
        $config['db']['host']   = "localhost";         //ホスト名
        $config['db']['user']   = "webuser";          //ユーザ名
        $config['db']['pass']   = "password";             //パスワード
        $config['db']['dbname'] = "testdatabase";   //データベース名

    ?>


  2. Slim フレームワークオブジェクトのインスタンスを生成します。


     いよいよ、 Slim REST API の本体となる index.php ファイルを書いていきます。ユーザへのURI を提供するのがこのファイルとなります。

     $app = new \SlimApp(); で $app という名前の Slim オブジェクトのインスタンスが生成されますが、あらかじめ接続情報を読み込ませておく場合は、$app = new \Slim\App( ['settings' => $config] ); のように記述します。

    <?php

        use \Psr\Http\Message\ServerRequestInterface as Request;    //要求インタフェース
        use \Psr\Http\Message\ResponseInterface as Response;       //応答インタフェース

        require_once '../slim/vendor/autoload.php';    //Slim への相対パス
        require_once 'config.php';                            //外部ファイル化された接続情報(任意)

                                                                    //Slim インスタンス生成
        $app = new \Slim\App( ['settings' => $config] );

    ?>

  3. データベース接続の準備をします。

    $app に実装済のデータベース接続情報の取り出しは、getContainer() メソッドで行います。
    そして、コンテナの db 要素に PDO オブジェクトを返すように設定しておきます。

                            //コンテナ取り出し
    $container = $app->getContainer();

                            //コンテナにデータベース接続を定義しておく
    $container['db'] = function ( $c ) {

        $db = $c['settings']['db'];
        $pdobj = new PDO("odbc:Driver={FileMaker ODBC};host=" . $db['host'] . ";Database=" . $db['dbname'],$db['user'], $db['pass']);
        $pdobj->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
        $pdobj->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);

        return $pdobj;

    };


  4. GET リクエストを受信したときの動作を記述します。

     GET リクエストを受信した場合に応答する場合は、get メソッドを使います。
     $app->get(); が原形となりますが、GET で受け取る引数と処理の記述は、たとえば以下のような形式となります。

     赤字がユーザから受け取る引数のリスト(スラッシュ区切り)、青字が処理内容です。
     引数のリストの可変部分は中カッコ{}で囲み、中にその識別名を入れておきます。
     以下の場合は、出庫ID を想定した識別名を id とし、{id} のように記述しています。

     ユーザから渡された id を取り出すには、要求オブジェクト $request から getAttribute メソッドを呼び出すことで実現します。
     以下のコードのように書くことで、ユーザから渡された id が $id にセットされます。

    $app->get( '/outgoing/{id}', function ( Request $request, Response $response )   {
                                //パラメータ取り出し
            $id = $request->getAttribute( "id" );
        }

    );

    $app->run();

    最後の $app->run(); でユーザからのリクエストを受け付けます。

    上記は GET 要求に対する処理を無名関数の中で行うように記述していますが、別途名前つきの関数を作って呼び出すようにしてもかまいません。
  5.  データベースに接続し、クエリを発行します。

     データベースの接続は、$this->db; で行います。これにより、3. のデータベース接続が実行されるとともに、PDO オブジェクトが返ってきますので、それを使ってデータベース操作を行います。

     たとえば、前述の get メソッドの部分をまとめて書くと、以下のようになります。
    最後に結果を return することで呼び出し元に json フォーマットのデータを返しています。

    $app->get( '/outgoing/{id:[0-9]+}', function ( Request $request, Response $response ) {

                            //パラメータ取り出し
        $id = $request->getAttribute( "id" );
           
        try {

                            //$this->db の形で接続確立し、$pdo オブジェクトを生成
                $pdo = $this->db;

                $sql = 'SELECT * FROM "出庫" WHERE "出庫ID"='.( int )$id;
                $stmt = $pdo->prepare( mb_convert_encoding( $sql, "shift-jis" ) );
                $stmt->execute();

                                //対象レコードカウント
                $recordCount = $stmt->rowCount();
               
                if( $recordCount == 0 ){

                            //レコードなし
                    $result = 401;

                }else{
           
                            //レコード取り出し
                    $data = $stmt->fetchAll();
               
                    if( isset( $data ) ){

                        mb_convert_variables( 'UTF-8','shift-jis',$data );

                        $result =  json_encode( $data );

               
                    }else{

                            //レコードなし
                        $result = 401;
                   
                    }
                }

                $pdo = null;
           
            } catch( PDOException $e ) {

                $result = '{"error":{"text":'. $e->getMessage() .'}}';
               
            }

            return $result;
           
        });

    重要:
    • PDO(ODBC) でクエリを発行する際は、文字コードは shift-jis 形式で渡さなければエラーが発生します。
    • 戻りデータの文字コード shift-jis になりますので、必要に応じて文字コードを変換してから使用する必要があります。
    • PDO(ODBC) では bindParamやbindValue による引数のバインドがうまくいかない模様です。このため、SQL インジェクション対策として、{id} で受け取る引数を数値に限定するように {id:[0-9]+} と書き換えてあります。

  6. テストしてみましょう。

    Web ブラウザからhttp://hostname/inventory/outgoing/任意の数字 を入力して送信したとき、json 形式の結果がブラウザページに表示されれば成功です。


 応用編として、Web インタフェースを作り、出庫ID指定による一覧呼び出しを行った例が、以下のようになります。 内部的に Slim アクセスへの URI を呼び出しを行い、戻ってきた json データを整形して一覧表示しています。

内部的に Slim URI を呼び出している Web インタフェースの例

 Slim は軽量とはいえ、間にフレームワークを挟めば処理速度は低下します。
 こちらの記事でパフォーマンスについてご紹介しておりますので、併せてご覧いただけると幸いです。
 Slim フレームワークの REST(PDO) および RESTfm を使って CRUD のテストをしてみた


 Slim フレームワーク以外でも FileMaker で使用できるオープンソースの REST 環境がいくつかあるようです。
 

参考リンク:
 
 RESTfm (Goya)
 RESTfmがオープンソースに (Not only FileMaker)
 fmEasyAPI  開発者はサポートやめちゃったみたい...

2016-08-30

Record navigation in FileMaker PDO Custom Web Publishing is so slow... why?


Searching records in FileMaker Custom Web Publishing(CWP) using PDO(PHP Data Objects) can become pretty frustrating as a table grows much bigger, say the table has one million records.


A table with one million records is not THAT huge when it is of a MySQL table, but it is obviously too much to handle for FileMaker if you want to do some CWP using PDO.

FileMaker is compatible with ODBC, and PDO supports ODBC.  This means you can perform SQL queries via PDO to retrieve data from FileMaker databases.

We will be talking about this issue using PDO in this post.
Here are a few things to consider if your tables have thousands of records:

  1. Do not use SELECT COUNT (*)

    select count(*) causes a server time out, and worse yet, the existing fmxdbc_listener.exe process eats up CPU usage and RAM while counting records, and then goes unresponsive.

    This is serious, because you will end up killing and starting fmxdbc_listener.exe process manually, or restarting the FileMaker Server.

    SELECT COUNT ( fieldname ) would not make the situation any better. :(
  2. Do not use the ORDER BY clause

    This also causes a server timeout and fmxdbc_lisner.exe turns into a CPU/RAM eating monster if you use the ORDER BY  clause for a large volume of recordset.
  3. Try not to retrieve a large recordset by using SELECT.

    The query response becomes worse if the found recordset is huge, even if indexed fields are specified in a WHERE clause.


How would you navigate records in a found set?


You may find some different ways to navigate records in a found set if you google it.
However, when it comes to FileMaker CWP, your options are quite limited after you consider those don't's we have already explained above.

Method 1:  Use PDO scrollable cursors


Here is a sample php script for retrieving the last record in a found set using a PDO scrollable cursor.


<?php //sets up a connection
try {

$dsn= "odbc:Driver={FileMaker ODBC};host=127.0.0.1;Database=test";
$pdo = new PDO( $dsn, "cgi", "pwd" );
$pdo->setAttribute( PDO::ATTR_EMULATE_PREPARES, false );
$pdo->setAttribute( PDO::ATTR_CASE, PDO::CASE_NATURAL );

} catch ( PDOException $e ) {

exit( "Database connection failed.". $e->getMessage() );

}

//builds a query string
$sql = "select recId, invoiceNo from invoice";

//prepares a PDO statement and runs it
$stmt = $pdo->prepare(  $sql, array( PDO::ATTR_CURSOR => PDO::CURSOR_SCROLL ) );
$stmt->execute();

//retrieves the last record in a found set
$record = $stmt->fetch( PDO::FETCH_ASSOC, PDO::FETCH_ORI_LAST );

//script goes on using $record....

?>


PDO::ATTR_CURSOR => PDO::CURSOR_SCROLL defines a scrollable cursor, and PDO::FETCH_ORI_LAST moves the cursor to the last row in a found set.

You may also consider using the following predefined PDO constants:

PDO::FETCH_ORI_FIRST --- moves the cursor to the first row in a found set.
PDO::FETCH_ORI_ABS --- moves the cursor to the specified row in a found set. The absolute position is specified in the third argument.
Example: $record = $stmt->fetch( PDO::FETCH_ASSOC, PDO::FETCH_ORI_ABS,$absPosi);

For more information, please visit http://php.net/manual/en/pdo.constants.php


Method 2:  Use FileMaker's OFFSET n ROWS and FETCH FIRST n ROWS Clauses


Here is a sample php script for retrieving the 5000th record in a found set using FileMaker's OFFSET n ROWS and FETCH FIRST n ROWS clauses.


<?php //sets up a connection
try {

$dsn= "odbc:Driver={FileMaker ODBC};host=127.0.0.1;Database=test";
$pdo = new PDO( $dsn, "cgi", "pwd" );
$pdo->setAttribute( PDO::ATTR_EMULATE_PREPARES, false );
$pdo->setAttribute( PDO::ATTR_CASE, PDO::CASE_NATURAL );

} catch ( PDOException $e ) {

exit( "Database connection failed.". $e->getMessage() );

}

//defines the offset value of 4999
$offset = 4999;
//builds a query string
$sql = "select recId, invoiceNo from invoice OFFSET ".$offset." ROWS";

$sql .= " FETCH FIRST 1 ROWS ONLY";

//prepares a PDO statement and runs it
$stmt = $pdo->prepare( $sql );
$stmt->execute();

//retrieves a record
$record = $stmt->fetch( );

//script goes on using $record....

?>

$offset = 4999 defines to go to the 4999th row in a found set.
FETCH FIRST 1 ROWS ONLY defines to retrieve one row.
Thus, the 5000th row will be set to $record variable.

The Response is SO Slow Whatever the Method is....


Practically speaking, requiring five seconds to retrieve JUST one record is simply ridiculous.
But unfortunately this happens with FileMaker CWP when tables get bigger.

We have created sample scripts using those two data retrieving methods to navigate records in a found set, in order to show you how slow the FileMaker server response gets.

Method 1:  Using  PDO scrollable cursors


First button

The response is fairly good since the query does not have a WHERE clause.


Next button

It took 5.3859 seconds just to show the second record out of 939,623 records.
This outcome is pretty disappointing but this happens when the query has a WHERE clause and the found set is huge.

In this example, cRecId > 17538 results in 922,084 records and FileMaker Server's response goes slow, even though cRecId field is indexed.


Previous button

It took 5.4028 seconds when clicking Previous button to retrieve the previous record from the very last position.
This is another disappointing outcome because this huge found set caused the slow response.

In this example, cRecId < 957160 results in 939,622 records and FileMaker Server's response goes slow, even though cRecId field is indexed.


Last button

The response is alright, since the query does not require a WHERE clause.


Method 2: Using FileMaker's OFFSET n ROWS and FETCH FIRST n ROWS Clauses


This method requires two separate queries:

  1. A query to get the record count from a table with SELECT clause.
  2. A query to set the starting position (offset)  in a found set and fetch the specified number of rows of records.

Performing two queries does not appear to be a very smart, however, there is no better way to know how many records there are in a table(especially when you want to know the total record count), and then perform OFFSET and FETCH ONLY n ROWS clauses.


First button

It took 1.0043 seconds to get the first row.
Please note the first query (QUERY1 in the figure below)  does not have a WHERE clause.



Next button

It took 5.7659 seconds just to show the second record out of 939,623 records.
In this example, the first query's (QUERY1 in the figure below) cRecId > 17538 results in 922,084 records and FileMaker Server's response goes slow, even though cRecId field is indexed.


Previous button

It took 6.854 seconds when clicking Previous button to retrieve the previous record from the very last position.

In this example, the first query's (QUERY1 in the figure below) cRecId < 957160 results in 939,622 records and FileMaker Server's response goes slow, even though cRecId field is indexed.




Last button

It took 2.0451 seconds to get the very last row.
The first query (QUERY1 in the figure below)  does not have a WHERE clause, so the response is faster than the Next and Previous buttons.


(亀/turtle)






2016-06-15

WebDirect 14 vs 15 ― JMeter による負荷テスト

 FileMaker インスタント Web の後継版として、FileMaker 13 より WebDirect (以下、WD)が登場しました。インスタント Web に比べ、 WD の操作性はより FileMaker Pro に近づいたものの、パフォーマンスや安定性にかなり問題があるんじゃないか、みたいなことを約1年前に記事にしました。 その折は、WD13 と WD14 の2つのサーバ上で、複数のクライアントPCを用意し、各PCで複数のブラウザウインドウを開いた状態で、それぞれのウインドウからスクリプトを手動実行して負荷をかける、というものでした。
 今回は Apache JMeter (以下、JMeter)というパフォーマンステストツールを使用し、WD14 と WD15 のパフォーマンス比較をしたので、以下にその内容をレポートします。WD の採用を検討されている方の参考になれば幸いです。

テスト内容と結果


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

仮想サーバ構成


 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


注:
  • Pause を設けずにシナリオを実行すると、ログアウトを待たずに次々にセッションが実行され、最大同時接続数25を超過するエラーが発生して伝票作成に失敗するため、WD15 では 1 秒、WD14 では 1.5 秒 の Pause 時間を設けました。両者で 0.5 秒の差があるのは、WD14 を 1 秒で設定すると、同様のエラーが多数したためです。この点からも、WD15 のパフォーマンスが改善していることがわかります。
  • シナリオ実行後は出庫伝票が 250 個作成されていることを目視で確認しています。未作成レコードがある場合、下表に記載しています。

テスト結果

WebDirect 14 vs 15 出庫レコード作成時のパフォーマンス(Fails は作成に失敗したレコード数)

Peformance comparison graph on CPU cores and memory

考察


※WD14 vs WD15 の比較

 サーバリソースにかかわらず、WD15 は WD14 に比し、30%程度実行速度が改善されました。

※サーバリソースと実行速度の改善

 サーバリソースを 1core/2GB から 2core/4GB に増やすと、WD15 で約 50%、WD14 で約 40%、実行速度が改善されました。
 さらにリソースを 2core/4GB から 4core/8GB に増やすと速度は改善されたものの、改善率はそれぞれ 20%弱と 15%弱となりました。このことから、リソース割り当てを増やせば実行速度は改善するが、その改善率は徐々に鈍化するものと推定されます。
 
※ CPUの占有率

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


FM WebDirect 15


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

2 Core / 4GB RAM


4 Core / 8GB RAM



FM WebDirect 14

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

2 Core / 4GB RAM


4 Core / 8GB RAM

JMeter テスト環境と運用環境の違い


 最後にJMeterテスト環境と実際の運用環境との違いについて簡単に触れます。下図左のグラフは JMeter でにより伝票作成スクリプトを 1 セッションで 1 回実行したときのもので、右のグラフはブラウザ上から手動により伝票作成スクリプトを1回実行したときのものです。サーバのリソースは共に 1core/2GB です。 JMeter では CPU のピーク時の占有率が約 20%であるのに対して、ブラウザでは 80%弱となっています。

 今回は WD14 と WD15 の比較とサーバリソースの増減によるパフォーマンスの変化をテーマとしているためあまり問題ではないと思いますが、実際の運用環境を JMeter によりシミュレートしようとする場合は、JMeter のシナリオを如何に運用環境に近づけるかが大きな課題となります。ただ、JMeter は実行するタイミングによってパフォーマンスにばらつきが出たり(実機でもそうですが)、シナリオを WD の運用環境に近づけるのはかなり難しかったりするため、その差分を係数化し、JMeter ではその係数分の負荷を余計にかける、などの補正が必要かもしれません。
 たとえば、下図のような状況であれば係数を 0.25 とし、運用環境で 20 ユーザが 10 秒間に 1 回レコード保存を実施すると想定されるのであれば、Ramp-up は 10 秒ではなく、2.5 秒に設定し、必要な回数のループを実行する、というのは一案と思われます。 


 それでも納得できないお客様に遭遇してしまった場合wは、必要台数分の仮想マシンや VDI 環境を用意し、FileMaker スクリプトを各仮想マシンから一斉に実行するような仕掛けが必要になるかもしれません。
 


その他の情報

ここでは、今回の JMeter による WD パフォーマンス測定で得られたその他の情報をまとめます。
  1. JMeter で WebDirect にリクエストを発行すると、タイムスタンプが狂う

    レコード作成日時を記録するためのフィールドをタイムスタンプ型にしておくと、JMeter 経由で WD のレコードを作成/修正すると、タイムスタンプが協定世界時刻(UTC)になってしまうことがあります。

    この設定では、JMeter 経由でのレコード作成時に協定世界時が記録されてしまう

     つまり、日本時刻では 9 時間のズレが生じることになりますが、以下のようにホストのタイムスタンプを自動入力させることでこれを回避できます。

    Get( ホストのタイムスタンプ ) を計算値として自動入力することで時刻の狂いを回避

    または、Get ( 現在の時刻 UTC ミリ秒 ) を使って日本時間を算出することもできます。

    計算式:
    GetAsTimestamp ( ( Get ( 現在の時刻 UTC ミリ秒 ) + ( 9 * 3600000 ) ) / 1000 ) 

  2. WD14 と WD15 の挙動の違い

    WD14 でレコードを作成したり、修正したりすると、FileMaker で記録されるユーザ名は [WebDirect] ですが、WD15 では [WebDirect-XXXXX]という形式でユーザ名が記録されます。

    この XXXXX の部分は WD 実行時のセッションID(32桁、16進数文字列)の最後の 5 桁となり、各 WD ユーザを識別しやすくなっているといえるでしょう。

    FileMaker Pro 15 のヘルプにもこの解説がありますので、興味のある方は参考にしてみてください。

    Get ( ユーザ名 ) の説明
    Get ( 持続 ID ) の説明



(亀)

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-25

FileMaker 5.5/6 をモバイルで使う

 FileMaker 15 がリリースで盛り上がる?中、前回は FileMaker 5.5/6 って最高!という記事を書きました。

 開発サイドとしては、機能強化された最新の FileMaker を利用していただけると助かるのですが、コスト、対応デバイス、環境変更の手間等々の事情により、そう簡単にアップグレードできない企業・組織ユーザも多いのでは、と思われます。そうしたユーザの中には「現行の FileMaker システムは順調に稼働しているので苦労してアップグレードはしたくない。でも、モバイルでは利用したいよね」、みたいなところもあるのではないかと思います。

 そんなわけで、「この会社は一体何を考えているのか」という冷ややかな視線を感じつつ、今回は FileMaker 5.5/6 によるモバイル使用を試してみます。
 とは言いつつも、モバイル用のリモートデスクトップアプリを介してFM5.5/6を使用する、というだけなので、「なにを今さら」と思う方もいらっしゃると思います。小社でも以前、いくつかのリモート接続ツール(Remote とか iRdesktop とか iTapRDP )を試してみて、「これでFMデータベース操作するのは厳しい」と思い込み、最近は完全ノーマークでした。ところが Microsoft 社からリリースされているモバイル用 Remote Desktop Client というアプリを恥ずかしながら最近知り、これならなんとか使えるかも、と思い始めた次第です。

注:
言わずもがなですが、iPhone/iPad 上のFileMaker Go を使用すれば FileMaker Server に直接接続できます。本稿は、FileMaker Go は利用できない、あるいは Android やSurface で FileMaker を使用したいという方向けへの記事ともなっています。 

概要と準備するもの


 モバイル機器からの FileMaker データベース接続イメージはこのようになります。

モバイル機器による旧バージョン FileMaker データベース接続イメージ

 上記のように構成する場合は、以下の環境が必要となります。


 FMモバイルアクセス環境
  1. FileMaker Server
  2. FileMaker Pro アプリケーション(クライアント数分のライセンスが必要)
  3. タブレットPCやスマートフォンなどのモバイル機器
  4. リモートデスクトップサーバやVDI等の仮想デスクトップ環境(ここで FileMaker Pro を起動し、サーバにアクセス)
  5. モバイル用Microsoft Remote Desktop(Android / iOS

 FileMaker Server、FileMaker Pro、仮想デスクトップ環境(上記4)の各種設定の説明は省略しますが、 仮想デスクトップ環境では、下図のようにPC のプロパティより「リモートの設定」を選択してリモート接続を許可する点にご留意ください。




操作手順


 今回は FileMaker Server 5.5でデータベース(本例では、小社の旧商品「売上猫くん 4.5」(FileMaker 5.5/6対応)を公開し、仮想デスクトップ環境を介してAndroid タブレット PC (Nexus7)からアクセスする方法を順を追ってご紹介します。

  1. タブレット PC に Microsoft Remote Desktop アプリをインストールします。

    Google Play を開き、MS Remote Desktop を検索し、インストールします。



    【iOS用の Microsoft Remote Desktop アプリ】

    iOS をご利用の方は、Apple ストアから Microsoft Remote Desktop アプリを入手してインストールすれば、同様に操作できるようになります。

  2. RD Client アイコンをタップします。

    ホーム画面に RD Client アイコン(←Microsoft Remote Desktop のアイコン)が表示されますので、これをタップします。


  3. リモートデスクトップ接続を追加します。

    Remote Desktop Client アプリが起動します。
    画面右上の+アイコンをタップします。


  4. Desktop を選択します。

    追加可能な項目の一覧が表示されますので、その中から Desktop を選択します。

  5. リモートデスクトップ接続情報を入力します。

    表記はすべて英語となりますが、最低限接続先のPC名(または IP アドレス)とユーザ名を設定するだけでも接続できるようになります。

    下図では、フレンドリ名として nekodemo を入力していますが、これは必須ではありません。



  6. 共有先の Windows PC に接続します。

    接続情報を保存すると、nekodemo という名前のアイコンが画面に追加されますので、これをタップします。

  7. ログイン情報を入力します。

    共有先の PC に接続すると、ログインダイアログが表示されますので、Windows PC へのログイン情報を入力し、“Connect”ボタンをタップします。



    ※このアプリの仕様と思われますが、接続後の画面設定は縦置き表示ができないため、以降は、デバイスを横置きにした状態で操作を進めます。
  8. マウスポインタをタッチパネルに切り替えます。

    ログインに成功すると、おなじみのリモートデスクトップ画面がモバイル PC 上に表示されます。



    画面上部のポインタ切り替えアイコンをタップします。すると、画面表示が以下のように変わります。

    画面右の“Touch”アイコンをタップすることによって、マウスポインタをタッチパネルモードに切り替えます。

  9. ズームインモードに切り替えます。

    モバイル PC 上のリモートデスクトップ画面はとても文字が小さいという難点があります。
    リモート共有 PC側でフォントサイズを大きくしても、これは Remote Desktop アプリでは有効にならないため、文字サイズは小さいままとなります。

    ここで、ズームモードに切り替えて操作してみましょう。
    画面上部の虫眼鏡アイコンをタップします。

    すると、デスクトップがズームインされ、画面に十字矢印のアイコンが表示されます。



    この十字矢印に指を乗せて画面をなぞることによって、デスクトップの表示領域を移動します(多少の慣れが必要です)。
    以降、しらばらくはズームイン状態のまま操作します。
  10. FileMaker 起動後、スクリーンキーボードを使って『売上猫くん4.5』にログインします。

    画面上の FileMaker Pro 5.5/6.0 アイコンを二回連続でタップすると、FileMaker Pro アプリケーションが起動します。
    共有ファイルより、『売上猫くん4.5』のメニューファイルを開きます。

    以下は FileMaker Server 5.5 で公開されている『売上猫くん4.5』のログイン画面が表示されたところです。
    [パスワード]入力ボックスをタップしてもスクリーンキーボードは表示されませんので、画面上部に配置されているスクリーンキーボードアイコンをタップします。



    スクリーンキーボードが表示されますので、パスワードを入力して Enter キーをタップしてログインします。

  11. 『売上猫くん4.5』を操作してみます。

    リモートデスクトップ共有で『売上猫くん 4.5』を操作しているため、ご覧のようにファイルメーカー Pro のメニューバーは表示されたままの状態となります。



    “顧客(仕入先)”ボタンをタップすると、顧客仕入先画面が表示されます。
    ご覧のように、表示はモバイル PC 用に最適化されていないため、画面の一部が切れた状態となります。



    ここで、画面上部に表示されている虫眼鏡アイコンをタップすることにより、ズームイン状態を解除します。



    これにより、デスクトップ全体表示に戻ります。
    各画面の情報照会はズームインモード、一覧データを照会する際はデスクトップ全体表示にするなど工夫が必要かもしれません。

    (参考:住所録表示)

  12. 日本語入力に切り替えて、テキストを入力します。

    Remote Desktop アプリケーションは、接続直後の入力モードは英語(EN)となります。
    日本語のテキストを入力するには、日本語入力モードに切り替えてから使用する必要があります。



    リモートデスクトップの右下に表示されている EN アイコンをタップし、JP (日本語)に切り替えます。

    そして、日本語を入力したい画面のテキストボックスをタップし、手順10.の要領で画面上のキーボードアイコンをタップしてスクリーンキーボードを呼び出します。

    このとき、お使いのモバイル PC によってはキーボードが英語のままになっているため、キーボード下部の English をタップすることによって、日本語キーボードに切り替えます。





    日本語入力をしてみましょう。以下は「てすとにゅうりょく」とローマ字打ちしてから、候補の中から「テスト入力」を選ぼうとしているところです。



    ご覧のように、[備考]フィールドに「テスト入力」と入力できました。


 以上、使い勝手はモバイルに最適化されたFileMaker Go にはかないませんが、モバイル版Microsoft Remote Desktop による FileMaker データベースの操作は、想像以上に快適に思いました。もともとリモートデスクトップはLAN上の仮想デスクトップで処理を行い、画面イメージのみをリモート端末に送るので高速です。また、モバイル機器に比べて、プリンタ等の周辺機器もPC同様に使用できるメリットもあります。
 種々の事情から FileMaker Go を利用できないユーザの方は、Microsoft Remote Desktop の利用を検討されてはいかがかと思います。

 時間があれば、旧FileMaker のアプリをモバイル用に無理やりカスタマイズしたらどのくらい操作性が向上するのか、とかも記事にしたいなぁと思っています。
 
 なお、セキュアなモバイル接続については、下記のページが参考になるかと思います。
 最終回 遠隔地のAndroid/iOS端末から社内PCにリモートデスクトップ接続する (1/2)



■ 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 の意外な利点。



参考リンク:
Microsoft Remote Desktop アプリダウンロードページ(Android)
Microsoft Remote Desktop アプリダウンロードページ(iOS)


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


(亀)