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に格納すると高速化するようで