关于在场景中并发执行会出现HTTP500的现象的疑问

咸菜

问题描述:
        脚本调试通过,但是在场景中并发执行时候会出现HTTP500错误,并且均是在40个用户才出现1个事务失败,39个用户是不会出现该错误的;当100个用户时候也大概是几个事务失败

         通过查看服务器端应用程序日志,有以下提示信息

        事件 ID ( 2 )的描述(在资源( FeeSys )中)无法找到。本地计算机可能没有必要的注册信息或消息 DLL 文件来从远程计算机显示消息。您可能可以使用 /AUXSOURCE= 标识来检索词描述；查看帮助和支持以了解详细信息。下列信息是事件的一部分: Url /XXXX/XXXX/vXXXX.aspx Error: System.Web.HttpUnhandledException: 发生类型为 System.Web.HttpUnhandledException 的异常。 ---> System.Web.HttpException: Invalid_Viewstate
        Client IP: 192.168.1.40
        Port: 18831
        User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
        ViewState: dDwtNjU0MzcyMTk1Ozs+TGAIghvm1FB3tWjMeDQJAork4bQ=
        Http-Referer: http://192.168.0.66/XXXX/XXXX/vXXXX.aspx
        Path: /XXXX/XXXX/vXXXX.aspx. ---> System.Web.HttpException: Authentication of viewstate failed.  1) If this is a cluster, edit <machineKey> configuration so all servers use the same validationKey and validation algorithm.  AutoGenerate cannot be used in a cluster.  2) Viewstate can only be posted back to the same page.  3) The viewstate for this page might be corrupted. ---> System.Web.HttpException: 无法验证数据。
   at System.Web.Configuration.MachineKey.GetDecodedData(Byte[] buf, Byte[] modifier, Int32 start, Int32 length, Int32& dataLength)
   at System.Web.UI.LosFormatter.Deserialize(String input)
   --- 内部异常堆栈跟踪的结尾 ---
   at System.Web.UI.LosFormatter.Deserialize(String input)
   at System.Web.UI.Page.LoadPageStateFromPersistenceMedium()
   --- 内部异常堆栈跟踪的结尾 ---
   at System.Web.UI.Page.LoadPageStateFromPersistenceMedium()
   at System.Web.UI.Page.LoadPageViewState()
   at System.Web.UI.Page.ProcessRequestMain()
   --- 内部异常堆栈跟踪的结尾 ---
   at System.Web.UI.Page.HandleError(Exception e)
   at System.Web.UI.Page.ProcessRequestMain()
   at System.Web.UI.Page.ProcessRequest()
   at System.Web.UI.Page.ProcessRequest(HttpContext context)
   at System.Web.CallHandlerExecutionStep.System.Web.HttpApplication+IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously).


   请问大家遇到过此类问题否,VIEWSTAT是已经关联了的啊.是LR自动关联的.
   那到底是应用程序的问题呢?还是IIS的问题呢?应该以什么思路去判断是哪部分的问题?

[ 本帖最后由 咸菜 于 2008-11-24 17:23 编辑 ]

archonwang

这个貌似iis的问题

Well finally through our support with HP and Microsoft, I finally got
these answers in relation with the Identity of an Application Pool on
IIS 6.0:

==================================================
There are two registry keys that are significant:

HKEY_LOCAL_MACHINE\Software\Microsoft\ASP.NET
HKEY_CURRENT_USER\Software\Microsoft\ASP.NET

When machineKey is set to AutoGenerate, the key information is stored
in the
HKEY_CURRENT_USER hive for the account running the process.  When the
process
launches, ASP.NET will use the HKEY_CURRENT_USER registry key if it is
available, but will fall back to the
HKEY_LOCAL_MACHINE key if it is not.  If neither registry key exists,
the process
creates the key in the HKEY_LOCAL_MACHINE hive. Otherwise a new set of
keys is generated.
There is some logic that checks to ensure that the key was created
after the
install time for ASP.NET as well so updates will cause a new key.

Now is the catch:

When the application pool is running under a user account (** my case
**) the above keys are NOT generated and you get the VIEWSTATE error.
Running as an administrative level account or Network Service does NOT
return a viewstate error.

MORE INFORMATION:
====================================
IIS does not load an explicit user profile hive for the worker process.
The Service
Control Manager loads the user profile hive for network service so this
area is
available, but custom accounts do not.  As a result, there is not an
HKCU hive (or
any other innate writable location) in which to persist keys.  There is
work being
done in ASP.NET 2.0 to try and provide a place to persist this type of
data for
other accounts.

The workaround is to use a specific key in the machine.config so the
key will not
be generated on each process start.  You can also disable the IIS
health features
that you do not explicitly need to reduce the probability of running
into the
situation.  As we discussed before, using the key in the machine.config
is common
since it is required in web farm scenarios.
====================================

So now I going to try the machine.config key solution and makes some
tests.

参考下看看
http://www.netnewsgroups.net/gro ... pnet/topic1318.aspx