データ取得時のパフォーマンス向上について
- このフォーラムに新しいトピックを立てることはできません
- このフォーラムではゲスト投稿が禁止されています
データ取得時のパフォーマンス向上について
msg# 1
haisei
投稿数: 9
はじめて投稿させていただきます。
Magic歴1ヶ月のホヤホヤです。
uniPaas V1.9g2 + SQLServer2008 で
クラサバシステムを開発させていただいておりまして、
データをクラウドに徐々に移行しているのですが、
レスポンスが遅くなるのが気になってきました。
回線などの問題はさておき、
なんとかMagic側で改善できることはないものかと
色々調べているところです。
手始めにメインソースで指定しているところに対して
3つのパターンで速度を計測してみたところ
メインソース>メインソース+宣言>SQLコマンド
となり、SQLコマンドで取得するほうが
高速であることがわかりました。
ですが、後々のメンテナンスなどのことも考えると、
SQLコマンドでの取得するのは・・・とも考えています。
Magic.iniなどの設定は特に触っていないのですが
他に対策などがあったりしますでしょうか。
Magic歴1ヶ月のホヤホヤです。
uniPaas V1.9g2 + SQLServer2008 で
クラサバシステムを開発させていただいておりまして、
データをクラウドに徐々に移行しているのですが、
レスポンスが遅くなるのが気になってきました。
回線などの問題はさておき、
なんとかMagic側で改善できることはないものかと
色々調べているところです。
手始めにメインソースで指定しているところに対して
3つのパターンで速度を計測してみたところ
メインソース>メインソース+宣言>SQLコマンド
となり、SQLコマンドで取得するほうが
高速であることがわかりました。
ですが、後々のメンテナンスなどのことも考えると、
SQLコマンドでの取得するのは・・・とも考えています。
Magic.iniなどの設定は特に触っていないのですが
他に対策などがあったりしますでしょうか。
投票数:0
平均点:0.00
Re: データ取得時のパフォーマンス向上について
msg# 1.1
pu_mahalo
居住地: 大阪
投稿数: 775
こんにちは Puです
C/Sな作りである以上、回線の帯域に影響されますので
それが限界かと思います。
きをつける事は
グリッド(テーブル)コントロールのsort=Y列を使わない
等、サーバーとクライアントとの通信量を減らすしかないと思います
C/S以外の方法も選択肢に入れるなど、方法で対応するしか
今のところはないのかと思っています。
私もヒントが欲しいです。
でわ〜でわ〜
C/Sな作りである以上、回線の帯域に影響されますので
それが限界かと思います。
きをつける事は
グリッド(テーブル)コントロールのsort=Y列を使わない
等、サーバーとクライアントとの通信量を減らすしかないと思います
C/S以外の方法も選択肢に入れるなど、方法で対応するしか
今のところはないのかと思っています。
私もヒントが欲しいです。
でわ〜でわ〜
投票数:0
平均点:0.00
Re: Re: データ取得時のパフォーマンス向上について
msg# 1.1.1
ISHIJIMA
居住地: 静岡県
投稿数: 1827
アマゾンのRDS等でやってみるのも1つですかね・・
投票数:0
平均点:0.00
Re: データ取得時のパフォーマンス向上について
msg# 1.2
pu_mahalo
居住地: 大阪
投稿数: 775
こんにちは
amazon rdsもazureのSQLdatabaseも c/sで使用するなら
帯域に影響されますので
やはり RDS(RemoteDeskTop)やRIAなどc/s以外も視野に入れるのが
よろしいかと思いました
私はc/sの場合VPNの設定で出来るだけ帯域を使いきるように設定してます
でわ〜でわ〜
amazon rdsもazureのSQLdatabaseも c/sで使用するなら
帯域に影響されますので
やはり RDS(RemoteDeskTop)やRIAなどc/s以外も視野に入れるのが
よろしいかと思いました
私はc/sの場合VPNの設定で出来るだけ帯域を使いきるように設定してます
でわ〜でわ〜
投票数:0
平均点:0.00
Re: データ取得時のパフォーマンス向上について
msg# 1.3
Tanda
投稿数: 2151
そうですね、選択肢としては皆さんがおっしゃる通り、3種類あるわけ
ですから、どれが最適か費用対効果で試されるとよろしいですね。
1. クライアント・サーバでSQLにダイレクトアクセス
2. Remote Appで画面とキーボード情報だけやり取り
3. RIAでチャンクデータだけのやり取り
ですから、どれが最適か費用対効果で試されるとよろしいですね。
1. クライアント・サーバでSQLにダイレクトアクセス
2. Remote Appで画面とキーボード情報だけやり取り
3. RIAでチャンクデータだけのやり取り
投票数:0
平均点:0.00
Re: データ取得時のパフォーマンス向上について
msg# 1.4
haisei
投稿数: 9
pu_mahalo 様
ISHIJIMA 様
Tanda 様
お忙しい中ご回答いただき誠にありがとうございます。
回線の帯域についてはVPNの設定をもう少し見るようにしたいと思います。
ただ、このあたりはまだまだ自分自身が理解不足でして、
ここの設定は絶対に見といたほうが良いよ(このサイト見たら参考になるよ)
などありましたらご教授いただけると大変嬉しいです。
なるべく通信量を減らすという点では、
めったに更新されないマスタデータを
起動時に「SQLコマンド」で取得して「Memoryテーブル」に
読み込むような工夫(+運用上の工夫)はしてみました。
その際、Magicの「常駐テーブル」の機能を
使おうとしたのですが取得速度が
上記手法より遅くてあきらめました。
sort=Yを使わないといったMagic上のテクニックは
全然知らなかったのでアプリケーション内で
使ってないか調べてみます。
C/S以外の方法の検討については
最後の砦として考えたいと思っておりますが、
速度向上の選択肢として挙げていただけたこと
非常に参考になります。
なお、RemoteDeskTop(RemoteAppと同じ?)というのは
アプリをクラウドに配置してリモートデスクトップ接続で
クラウドに繋いで操作するといった感じでしょうか?
長々と書きましたが、本当に回答いただきありがとうございます。
ISHIJIMA 様
Tanda 様
お忙しい中ご回答いただき誠にありがとうございます。
回線の帯域についてはVPNの設定をもう少し見るようにしたいと思います。
ただ、このあたりはまだまだ自分自身が理解不足でして、
ここの設定は絶対に見といたほうが良いよ(このサイト見たら参考になるよ)
などありましたらご教授いただけると大変嬉しいです。
なるべく通信量を減らすという点では、
めったに更新されないマスタデータを
起動時に「SQLコマンド」で取得して「Memoryテーブル」に
読み込むような工夫(+運用上の工夫)はしてみました。
その際、Magicの「常駐テーブル」の機能を
使おうとしたのですが取得速度が
上記手法より遅くてあきらめました。
sort=Yを使わないといったMagic上のテクニックは
全然知らなかったのでアプリケーション内で
使ってないか調べてみます。
C/S以外の方法の検討については
最後の砦として考えたいと思っておりますが、
速度向上の選択肢として挙げていただけたこと
非常に参考になります。
なお、RemoteDeskTop(RemoteAppと同じ?)というのは
アプリをクラウドに配置してリモートデスクトップ接続で
クラウドに繋いで操作するといった感じでしょうか?
長々と書きましたが、本当に回答いただきありがとうございます。
投票数:0
平均点:0.00
Re: データ取得時のパフォーマンス向上について
msg# 1.5
nkmt
投稿数: 1668
補足します。
Puさんが言われている
sort=Y列 はテーブルコントロール(言語系で言うグリッド?)
のカラムタイトル をクリックして、
その 列の値で ソートさせると、その分データ参照し直しに
行くので、カラムソート=不可 にした方がいいかもしれない
という意味だと思います。
Puさんが言われている
sort=Y列 はテーブルコントロール(言語系で言うグリッド?)
のカラムタイトル をクリックして、
その 列の値で ソートさせると、その分データ参照し直しに
行くので、カラムソート=不可 にした方がいいかもしれない
という意味だと思います。
投票数:0
平均点:0.00
Re: データ取得時のパフォーマンス向上について
msg# 1.6
haisei
投稿数: 9
nkmt 様
sort=Yに関しての詳細な情報をいただき
ありがとうございます。
グリッドという表現も助かります。
ソートをするとデータを再度読み込むというわけですね。
明細の画面も数多くあるので調べてみます。
sort=Yに関しての詳細な情報をいただき
ありがとうございます。
グリッドという表現も助かります。
ソートをするとデータを再度読み込むというわけですね。
明細の画面も数多くあるので調べてみます。
投票数:0
平均点:0.00
Re: データ取得時のパフォーマンス向上について
msg# 1.7
pu_mahalo
居住地: 大阪
投稿数: 775
nkmtさん 補足説明ありがとうございます。
私の使用しているvpnソフトはtcpのコネクション数を変更できるので
複数コネクションを利用して帯域を稼いでます。
RemoteAPPはサーバー上でアプリが動作し その画面情報とキーボード
情報だけが圧縮されて送られるので
データ量が非常に少ないです。
でわ〜でわ〜
私の使用しているvpnソフトはtcpのコネクション数を変更できるので
複数コネクションを利用して帯域を稼いでます。
RemoteAPPはサーバー上でアプリが動作し その画面情報とキーボード
情報だけが圧縮されて送られるので
データ量が非常に少ないです。
でわ〜でわ〜
投票数:0
平均点:0.00
Re: データ取得時のパフォーマンス向上について
msg# 1.8
nkmt
投稿数: 1668
本社内は、社内に置いたWindowsサーバーとPCをクラサバで、
営業所からは、そのWindowsサーバー内のMagicを
RemoteAPPで利用するという事はよくやってます。
営業所のPCにもMagicを入れて、本社のSQLサーバーのデータを
直で読み書きというのも可能なようですが未経験です。
haiseiさんが今されているのも似たような事ですね。
ちょっと話逸れますが
RemoteAPPの場合、何台ぐらいまでが現実的なんですかね?
WindowsRemoteCALが1台3万円前後するのでしょうか?
自分のやり方だと、リモートユーザーがもし30台いれば
先程のCALも30本必要だし、Windows上へのユーザー登録も30名分
必要でしょうし。
ターミナルサーバーも1台でまかなえるユーザー数に限界もあるのでしょうね。
私の経験ではリモートのユーザー数はせいぜい10台止まりです。
100台、200台になるとWebやRIAの出番なんですかね?
これぐらいの台数だとRIAの事例も結構ありますよね。
RemoteAPPは光はもちろんですがADSLでも速度に不満はありませんでした。
距離にも影響すると思いますけど。
ADSLの場合は、印刷データの場合、数秒待つという事もありました。
営業所からは、そのWindowsサーバー内のMagicを
RemoteAPPで利用するという事はよくやってます。
営業所のPCにもMagicを入れて、本社のSQLサーバーのデータを
直で読み書きというのも可能なようですが未経験です。
haiseiさんが今されているのも似たような事ですね。
ちょっと話逸れますが
RemoteAPPの場合、何台ぐらいまでが現実的なんですかね?
WindowsRemoteCALが1台3万円前後するのでしょうか?
自分のやり方だと、リモートユーザーがもし30台いれば
先程のCALも30本必要だし、Windows上へのユーザー登録も30名分
必要でしょうし。
ターミナルサーバーも1台でまかなえるユーザー数に限界もあるのでしょうね。
私の経験ではリモートのユーザー数はせいぜい10台止まりです。
100台、200台になるとWebやRIAの出番なんですかね?
これぐらいの台数だとRIAの事例も結構ありますよね。
RemoteAPPは光はもちろんですがADSLでも速度に不満はありませんでした。
距離にも影響すると思いますけど。
ADSLの場合は、印刷データの場合、数秒待つという事もありました。
投票数:0
平均点:0.00
Re: データ取得時のパフォーマンス向上について
msg# 1.9
haisei
投稿数: 9
pu_mahalo 様
VPNの情報ありがとうございます。
TCPのコネクション数ですね・・・調べてみます。
(VPNソフトは使ってないのでハードの設定かもです)
pu_mahalo 様
nkmt 様
RemoteAPPの情報もありがとうございます。
ADSLでも速度に不満がないというのはすごいです。
少しずつ調べてみているところなのですが、
http://cloud.watch.impress.co.jp/epw/cda/special/2007/11/29/11674.html
古い記事ですがローカルPCのハードウェアも利用できるのですね。
(初心者丸出しでごめんなさい・・・)
現在、結構な台数利用しているので
リモートユーザー数の考慮などを考えると
ちょっと厳しいかもしれないですが
工夫して利用できれば良いなと思います。
VPNの情報ありがとうございます。
TCPのコネクション数ですね・・・調べてみます。
(VPNソフトは使ってないのでハードの設定かもです)
pu_mahalo 様
nkmt 様
RemoteAPPの情報もありがとうございます。
ADSLでも速度に不満がないというのはすごいです。
少しずつ調べてみているところなのですが、
http://cloud.watch.impress.co.jp/epw/cda/special/2007/11/29/11674.html
古い記事ですがローカルPCのハードウェアも利用できるのですね。
(初心者丸出しでごめんなさい・・・)
現在、結構な台数利用しているので
リモートユーザー数の考慮などを考えると
ちょっと厳しいかもしれないですが
工夫して利用できれば良いなと思います。
投票数:0
平均点:0.00
Re: Re: データ取得時のパフォーマンス向上について
msg# 1.9.1
Tanda
投稿数: 2151
haiseiさん、
RemoteAPPはもともと回線のスピードが遅かった時代に編み出された
テクノロジーですので、ADSLとかでも問題なく動きます。
行き来するデータは画面描画情報とキーボード入力情報だけですから、
DB等の実データは転送されません。
ただしその分サーバの負担が増えますので、クライアント数が増えれば
増えるほど、全体のパフォーマンスに影響します。
RemoteAPPはもともと回線のスピードが遅かった時代に編み出された
テクノロジーですので、ADSLとかでも問題なく動きます。
行き来するデータは画面描画情報とキーボード入力情報だけですから、
DB等の実データは転送されません。
ただしその分サーバの負担が増えますので、クライアント数が増えれば
増えるほど、全体のパフォーマンスに影響します。
投票数:0
平均点:0.00
Re: データ取得時のパフォーマンス向上について
msg# 1.10
haisei
投稿数: 9
Tanda 様
RemoteAPPの解説、誠にありがとうございます。
ポイントはクライアント数が増えると
パフォーマンスとライセンスなどの
課題がでてくるというところですね・・・。
RemoteAPPの解説、誠にありがとうございます。
ポイントはクライアント数が増えると
パフォーマンスとライセンスなどの
課題がでてくるというところですね・・・。
投票数:0
平均点:0.00
Re: データ取得時のパフォーマンス向上について
msg# 1.11
nkmt
投稿数: 1668
haiseiさんの今回の件は、結構な台数を利用するとの事ですので
Tandaさんの言う
1. クライアント・サーバでSQLにダイレクトアクセス
2. Remote Appで画面とキーボード情報だけやり取り
3. RIAでチャンクデータだけのやり取り
だと、1か3の選択になるんでしょうかね。
もし500台といった台数だと3なのでしょうね。
Tandaさんの言う
1. クライアント・サーバでSQLにダイレクトアクセス
2. Remote Appで画面とキーボード情報だけやり取り
3. RIAでチャンクデータだけのやり取り
だと、1か3の選択になるんでしょうかね。
もし500台といった台数だと3なのでしょうね。
投票数:0
平均点:0.00
Re: Re: データ取得時のパフォーマンス向上について
msg# 1.11.1
Tanda
投稿数: 2151
そうですね、RIAがお勧めですね。
特にクライアントの台数が多い場合は、RIAが圧倒的に保守が
楽ですね。
特にクライアントの台数が多い場合は、RIAが圧倒的に保守が
楽ですね。
投票数:0
平均点:0.00
Re: データ取得時のパフォーマンス向上について
msg# 1.12
nkmt
投稿数: 1668
普段からそうしてますけど
クラサバだと普通はMagic実行版をPC1台1台に入れる手間が
必要ですもんね。
haiseiさんの場合、SQL Serverなので、PCにはPervasiveは
要らないと思いますが、Pervasiveのシステムだとそれも入れる手間、
PCCでの設定も必要ですし、大変でしょうね。
Magicのプログラミングの保守性で比較すると
クラサバとRIAは同じぐらいか、RIAの方が工数かかる
といった感じですかね????????
クラサバだと普通はMagic実行版をPC1台1台に入れる手間が
必要ですもんね。
haiseiさんの場合、SQL Serverなので、PCにはPervasiveは
要らないと思いますが、Pervasiveのシステムだとそれも入れる手間、
PCCでの設定も必要ですし、大変でしょうね。
Magicのプログラミングの保守性で比較すると
クラサバとRIAは同じぐらいか、RIAの方が工数かかる
といった感じですかね????????
投票数:0
平均点:0.00
Re: データ取得時のパフォーマンス向上について
msg# 1.13
haisei
投稿数: 9
nkmt 様
Tanda 様
既存システムをRIA化することによって
速度改善などの恩恵を受けれそうな期待はあるのですが
作り変えないといけない部分も多いような気がしていて
その1つに現状のシステムのRM互換のイベント化・・・でしょうか。
その他にも注意事項などがあるとは思うのですが、
そこまで調べきれてないのが現状です。
通信量を減らすという点では、
例えば、明細画面において、
検索結果の表示を50件単位などして、
ページャーでページ移動するなどが
有効かな思ったりしているのですが、
そういうことってされてますか??
Tanda 様
既存システムをRIA化することによって
速度改善などの恩恵を受けれそうな期待はあるのですが
作り変えないといけない部分も多いような気がしていて
その1つに現状のシステムのRM互換のイベント化・・・でしょうか。
その他にも注意事項などがあるとは思うのですが、
そこまで調べきれてないのが現状です。
通信量を減らすという点では、
例えば、明細画面において、
検索結果の表示を50件単位などして、
ページャーでページ移動するなどが
有効かな思ったりしているのですが、
そういうことってされてますか??
投票数:0
平均点:0.00
Re: Re: データ取得時のパフォーマンス向上について
msg# 1.13.1
Tanda
投稿数: 2151
> 検索結果の表示を50件単位などして、
> ページャーでページ移動するなどが
これがまさにRIAで言うところの「チャンクサイズ」ですね。
タスク特性で設定できます。
クライアントサーバですとプログラムを作る必要がありますね。
> ページャーでページ移動するなどが
これがまさにRIAで言うところの「チャンクサイズ」ですね。
タスク特性で設定できます。
クライアントサーバですとプログラムを作る必要がありますね。
投票数:1
平均点:10.00
Re: データ取得時のパフォーマンス向上について
msg# 1.14
nkmt
投稿数: 1668
Tandaさん
数百台で使うシステムで、
さらに複数拠点で使うシステムの場合は特に
RIA化が望ましいという事なんでしょうね。
数百台で使うシステムで、
さらに複数拠点で使うシステムの場合は特に
RIA化が望ましいという事なんでしょうね。
投票数:0
平均点:0.00
Re: Re: データ取得時のパフォーマンス向上について
msg# 1.14.1
Tanda
投稿数: 2151
そうですね。それに保守がとても楽ですね。
インストールもアップデートもほとんど自動ですから、
SEが全国を駆け回る必要がないですね。
インストールもアップデートもほとんど自動ですから、
SEが全国を駆け回る必要がないですね。
投票数:1
平均点:10.00
Re: データ取得時のパフォーマンス向上について
msg# 1.15
haisei
投稿数: 9
Tanda 様
なるほどチャンクサイズというのはそのことだったのですね。
タスク特性で設定可能なんてすごいですね・・・。
現状のクラサバでもプログラムを作る必要があるけども
ページャー設置の検討の余地はありそうな予感がしました。
なるほどチャンクサイズというのはそのことだったのですね。
タスク特性で設定可能なんてすごいですね・・・。
現状のクラサバでもプログラムを作る必要があるけども
ページャー設置の検討の余地はありそうな予感がしました。
投票数:0
平均点:0.00
Re: データ取得時のパフォーマンス向上について
msg# 1.16
pu_mahalo
居住地: 大阪
投稿数: 775
こんにちは Puです
c/sでもオンラインタスクのscreenならそんなに遅いと感じません
ただ、zoomアクションなどでグリッドで一覧表示する場合に
遅さを感じます。
(一覧形式での複数データ表示)
ですので、私の場合、最初にloginプログラムでユーザーを宣言し
その方の部署やその方が使用されるであろうデータを初期表示(一覧)にする事で、遅さをカバーしております。
ただバッチは遅いので、日次バッチなどは本社で行ってもらってます
でわ〜でわ〜
c/sでもオンラインタスクのscreenならそんなに遅いと感じません
ただ、zoomアクションなどでグリッドで一覧表示する場合に
遅さを感じます。
(一覧形式での複数データ表示)
ですので、私の場合、最初にloginプログラムでユーザーを宣言し
その方の部署やその方が使用されるであろうデータを初期表示(一覧)にする事で、遅さをカバーしております。
ただバッチは遅いので、日次バッチなどは本社で行ってもらってます
でわ〜でわ〜
投票数:0
平均点:0.00
Re: データ取得時のパフォーマンス向上について
msg# 1.17
haisei
投稿数: 9
pu_mahalo 様
グリッドによる一覧表示(たくさん)であったり、
1画面にたくさんの情報が詰まっている場合は、
どうしても遅さを感じてしまいますので、
このあたりも工夫が必要かなと思っています。
> 最初にloginプログラムでユーザーを宣言し
> その方の部署やその方が使用されるであろうデータを初期表示
これがイメージできなかったのですが、
もう少し詳しく教えていただけると助かります。
グリッドによる一覧表示(たくさん)であったり、
1画面にたくさんの情報が詰まっている場合は、
どうしても遅さを感じてしまいますので、
このあたりも工夫が必要かなと思っています。
> 最初にloginプログラムでユーザーを宣言し
> その方の部署やその方が使用されるであろうデータを初期表示
これがイメージできなかったのですが、
もう少し詳しく教えていただけると助かります。
投票数:0
平均点:0.00
Re: データ取得時のパフォーマンス向上について
msg# 1.18
nkmt
投稿数: 1668
横からコメントですが
例えば、営業さんがシステム起動したら
得意先検索画面には 自分が担当している得意先のみ表示する
とか、自分が営業担当になっている売上伝票だけ表示する
といった事だと思います。
事務担当が起動したら、自拠点管轄の得意先だけ表示など。。。
おそらくそういった事なんでしょうね。
メインPGに、変数用意して、ログオン担当者をその変数に記憶して
いろんな画面からメインPGの変数を参照する事もよくやります。
例えば、営業さんがシステム起動したら
得意先検索画面には 自分が担当している得意先のみ表示する
とか、自分が営業担当になっている売上伝票だけ表示する
といった事だと思います。
事務担当が起動したら、自拠点管轄の得意先だけ表示など。。。
おそらくそういった事なんでしょうね。
メインPGに、変数用意して、ログオン担当者をその変数に記憶して
いろんな画面からメインPGの変数を参照する事もよくやります。
投票数:0
平均点:0.00
Re: データ取得時のパフォーマンス向上について
msg# 1.19
pu_mahalo
居住地: 大阪
投稿数: 775
nkmtさん
いつも詳しい補足説明ありがとうございます。
おっしゃる通りです。
遠隔でなくても こういった機能があると
喜ばれます。
でわ〜でわ〜
いつも詳しい補足説明ありがとうございます。
おっしゃる通りです。
遠隔でなくても こういった機能があると
喜ばれます。
でわ〜でわ〜
投票数:0
平均点:0.00
Re: データ取得時のパフォーマンス向上について
msg# 1.20
haisei
投稿数: 9
nkmt 様
pu_mahalo 様
初期表示時に検索条件を絞り込んで
表示件数を抑えるという手段ですね。
理解できました。ありがとうございます。
pu_mahalo 様
初期表示時に検索条件を絞り込んで
表示件数を抑えるという手段ですね。
理解できました。ありがとうございます。
投票数:0
平均点:0.00