初心者のFileMaker pro Q&A (旧掲示板)

Valon

Member

サーバースクリプト実行中のパフォーマンス

お世話になっております。

FileMaker Pro, Server 20.1.2
OS：Windows 10 & Windows Server 2019

サーバースクリプト※①実行中に、別のサーバースクリプトを実行した時のFileMaker Proでのパフォーマンスが良くないです。
①で実行している主なスクリプト内容は、外部API通信を利用したデータ取得、更新やファイルからのインポートととなり、１日中Loopしています。

①を実行中に、別のサーバースクリプトを実行すると通常1秒のところ7～15秒程度かかったりします。
①が動いていないときや、新たに別のサーバースクリプトを実行させていない時にはパフォーマンスに問題ありません。

スクリプト内容によると言われればそれまでなのですが、
ここの設定を見直すべき、小技などがあれば教えていただけますでしょうか。
Windows Serverのマシンスペックは低くはないと思います・・・
（Intel(R) Xeon(R) E-2334 CPU @ 3.40GHz   64.0 GB）

原因の１つと思われる箇所に、APIでデータを取得する際に、データが重すぎて数秒固まっています。
「〇〇」の処理をサーバーに行わせている時は、特に重くなる 等の情報でも構いません。

よろしくお願いいたします。

Shin

Member

Re: サーバースクリプト実行中のパフォーマンス

①で実行している主なスクリプトを、クライアントで実行して見て比較されるとどうでしょう。
apiを使ったデータ取得は、連携先の応答時間がありますので、件数が多くなってくると相当の時間になります。また、ファイルからのデータインポートは、レコードの抽出にそれなりに時間がかかる上に、レコード数が多いとインポート後のインデックスの書き換えにそれなりの時間がかかっているでしょう。
それらをクライアント側で実行させると、他のクライアントへの影響は、データとインデックスの送受のみになります。連携の待ち時間やインデックスの編集時間は、ローカルですので、影響を与えないはずです。
一度試してみてください。

himadanee

Guest

Re: サーバースクリプト実行中のパフォーマンス

＞①を実行中に、別のサーバースクリプトを実行すると通常1秒のところ7～15秒程度かかったりします。
スケジュールのスクリプトですよね？同時には実行できないので、先に実行しているスクリプトが終わるまで待たされるのでしょう。
昔のバージョンで「スクリプトキューは「スケジュールスクリプト」「バックアップ」の2系列ある」という説明を読んだ記憶があるのですが、ナレッジベースを「キュー」で検索しても何も出てこない...

クライアントから実行する「サーバー上のスクリプト実行」であれば、仮想クライアントをそれぞれに作るので、同時実行される（同時最大数の設定があったはず）と思いますが、
「インポート」がレコードの追加でなく更新だと、レコードにロックがかかって同時実行は不可能になりますよね？
インポートでなくても排他処理が必要な場合は待たされたりエラーになったりする可能性はあります。

Valon

Member

Re: サーバースクリプト実行中のパフォーマンス

Shin 様
いつもありがとうございます。

①で実行しているスクリプトは、開発段階でそれなりに動作に時間が必要なことは確認できております。
１日中Loopさせている＆プラグイン使用ため、クライアントでの実行にすることはできず、クライアントから停止することもあるためサーバーで実行させておく必要がございます。
逆に別のサーバースクリプトをローカル実行にしてみようと思います。 重めの処理は何でもかんでもサーバーにやらせているので、見直してみたいと思います。

himadanee様
いつもありがとうございます。

①も、別のサーバースクリプトもスケジュールではなく、同一スクリプトでもございません。
分かり辛く申し訳ないです。
同時最大数は記憶している限り数百だったと思います。

Shin

Member

Re: サーバースクリプト実行中のパフォーマンス

解決になっていますが
> １日中Loopさせている＆プラグイン使用ため、クライアントでの実行にすることはできず、
FMS でしか動かないプラグインですか、環境的に限定されるのですか
以前の職場で、無停止でスクリプトを回しているクライアントを作っていました。基幹から送られてくるテキストデータを数分ごとに監視し流し込む動きでした。単純な動きなので当初サーバースケジュールで動かすつもりだったのですが、サーバーの応答性がかなり落ちたので、そのファイルの転送の手間も含めて、専用クライアントを立てて動かしていました。
himadaneeさんの指摘の様に、レコードの更新があり、場合によってはリトライもありましたが、順調に動いていました。管理も楽でした。
ご参考まで