Nagle算法的立意是良好的，避免网络中充塞小封包，提高网络的利用率。但是当Nagle算法遇到delayedACK悲剧就发生了。DelayedACK的本意也是为了提高TCP性能，跟应答数据捎带上ACK，同时避免糊涂窗口综合症，也可以一个ack确认多个段来节省开销。悲剧发生在这种情况，假设一端发送数据并等待另一端应答，协议上分为头部和数据，发送的时候不幸地选择了write-write，然后再read
去年做的分享，一直上传slideshare失败，今天又试了下，成功了。这个主题主要介绍JavaNIO编程的技巧和陷阱，解读了一些NIO框架的源码，以及编写高性能NIO网络框架所需要注意的技巧和缺陷。关注这方面的朋友可以看一下。去年写了篇blog提供了pdf版本的下载，看这里。Niotrickandtrap
HandlerSocket是日本人 akira higuchi 写的一个MySql的插件，通过这个插件，你可以直接跟MySql后端的存储引擎做key-value式的交互，省去了MySql上层的SQL解释、打开关闭表、创建查询计划等CPU消耗型的开销，按照作者给出的数据可以在数据全部在内存的情况下可以达到75W的QPS查询。具体信息可以看这篇Blog，中文介绍可以看这篇文章《HandlerS
前段时间对kilim的当前版本做了一些改进，集中在nio调度器这一块。Kilim新版本引入了nio调度器，可以跟非阻塞IO结合在一起，从这个版本开始，kilim才真正具有实用性。协程只有跟非阻塞IO结合起来才能发挥威力啊。但是Kilim的默认的nio调度器还只是使用一个nioworker做调度，这跟现有的NIO框架采用多个nioworker来提升效率比较起来相对落伍。我改进了NioSelector
背景：在大型分布式java应用中，为了方便开发者，通常底层的rpc框架都会做一些调用的封装，让应用层开发人员在开发服务的时候只用编写简单的pojo对象就可以了，如流行的springremoting，jbossremoting等等，都有这样的效果。随着业务的需要，可能上层应用希望采用非java技术，如php，rubyonrails，而由于javagc和内存模型的限制，可能有的底层服务又需要采用更高性
Netty提供异步的、事件驱动的网络应用程序框架和工具，用以快速开发高性能、高可靠性的网络服务器和客户端程序[官方定义]，整体来看其包含了以下内容：1.提供了丰富的协议编解码支持，2.实现自有的buffer系统，减少复制所带来的消耗，3.整套channel的实现，4.基于事件的过程流转以及完整的网络事件响应与扩展，5.丰富的example。本文并不对Netty实际使用中可能出现的问题做分析，只是从
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
