如果超时,程序就会瘫痪,如何报错或者避免?

lioujian47 2008-07-05 05:11:09

好几天没来了.
有个问题,如下:



url = r'http://zqb.cyol.com'

html = urllib.urlopen(url).read()

如果zqb.cyol.com无法访问,就会导致整个程序报错.有没有什么办法可以在遇到问题的时候,采用备用办法,或打印出"error,timeout!"

...全文

90 4 打赏收藏转发到动态举报

写回复

用AI写文章

4 条回复

切换为时间正序

请发表友善的回复…

发表回复

lioujian47 2008-07-07

打赏
举报

恩,不错,谢谢您的回覆

iambic 2008-07-05

打赏
举报

那就比较麻烦了。
google：python 异步 socket

或者简单设下超时选项：

import socket

socket.setdefaulttimeout(3)

lioujian47 2008-07-05

打赏
举报

谢谢,可是可以,不过



try:

    url = r'http://zqb.cyol.com'

    html = urllib.urlopen(url).read()

这一步耗时太长了.能有办法快些的吗?
我想个办法,比如我这个情况,如果第一个地址打不开就打开另一个地址.
即同时打开两个不同的url,取第一个相应的.这个办法如何?
可行的话,能否给个代码?
谢谢先?

iambic 2008-07-05

打赏
举报

try:

    url = r'http://zqb.cyol.com'

    html = urllib.urlopen(url).read()

except Exception, e:

    print e

结构层次及相互联系 (1)、工作线程：响应连接的IO投递返回并负责投递读请求，并将IO返回结果投递给处理线程，可设定参数决定工作线程数量； (2)、处理线程：处理线程调用回调函数将信息传递给应用层或协议栈，可设定参数决定工作处理数量； (3)、看守线程：响应Accept事件调用AcceptEx，检测连接和心跳超时，将信息投递给工作线程，模块仅有一个看守线程。 1. 技术要求 (1)、线程同步：Lock指令、临界段； (2)、主要Socket API：WSASend、WSARecv、AcceptEx、DisconnectEx； (3)、内存管理：连接池（句柄重用）、内存池； (4)、数据0拷贝：通过内置处理线程，上层应用可以避免自建线程池及复制数据的过程。同时提供GBuf内存分配功能，应用层获得分配地址及填充数据之后亦可直接投递给内核/驱动层； (5)、数据顺序同步：同一个连接同时只有一个处理线程响应其IO事件； (6)、IO请求投递：单投递读、多投递写； (7)、0缓冲读投递：可条件编译实现，以适用大规模连接要求。 (8)、超时机制：可设置空连接（连接不发送数据）超时时间以防止DOS攻击，也可设置心跳超时时间防止网络故障导致的现有连接成为虚连接避免耗尽系统资源。 (9)、接口技术：API、回调函数、客户句柄（客户连接句柄）。 (10)、主、被动发送：不使用HASH、MAP及LIST技术，即可提供安全可靠高效的客户连接句柄，以实现服务器端主被动发送数据功能； (11)、PerHandleData的回收不以IO投递的计数器或链表来做依据但仍能安全回收，同时尽量避免在高频的读写操作时做其他无关的操作以提高读写效率。 (12)、处理线程和工作线程有着良好分工界限，繁重的工作交给处理线程完成，工作线程工作量最大限度的减少，仅响应投递返回及读投递的操作；（13）、支持AWE，模块自动识别AWE是否开启（需手动开启），“否”则使用虚拟内存机制。 2. 功能要求 (1)、多IP多端口监听，每个监听可设置不同的回调函数，以高效的区别处理数据 (2)、可设置每秒最大的连接并发量和空连接（连接不发数据）超时时间以防止DOS攻击造成的服务瘫痪、具有心跳处理（防网络异常造成的虚连接）功能 (3)、不加协议的透明传输，可适用广泛的网络通讯环境 (4)、可现实主、被动发送数据，但不会因兼顾主动发送而额外增加降低效率的工作 (5)、内置处理线程，上层应用可不必自建线程池处理数据，所有IO事件按顺序调用回调函数并可以在回调函数内直接处理数据，不必担心多线程造成的接收数据乱序的问题。 (6)、高效率的数据对应关联机制，在初次连接并根据登录数据设置每个连接对应的宿主（Owner）之后，再接收的数据即可立即获得该连接对应的宿主，而不必再做额外的查询工作，并且模块内部采用的是指针关联方式，对于长连接、主动发送的服务器系统而言是高效率的。 (7)、可兼容IPv6 3. 注意事项因硬件环境和应用环境不同，不合理的配置会出现效率及性能上的问题，因此以下情况出现时，请务必与作者联系以确保获得更好的参数配置： (1)、连接量超过1000个的。超过的应结合具体硬件配置和网络带宽等因素综合设定运行参数。 (2)、带宽使用率超过20%的。工作线程和处理线程数量的设置也是综合考虑数据吞吐量和数据处理负载的因素来设置的，过多的线程会在调度上浪费时间，同时也应该综合考虑线程优先级别来设置工作线程和处理线程数量，两者的设置也不一定能相等。 (3)、服务器端有主动发送需求的、短连接（含网络故障造成的连接断开）出现频率高的。压力测试工具介绍：一、使用G-TcpClient模块二、可以设定间隔时间发起大规模长、短连接三、可以发起密集数据包，包括即时和定时发送，1M的光纤带宽最大可以达到100K/S（单向）以上,100M本地网最大可以达到10M/S（单向）以上四、数据发送仅由一个独立线程但当，每点击一次Connect就创建一个线程根据当前参数发起连接。五、测试前提：服务器接收客户端数据后立即原样返回给客户端

《RPC超时问题分析与优化实践》摘要本文针对微服务架构中常见的RPC超时问题展开分析。从原理层面阐述了超时重试机制的双面性：既能提升系统容错能力，又可能导致重复请求、性能下降甚至雪崩效应。作者提出了合理的超时设置策略：基于依赖服务的TP99响应时间加50%作为基准，区分可重试服务并确保幂等性，控制重试次数（通常2-3次）。在解决方案部分，分享了数据库优化、第三方服务调优、中间件配置及代码改造等实战经验，特别展示了通过CompletableFuture实现异步编排的代码优化案例，将串行查询改造为并行执行，有

面对超时,我们要降低发生的概率，同时做好强有力的防护，不相信任何三方组件和接口，绝对保证自己及上游系统的稳定性！

为用户标识出滞后的查询是非常重要的，因为它让你对查询时间了如指掌，让你免受数据库性能陷入瘫痪的风险。为此，Navicat Monitor 3 监控工具的查询分析器画面顶部就设计出了这个费时查询图表。另一种方法是限制查询在超时之前可以执行多久。正如在本文中提到，可以在 PostgreSQL 的数据库、会话甚至单个角色级别设置查询超时。如果你还没有设置 statement_timeout 变量，我们建议你尽快设置。这只是优化数据库性能的其中一步，但它有助于确保你的数据库实例保持良好状况和可用。

原因：阻塞的线程导致系统卡死的原因并不是因为线程数量过多，而是因为阻塞的线程占用了系统资源，导致其他线程无法正常运行。如果系统中有很多阻塞的线程，这些线程会一直占用CPU资源，导致其他线程无法正常运行。为了避免这种情况，可以考虑使用线程池、异步调用等技术来管理线程，避免阻塞线程导致系统卡死的情况发生。3、异步调用：可以使用异步调用，将请求放到队列，由专门的线程处理队列中的请求，避免执行线程阻塞。在调用某个接口时，如果这个接口超时了，线程会阻塞等待结果，这个阻塞的线程会导致系统卡死。

脚本语言

37,743

社区成员

34,212

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

试试用AI创作助手写篇文章吧

+ 用AI写文章