java rmi 超时_java RMI服务超时

Netty的worker线程只负责nio,在收到完整数据后将数据按要求封装并放入到业务数据队列;业务处理类负责从该队列中取出数据并处理。

这里的业务处理类现在是如何实现的?按你的说法,单线程和多线程 在这个类中都试验过,并且都没能解决问题,由此来看 可以得出2个结论:(1)需要再努力优化业务处理过程以节省处理时间;(2)提升服务器硬件性能。######回复 @阿森lin1991 : 我也是碰到这个问题,单位时间内大量客户端同时连接上来,服务端线程来不及处理。就大量堆积在队列里,请问有办法解决吗?######回复 @阿森lin1991 : 你netty什么版本?netty3和4的线程模型有不小区别,推荐infoq上李林峰写的《netty升级血泪史》######如果netty没有相应api接口的话,那就无解了。看看新版本中是否有,或者可以参考下######回复 @阿森lin1991 : 回复 @阿森lin1991 : 关键是netty接收消息队列消息时造成的阻塞;netty3.0中有ExecutionHandler可以使用(其实也是一个线程池,work执行到ExecutionHandler时直接返回执行下一个channel);我现在也遇到这样的问题,希望可以找到一起其他的解决办法,比如非阻塞接收消息队列消息。######2:接第1条...所以想把消息输出也放在nioEventLoopGroup(worker)线程中执行,即业务处理完后把输出消息压入输出队列,但是怎样才能调用nioEventLoopGroup(worker)线程去处理这个输出队列了?好像没有相关接口###### 1  netty本身的 worker线程的个数是根据CPU来的,直接在 worker线程里做业务逻辑处理不好么? 2 如果不想并发,修改源码,让worker线程个数为1,就没有并发了,这一点跟redis一样的,redis单线程的处理能力貌似也够用了,redis的作者是这么说的。 3 为啥要自定义多个业务逻辑线程?netty本身的worker线程拿到消息后就可以处理了啊 ######回复 @阿森lin1991 : 没必要为每个消息加业务逻辑处理线程,并发量多,线程自然多,这样跟IO模型就没区别了。收到数据后消息处理直接用worker线程,当你预估的业务逻辑实在是太费资源才开一个线程,这个线程中尽量不要有类变量已减少并发错误或人为加锁。实在不能满足需求,可以考虑用RMI把复杂逻辑放到另外的机器上做分布式处理######1.worker线程更多的负责读写网络数据,对于复杂或耗时的业务处理都交由自定义的逻辑线程处理,不然很可能阻塞nio线程,大大减少并发量。 2.我现在的情况不是worker线程并发有问题,而是自定义了逻辑线程并发有问题(阻塞情况比较严重) 3.同1 不过谢谢你...###### 你现在的问题跟Netty没有关系,主要是你的业务处理速度跟不上你所要求的请求速度,单线程也好,多线程也好,都没有关系。 处理不过来, 1,要不把超时的改掉或做优化处理 2,增强处理速度:找到瓶颈优化或者做请求分发到不同服务器处理 ######同意这种说法,最好是将业务线程能够优化######(2)提升服务器硬件以提高业务处理性能。######楼主你好,请问这个问题解决了吗?我先在也是遇到了这问题。######单机环境调优讲一种方法吧。 1. 明确你的优化目标(优化是永无止境的,但必须适可而止) 2. 分析你的硬件瓶颈(归根到底,还是你的硬件在执行软件代码), 比如你的核,内存,带宽(本例中注意下你的带宽拥挤是否延迟你的消息返回) 3. 根据你的目标调整Netty的BoosEventLoop, WorkEvnetLoop,Buffer大小。 4. 优化你的消息包,尽量在一个MTU大小,优化你的编解码工具类,比如使用Protobuffer(传输小,解码快)代替Json.  另外,特别注意Bytebuf转Message后,是否有被ReferenceCountUtil.release() 5. 消息的返回注意 chanel的write跟writeAndFlush的区别。一个是等缓冲区满了才返回,一个是立刻返回。 上面做完了,就跟netty没啥关系了。 针对你的 编解码Loop线程组 与 工作线程组 的优化 Netty WorkEvnetGroup = M,   BusinessWorkerGroup = N  ( M, N >1) 这种情况就是一个生产消费模型,M, N之间有一个ArrayBlockingQueue(必需限制上限)做消息缓存。 1. 为了减少锁竞争,可以使用 无锁队列 Disruptor代替 java的 ArrayBlockingQueue, 据说效率是后者的10倍 2.工作任务代码优化,可以全内存操作以及算法优化。######业务服务是否可以分析出单独微服务啊

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值