7

In-Proc セッション ステートに生産上の問題があります。

私たちのアプリケーションは MVC 3 .NET フレームワークに基づいており、Sitecore CMS を実行しているサイトに統合されています。

ユーザーは、アプリケーション フロー全体でランダムに「オブジェクトのインスタンスに設定されていないオブジェクト参照」を経験しています。

広範なログとトレースの結果、セッション オブジェクトが null を返したことが原因であると結論付けることができました。

ここでは、私たちが発見したことと知っていることについて、いくつかの詳細を説明します。

  1. セッション ID は同じユーザーに対して永続的であり、アプリケーションに正しく渡されます。
  2. これはコードの問題ではないと思います。これは本番環境でランダムな間隔でのみ発生し、ローカル、開発、またはステージング環境では決して発生しないためです。
  3. ロード バランサーを介して実行されている 2 つの運用サーバーがあります。
  4. サーバーの 1 つをスリープ状態にし、すべてのトラフィックを 1 つのサーバーにルーティングすることでテストしたため、これはサーバーの永続的な問題ではありません。また、ロギングを通じて、ユーザーが同じサーバーにアクセスしていることを特定できましたが、セッションは null になりました。
  5. 以前にエラーが発生した場合でも、アプリケーションを正常に処理できるため、これはクライアントの問題ではないようです。
  6. これは、トラフィックの負荷やサーバーの負荷の問題ではないようです。これは、1 日を通してランダムな時間に発生し、ランダムなユーザーに発生するためです。
  7. これは、アプリ プールのリサイクルが原因ではないようです。
  8. これは、タイムアウトが 2 時間に設定されているため、セッション タイムアウトが原因ではないようです。ログを追跡している間、ユーザーはフローの開始から 5 ～ 10 分かかる可能性があります。

補足: Sitecore CMS により、In-Proc セッション状態を使用する必要があります。したがって、デザインの変更はオプションではありません。

セッションのロックまたは同時アクセス試行による破損に関係している可能性があるという理論があります。

アプリケーションでこの問題が頻繁に発生するのは、ユーザーが JavaScript (windows.location) によってリダイレクトされている場合です。

また、非同期の ajax 呼び出しが行われている領域でも。

私たちはしばらくこれについて頭を悩ませていましたが、問題が何であるかについての洞察や理論を誰かが持っているのではないかと思っています。

ありがとう

追記:

@Mystere && @H27Studio、セッションIDまたはセッションリセットの問題に関連するものも発見しました。場合によっては、ページのリダイレクトで、メソッドへの 2 つの重複した GETS 呼び出しがトリガーされていることがわかります。最初の呼び出しにはセッション ID がなく、サーバーの 1 つにランダムにリダイレクトされます (これは、ロード バランサーからのサーバー永続セッションがクライアント IP、セッション ID、およびその他のヘッダー情報に基づいて一意のセッションを作成し、クライアントを 1 つのサーバーに保持します)。これは、リダイレクト ページが window.location を使用している場合、フロー中に毎回発生します。

これにより、セッション ID のない不適切な呼び出しが同じサーバーにヒットした場合、クライアントで「オブジェクト参照が設定されていません..」という問題が発生します。(これはおそらく、sessionID のない最初の不適切な呼び出しにより、アプリケーションが元のセッションのオブジェクトをオーバーライドする新しいセッションを作成するためです) したがって、正しい sessionID がアプリケーションに渡される 2 回目の呼び出しでも、セッション オブジェクトに null が含まれていることがわかります。 .

したがって、セッションオブジェクトをクリアする重複呼び出しに問題があると思いますが、その理由や原因はわかりません。

誰でもこれについて手がかりを持っていますか? ありがとう

更新: この問題を解決するために、これらの手順を実行する予定です。

  1. 非同期 Ajax 呼び出しが行われた領域で問題が発生したため、非同期機能を削除し、Ajax を同期して実行できるようにする予定です。
  2. Windows.location JavaScript リダイレクトが発生する問題があります。この領域の問題を解決するために、ポストバックを使用する別の方法を作成しました。
  3. 上記の問題のいずれにも関係しない他の領域は、まだ未解決のままです。

変更の影響は、本番環境へのデプロイ後に掲載されます。

すべてのコメントをありがとう。

4

2 に答える 2

7

何ヶ月にもわたる調査とデバッグの後、ようやく結論に達したと思います。Sitecore Analytics ロボットのセッション タイムアウトにバグがあるようです。最初に、セッションが途中でタイムアウトしたためにランダムにセッションが失われた場合はいつでも、これらのセッションが 120 分ではなく 1 分のタイムアウトに設定されていることに気付きました。

すべての構成ファイルを検索した後、Sitecore Analytic.Robots.SessionTimeout が 1 分に設定された唯一のタイムアウト値であることがわかりました。

この値を増やすことで、セッション タイムアウトの問題が解決しました。

したがって、基本的な問題は、Sitecore Analytics が一部の訪問者セッションをロボット セッションと誤認し、タイムアウトを 1 分に再割り当てすることです。これはおそらく報告すべきバグです。

更新: Sitecore からの応答:

Sitecore CMS は、ASP.NET WebForms テクノロジで使用するように設計されています。Web フォームを使用している場合、ボット検出はページのコントロールに依存します。ASP.NET MVC アプリケーションで使用できないのは当然ですが、簡単な解決策があります。次のコードを要素内に配置します。

<%
if (Context.Diagnostics.Tracing || Context.Diagnostics.Profiling)
{
  Response.Write("<!-- Visitor identification is disabled because debugging is active. -->");
}
else if (Tracker.IsActive && (Tracker.Visitor.VisitorClassification == 925))
{
  Response.Write("<link href=\"/layouts/System/VisitorIdentification.aspx\"    rel=\"stylesheet\" type=\"text/css\" />");
}
%>
于 2012-06-20T19:10:14.887 に答える
0

あなたの問題はあなたがほのめかしている非同期ajax呼び出しかもしれないと思います。私は最近、問題を引き起こしている同じセッションでの同時ajaxリクエストの問題について話しているDavidHaydenの記事を読みました。とにかく見るものです。うまくいけば、それが役立ちます。

http://davidhayden.com/blog/dave/archive/2011/02/09/SessionLessControllersMvc3.aspx

彼は投稿の最後でそれについて話します。

于 2012-01-25T22:14:48.190 に答える