我的要求是在我的Asp.Net Web应用程序中在2秒内加载100个缩略图。每张图像的实际大小约为800 KB。因此，我使用Web处理程序方法动态调整图像大小（此处图像大小减小到8KB）。在这里，我发现96个请求被发送到服务器，缩略图在4秒内加载。我发现，在Firebug网络标签中检查的 阻止 中，90％的时间都在流失。所以我从96请求转移到单个请求。因此，Web处理程序接受单个请求并创建96个缩略图图像并将96个缩略图组合成一个大的单个图像，并将此单个图像写入输出流。这种情况我发现加载单个图像大约需要6秒。然后我使用.Net线程池机制在Web处理程序中创建缩略图。因此加载时间减少到2.6秒。我发现服务器处理实际上只花了1秒或更短的时间。剩余的1.6秒正在丢失。我的问题在下面
失去处理时间的地方。服务器端还是客户端？如果是在服务器端哪里是瓶颈？如何识别请求处理和页面加载时间？
Web处理程序是更好的方法吗？
我的系统配置
处理器 - 英特尔酷睿 - i7， RAM： - 4 GB
Web服务器： IIS 7
操作系统： Windows 7
请帮帮我
答案 0 :(得分：0)
＆GT;哪里丢失了我的处理时间。服务器端还是客户端？
也许它介于...... 1.6秒听起来正确传输数据：
8KB per image * 100 images ~= 1MB of data
1 M bytes = 8 M bits
8 M bits / 1.6 secs = 5 Mbps transfer rate
... sounds reasonable to within an order of magnitude
您的单一图像方法可能更好，因为这将减少100个单独请求的开销。但要注意在ASP.NET进程中使用后台线程。
转移时间是一个限制因素。即使您可以立即让服务器响应，您仍然需要等待数据返回客户端。
另一个限制因素是客户端浏览器可以渲染图像的速度。
基本上，您的要求正在推动实际ATM的界限。