DataTableをsessionに突っ込んでいた。
Ajaxでリクエストされた処理内でそんな処理がありちょいとハマる。
Azureの場合、sessionへの値の格納は、
実装したコードの処理が全て実行された後に、
Azure上のキャッシュに格納しようとする為、そこでエラると、しかもAjaxだと
検知しにくい。
➡ Grobal.aspx.vbにロギングの処理を実装して未処理エラーを拾うべし。
未処理のエラーが発生し、クライアントサイドが通信を打ち切り
通信を打ち切られたサーバサイドがシステムエラーをはく。
エラーの場所を特定しさあ本題が待ってました。
DataTableをsessionに入れようとしてタイムアウトになっていました。
これまでは発生しなかった現象でしたが、DataTableの容量が増えた際に発生しました。
DataTableのサイズはおよそ9M
10Mbps の回線なら、1秒で転送するはずなので、
容量が問題とは考えにくい。
色々ためした結果、
シリアライズの速度がネックなんじゃないかという推論に落ち着きました。
つまりDataTableをシリアライズするのはやたら時間がかかるという事。
結果的にほぼ同じサイズのデータがXElement または Stringの場合は、すんなりsessionに格納できました。
Azureのキャッシュに値を格納するためにAPIを実行すると、おそらく
シリアライズしながら逐次的にAzure上のサーバに転送をしているのではないかと思う。
XElementの場合は、中身は「XElementオブジェクトとその子要素」と断定的で静的に近い形になっているため、シリアライズの処理内での判定が早いのでは?
また、Stringの場合のシリアライズもほぼそのままの形なのでは?
それに比べ.NETのDataTableには、行に対して動的にオブジェクトを突っ込む事もできる。行のカラム毎に型情報を持っていて汎用的な構造になっているので、
きっとシリアライズにはもの凄く時間がかかるじゃない?
っていう話でした。
ちなみに、.NETではシリアライズの方法がいくつか提供されているようです。
また、Xml形式のデータでは、値をattributeに格納すると高速化するようです。
データ量が増えて発生する問題にはいつも悩まされます。
Ajaxでリクエストされた処理内でそんな処理がありちょいとハマる。
Azureの場合、sessionへの値の格納は、
実装したコードの処理が全て実行された後に、
Azure上のキャッシュに格納しようとする為、そこでエラると、しかもAjaxだと
検知しにくい。
➡ Grobal.aspx.vbにロギングの処理を実装して未処理エラーを拾うべし。
未処理のエラーが発生し、クライアントサイドが通信を打ち切り
通信を打ち切られたサーバサイドがシステムエラーをはく。
エラーの場所を特定しさあ本題が待ってました。
DataTableをsessionに入れようとしてタイムアウトになっていました。
これまでは発生しなかった現象でしたが、DataTableの容量が増えた際に発生しました。
DataTableのサイズはおよそ9M
10Mbps の回線なら、1秒で転送するはずなので、
容量が問題とは考えにくい。
色々ためした結果、
シリアライズの速度がネックなんじゃないかという推論に落ち着きました。
つまりDataTableをシリアライズするのはやたら時間がかかるという事。
結果的にほぼ同じサイズのデータがXElement または Stringの場合は、すんなりsessionに格納できました。
Azureのキャッシュに値を格納するためにAPIを実行すると、おそらく
シリアライズしながら逐次的にAzure上のサーバに転送をしているのではないかと思う。
XElementの場合は、中身は「XElementオブジェクトとその子要素」と断定的で静的に近い形になっているため、シリアライズの処理内での判定が早いのでは?
また、Stringの場合のシリアライズもほぼそのままの形なのでは?
それに比べ.NETのDataTableには、行に対して動的にオブジェクトを突っ込む事もできる。行のカラム毎に型情報を持っていて汎用的な構造になっているので、
きっとシリアライズにはもの凄く時間がかかるじゃない?
っていう話でした。
ちなみに、.NETではシリアライズの方法がいくつか提供されているようです。
また、Xml形式のデータでは、値をattributeに格納すると高速化するようです。
データ量が増えて発生する問題にはいつも悩まされます。
コメント
コメントを投稿