昨日対応、結果的に不思議な結末となりました。
ちなみに先日のタイムアウト時間を変更したら、
かわったのかかわらかったのか、
即時ではないぽい。
反応なかったのでAggregateや拡張SQLに設定できるので
とりあえず１２０００としたらきっちり使いきってタイムアウトで落ちた。
タイムアウト時間を調整してもだめな場合があることがわかった。
今回は、デフォルトのＤＢのたタイムアウト時間の変更と、
部品単位のタイムアウトの設定にて、
部品単位のタイムアウト時間がからだったらたぶんデフォルトのやつが反映されるだろうそして、パブリッシュしたときにその設定がいじされるのかな？
ということで解決しなかったので、
Aggregateで実装されたのを、
昔からあったのか新しくできたきのうなのが、
拡張SQLに焼き直ししてくれる機能があったので、
それを使って焼き直す。
その際に、ストラクチャに必要な項目だけにして、
一部Assignで条件で値を設定していたのでSQLのCASE文で作り直す。
なんかSQLエラー起こすので、あやしいCASE文のところをなくすと
おータイムアウト解消した。
じゃCASE文なおして、動くようにしたら解決！とおもったら
Aggregateときと同じ症状となり同じかんじでタイムアウト
うそだろ！（ユーチューバーおじおじ風）
とりあえず。
このあとoutsystemsのコミュニティで
aggregate timeout で情報を仕入れ対応方法が原因と対応方法が見えてきた
データベースへの要求は通ってるポイ、なんでかというと
データベース側ではエラーがはかれないから、
そう考えるとデータベース側から渡されたデータをoutsystems側で受け取り切れない、
受け取りの際になんらかのリトライが発生しているので、
タイムアウトを延ばしても無限ループのようにタイムアウト時間を消費しているようだ。
outsystemsの見解といては以下のようだ
①最大レコード数を設定してデータ量を制御する
maxrecordの設定ですね
今回は10191件で、元データは25万件ほどから19テーブル結合してだしている
バッチ処理なので、これはできないので今回は対象外
②抽出項目を限定する拡張SQLを使用する
これは試して一部成功するも、許容範囲を超えてしまい失敗。
結果Aggregateと同じなった見解も、Aggregateでは、使用しているデータに
最適化する仕様となっているので、意識しなくても拡張SQLと同じような結果と
なっていたおまじない程度に、やってみたがまさか同じ流れになるとは。
③②を行ったうえで、業務仕様を見直し、取得項目を減らして
取得データを減らす
これは、今回は最終局面と考えなし
④元データ25万件のトランザクションデータの
インデックスの再編成
こちらが一番対応としてはコメントがおおかった
いまこちらを対応中で、インデックスをDROPして再作成して
まったく修正していないソースを動かすとうごくそうな
データ量とは関係ないようなのだが、これだととれるみたい。
⑤EXTANALDBで外部DBの場合は、リソースを増やすとだけ書いてあった。
設定ではなく、DB側の変えろということみたい。
ということで、場面によって①～⑤の対応と前回やった
タイムアウト時間を変更する合計６パターンの対応があるようだが
めんどうだがパフォーマンスをあげるには④が一番効果が大きいようだ。
今回のトラブルは、なかなか勉強になった。
