我刚刚在台式电脑上安装了 Windows 7 x64 Ultimate。我安装了 IIS、Visual Studio 2008、注册了 ASP.NET 等。
我有一个 ASP.NET 3.5 网站,我正在这个新的 IIS 上运行速度非常慢。在 STA 和 PROD 服务器(Windows 2003 Server)以及我的旧 XP/IIS 5.1 上,一切运行顺利。
一个通常需要 1-2 秒加载的页面现在只需要 8 秒!
我在 IIS 论坛上看到了这篇文章。它说明了 Vista/7 不共享连接(只是为了让您知道,该网站在本地运行,但它连接到托管在远程服务器上的 SQL Server 2005)。
似乎需要一段时间才能“开始加载”页面...我的意思是,我单击刷新,它会停留几秒钟“等待本地主机”...然后当它得到响应时,它会正常加载整个页面.. 我不
知道如何强制Win7/IIS7.5 池数据库连接。
编辑:我创建了一个新的空 ASP.NET Web 应用程序来查看问题是否也会发生。答案是否定的,它的响应速度很快,因为它应该有一个空的默认页面。也许与数据库连接有关。我将做进一步的测试。这应该是一种修复它的方法...
编辑2:调试应用程序我注意到延迟发生在执行.NET代码(Page_Load等)之后...所以延迟似乎是位于 IIS 向浏览器提供页面时的某个位置。
I've just installed Windows 7 x64 Ultimate on my desktop PC. I installed IIS, Visual Studio 2008, registered ASP.NET, etc.
I have this ASP.NET 3.5 website I'm working on running EXTREMELY slow on this new IIS. On STA and PROD servers (Windows 2003 Server) and on my old XP/IIS 5.1 everything runs smoothly.
A page which usually takes 1-2 seconds to load is taking 8 seconds!!!
I saw this post on IIS forum. It says something about Vista/7 not pooling connections (just to let you know, the website is running locally but it's connecting to a SQL Server 2005 hosted on a remote server).
It seems that it takes a while to "start loading" the page... I mean, I click refresh and it stays for several seconds "Waiting for localhost"... Then when it gets response it loads the whole page normally...
I don't have a clue how to force Win7/IIS7.5 to pool database connections.
EDIT: I've created a new empty ASP.NET web application to see if the problems happens too. The answer is no, it responds fast as it should with an empty default page. Maybe is something related to the DB connection. I will do a further test. It should be a way to fix it...
EDIT 2: Debugging the app I noticed that the delay occurs AFTER the execution of .NET code (Page_Load, etc)... so the delay seems to be somewhere when IIS serves the page to the browser.
发布评论
评论(4)
对于遇到同样问题的人,这里有两种可能的解决方案。
我发现的大多数作者都建议这种方法是最快、最干净的解决方案。您需要做的基本上是在 Firefox 中打开配置设置 (about:config) 并将 network.dns.disableIPv6 设置更改为 true。
这是我的一个想法,用于检查在哪里以及如何干扰我的计算机上的 IPv6 设置。我看到上述来源的评论之一说,只需将 localhost 替换为 url 中的计算机名称即可解决该问题。
我没花很长时间就检查并发现禁用 IPv6 本地主机查找与直接在 Firefox 中禁用 IPv6 具有相同的作用。
您需要做的基本上是注释/删除主机文件中的这一特定行:
注意:::1 表示法是 IPv6 相当于 IPv4 127.0.0.1 查找地址。
我相信第二种解决方案可能更适合一般不想禁用 IPv6 的用户,第一种解决方案可能更适合所有其他在日常工作中仍不使用 IPv6 的用户。
For those having the same problem, here's two possible solution.
Most of the authors that I found out about suggest this approach as quickest and cleanest solution. What you need to do is basically to open configuration settings in Firefox (about:config) and to change network.dns.disableIPv6 setting to true.
This came to me as an idea to check where and how can I interfere in IPv6 settings on my machine. I saw one of the comments on above mentioned sources saying that one can get rid of the problem by simply replacing localhost with machine name in the url.
It didn’t take me long to check and see that disabling my IPv6 localhost lookup does the same thing as disabling IPv6 directly in Firefox.
What you need to do is basically to comment / delete this particular line in your hosts file:
Note: ::1 notation is IPv6 equivalent of the IPv4 127.0.0.1 lookup address.
I believe the second solution might be more suitable for users who do not want to disable IPv6 in general, and the first one for all others that still do not use IPv6 in their regular work.
我遇到了同样的问题:在 Windows 7 64 位上使用 IIS 7.5 时,站点性能极其缓慢,配备 Core 2 Duo、4GB RAM 和 3 个应用程序池进程,仅运行 1 个网站。以下是我为恢复 IIS 速度所做的操作,问题已解决...
对我来说,诀窍是使用 32 位工作线程运行 IIS,按照 Microsoft 在 IIS.net 上的说明进行操作,您可以在此处阅读:
http://learn.iis.net/page.aspx/201/ 32-bit-mode-worker-processes/
提供了简单的解决方案(我不想在这里重写)...您可以从 Windows 命令提示符运行 1 行命令,也可以运行 1 行命令来自 Windows PowerShell 的命令。我刚刚从命令行运行它(确保以管理员身份打开命令行或 PowerShell——右键单击 > 以管理员身份运行)。
谢谢,
马蒂·麦吉
I was having the same issue: extremely dead slow site performance using IIS 7.5 on Windows 7 64-bit with a Core 2 Duo with 4GB RAM and 3 Application Pool Processes running only 1 website. Here's what I did to get the speed back to IIS, problem solved...
The trick for me was to run IIS using 32-bit workers, as instructed by Microsoft on IIS.net, which you can read here:
http://learn.iis.net/page.aspx/201/32-bit-mode-worker-processes/
Simple solution provided (I don't want to rewrite it here)... Either you can run a 1-line command from the Windows Command Prompt or a 1-line command from Windows PowerShell. I just ran it from the command line (make sure you open Command Line or PowerShell as Administrator -- right-click > Run as Administrator).
Thanks,
Marty McGee
您可以尝试将多个进程作为应用程序池运行:
然后点击高级设置
“最大工作进程”并更新
改为 3(或进程数
你想允许运行)。
You can try running multiple processes as application pools:
and click Advanced Settings
"Maximum Worker Processes" and update
it to 3 (or the number of processes
you want to allow to run).
我知道该操作员正在运行 IIS 7.5,这可能不适用于他,但我发布此内容是因为它可能会帮助其他运行
IIS Express 8.0
的人。我遇到了同样的问题,但 IPv6 或主机文件更改对我来说都不起作用。我的 asp.net MVC4 项目在按 F5 刷新本地主机上的 js 更改后非常慢。所有浏览器都发生这种情况 - Chrome、FF 和 IE。最终我发现 IIS Express 8.0 在提供 js 文件时非常慢,并且似乎是一个错误。如果我在命令行上运行 iisexpress 并按 F5,我可以看到每个 js 文件需要 4 或 5 秒才能加载。我最终卸载了 IIS 8.0 并安装了 IIS Express 7.5,问题立即得到解决。以下是我遵循的步骤:
IIS Express 8.0 似乎是与 VS 2012 一起安装的,因此如果您进行了全新安装或可能进行了服务包更新这可能会升级以前的 IIS Express 版本。
I know the op was running IIS 7.5 and this may not apply to him, but I'm posting this as it might help others running
IIS Express 8.0
. I had the same problem and none of the IPv6 or hosts file changes worked for me. My asp.net MVC4 project was really slow after hitting F5 to refresh js changes on localhost. It was happening across all browsers - Chrome, FF, and IE. Eventually I discovered that IIS Express 8.0 is extremely slow when serving up js files and seems to be a bug. If I ran iisexpress on the command line and hit F5 I could see each js file took 4 or 5 seconds to load.I ended up uninstalling IIS 8.0 and installing IIS express 7.5 and straight away the problem was fixed. Here are the steps I followed:
IIS Express 8.0 seems to be installed with VS 2012 so if you had a new install or possibly a service pack update this might upgrade the previous IIS Express version.