对 Windows 2003 上的 IIS 6 进行故障排除的想法
我编写了一个 .NET 4.0 Web 服务，用于从应用程序数据存储发回数据。基本上，它正在访问远程结构化文本文件。数据请求平均需要 10-14 秒。在过去 3-4 周内，服务器现在需要大约 4 分钟才能访问相同的数据。为了消除网络问题，我将正在访问的文件移至 Windows 2003 上的 IIS 6.0 服务器，但返回数据仍需要大约 4 分钟。
我有一个 .NET 4.0 Web 服务，它调用用于访问数据文件的 COBOL 访问代码。访问代码和文件均未更改。
问题似乎出在 IIS 服务器上。我可以从我的开发人员工作站运行此 Web 服务来访问远程应用程序服务器上的文件，它在 10-14 天内运行。
性能：Web 服务的处理器利用率不会超过 50%。我没有仔细查看磁盘，但服务器大部分时间都处于空闲状态。
我正在寻找有关确定从哪里开始故障排除的建议。
谢谢， 马丁
I wrote a .NET 4.0 web service that sends back data from an applications data storage. Basically, it is accessing remote, structured text files. The request for data would take between 10-14 seconds on average. Within the last 3-4 weeks, the server is now taking about 4 minutes to access that same data. In an attempt to remove the network as an issue, I moved the files I was accessing to the IIS 6.0 server on Windows 2003 and it is still taking about 4 minutes to return data.
I have a .NET 4.0 web service making calls to COBOL access code that accesses the data files. None of the access code nor the files have been changed.
The problem appears to be the IIS server. I can run this web service from my developer work station to access the files at the remote application server, it runs within the 10-14.
Performance: The web service isn't going beyond 50% utilization processor-wise. I haven't looked that closely at the disks, but the server sits idle most of the time.
I'm looking for suggestions on figuring out where to start troubleshooting from.
Thanks,
Martin
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不是 COBOL 专家，只是发布我与一位内部 COBOL 开发人员发现的内容。
我对这个我不熟悉的网站进行了分析，发现它正在移动大量数据。 COBOL 开发人员为了使代码作为原型工作，需要围绕大数据块进行“链接”。一开始，有超过 13 个这样的大数据块在内存中移动。我不记得确切的错误消息，但探查器提到虚拟内存中的大量使用或应用程序正在使用大量分页。
我们重新设计了应用程序，它使用的内存显着减少，并且现在似乎可以在不到 2-3 秒的时间内发送回数据。
马丁
I'm not a COBOL expert, just posting what I found with one of my COBOL developers in-house.
I ran profiling against the web site, which I wasn't familiar with, and found that it was moving around a lot of data. The COBOL developer in an effort to get the code working as a prototype had the "linkage" moving around large chunks of data. At the start there were 13+ of these large chunks of data moving around in memory. I can't remember the exact error message, but the Profiler mentioned either heavy use in the Virtual Memory or that the application was using heavy paging.
We reworked the application and it uses significantly less memory and appears to be sending data back in less than 2-3 seconds now.
Martin