12,162
社区成员
发帖
与我相关
我的任务
分享求助，webservice调用超时问题
两个webservice接口（A和B）在一个IP地址下面（公网，具体是不是一台服务器不清楚。），
一台服务器windows 2008 系统(C服务器)，放了个一个推送数据库数据的程序去访问这两个webservice，传递数据，因为对速度有要求，开了30个线程并发，平时都算正常，推送数据程序偶尔会报：请求通道在 00:01:00 以后尝试发送超时。增加传递给请求调用的超时值，或者增加绑定上的 SendTimeout 值。分配给此操作的时间可能是更长超时的一部分。,这种情况平时不常见。
下午因为C服务器的FTP没有破解彻底就重新运行了一下破解补丁，然后重启了一下系统，等系统再启动起来发现两个webservice中的B接口频繁出现上面超时的现象，但A接口正常，B接口只能偶尔能够取到响应信息，这种现象持续了2个多小时，提供webservice的一方说没有做任何调整，后来2个多小时后又正常了，现在不知道从哪入手找问题，在这向各位请教一下，烦请给个详细的解答，
1、这个超时的访问在B接口的IIS日志或系统日志中能否找到对应的日志？
2、大致有多少原因会造成推送数据程序在访问webservice产生上面的错误？（排除webservice地址写错的原因，因为中间还有访问成功的，也排除网络问题，因为同一个IP下的另一个webservice是正常访问的）
3、这种问题是需要在客户端（访问接口的程序）还是webservice上入手解决？（推送数据程序有设置 ServicePoint 对象所允许的最大并发连接数，最多设置过1024。）
拜托了，实在不知道怎么回事了。
一台服务器windows 2008 系统(C服务器)，放了个一个推送数据库数据的程序去访问这两个webservice，传递数据，因为对速度有要求，开了30个线程并发，平时都算正常，推送数据程序偶尔会报：请求通道在 00:01:00 以后尝试发送超时。增加传递给请求调用的超时值，或者增加绑定上的 SendTimeout 值。分配给此操作的时间可能是更长超时的一部分。,这种情况平时不常见。
下午因为C服务器的FTP没有破解彻底就重新运行了一下破解补丁，然后重启了一下系统，等系统再启动起来发现两个webservice中的B接口频繁出现上面超时的现象，但A接口正常，B接口只能偶尔能够取到响应信息，这种现象持续了2个多小时，提供webservice的一方说没有做任何调整，后来2个多小时后又正常了，现在不知道从哪入手找问题，在这向各位请教一下，烦请给个详细的解答，
1、这个超时的访问在B接口的IIS日志或系统日志中能否找到对应的日志？
2、大致有多少原因会造成推送数据程序在访问webservice产生上面的错误？（排除webservice地址写错的原因，因为中间还有访问成功的，也排除网络问题，因为同一个IP下的另一个webservice是正常访问的）
3、这种问题是需要在客户端（访问接口的程序）还是webservice上入手解决？（推送数据程序有设置 ServicePoint 对象所允许的最大并发连接数，最多设置过1024。）
拜托了，实在不知道怎么回事了。
...全文
请发表友善的回复…
发表回复
风一样的大叔 2013-02-01
- 打赏
- 举报
现在是不是好了？人家没说调整就真的没调整吗？
killdebug 2013-01-24
- 打赏
- 举报
ServicePoint是500的时候也是这样，因为速度要有严格要求只能多并发来处理，同时也要求webservice效率达到最优
dopsop110 2013-01-24
- 打赏
- 举报
我怀疑是量太多服务器处理不过来了，试着控制一下ServicePoint对象所允许的最大并发连接数
killdebug 2013-01-24
- 打赏
- 举报
单次推送的数据不大，很小的数据，但是量多点
dopsop110 2013-01-24
- 打赏
- 举报
是因为传输的数据太大吗？
killdebug 2013-01-24
- 打赏
- 举报
另一个速度还不错
killdebug 2013-01-24
- 打赏
- 举报
网络应该没问题，两个webservice是同一IP，只是其中一个出现这个问题
EnForGrass 2013-01-24
- 打赏
- 举报
网络环境影响了吗
