摘要：
在上家公司曾写过这样一个服务，用户通过我的应用（以下简称fri_svr）索取自己的好友信息，而fri_svr需要向第三方平台（如：人人，Facebook）通过http协议批量请求用户数据，由于用户数据可能很大（几k几十k的级别），所以整个req/rep的过程通常会很慢，平均大概会在 1s – 10s 之间，这样当瞬时请求量到一定级别后，就会造成fri_svr的内存暴涨且响应不了前端的请求，原因在于fri_svr会对前端的每个请求hash到（根据user_id）专门用于http请求的线程队列中（也即是one thread per queue模型），当前端向fri_svr的请求速率大于平台响应fri_svr的，那么就会造成fri_svr中队列的积攒，内存的暴涨，且无法在超时时间内响应前端请求。 阅读全文
摘要：
几个月一直懒得没动笔写写博客，最近开始动笔写点什么，今天就趁着加班出版本，横下心决定把上次烂尾的文章给收了（上篇：http://www.cppthinker.com/linux/224/context_switch_1/）。
接上篇，我们已经通过分析内核代码看到pthread_cond_signal和pthread_cond_wait会发生CS（Context Switch），本篇我将从实际测试数据出发，来看CS究竟会对我们的应用程序产生怎样的影响。
一般我们可以通过工具vmstat, dstat, pidstat来观察CS的切换情况。
vmstat, dstat只能观察整个系统的切换情况，而pidstat可以更精确地观察某个进程的上下文切换情况。 阅读全文
摘要：
对于服务器的优化，很多人都有自己的经验和见解，但就我观察，有两点常常会被人忽视 – 上下文切换 和 Cache Line同步 问题，人们往往都会习惯性地把视线集中在尽力减少内存拷贝，减少IO次数这样的问题上，不可否认它们一样重要，但一个高性能服务器需要更细致地去考察这些问题，这个问题我将分成两篇文章来写：
1）从一些我们常用的用户空间函数，到linux内核代码的跟踪，来看一个上下文切换是如何产生的
2）从实际数据来看它对我们程序的影响 阅读全文
摘要：
每个网络库都会有自己的连接管理策略，而我在设计chaos的初期，就制定了几条规则，这里我就针对每一点进行分析，及当初的考虑。 阅读全文
摘要：
基本原理 -
在chaos开篇介绍（http://www.cppthinker.com/chaos/57/chaos_1）中已经提到，task service作为chaos库的核心，主要承担着三个重则：
1. 网络I/O
2. 超时事件
3. 异步消息处理
简单来讲，可以认为一个task service中包含一个epollfd，一个定时事件管理器，一个等待被处理的异步消息队列 阅读全文
摘要：
对于buffer的设计，chaos和其他网络库的做法稍有不同，就拿libevent-stable-1.4.13（以下所提到libevent处皆为该版本）来说，它采用一种能够自动扩张的buffer，基本策略如下：
1. 当缓冲区不够存放新数据时，它会先在内部做marshal，看看是否能够腾挪出足够的空间
2. 假如没有满足，那么对buffer进行expand, 大小为原来的两倍，扩张之后该buffer就不会缩小 阅读全文
摘要：
Chaos是一个基于Linux平台, reactor模式的网络事件库, 目前仅支持TCP传输协议, 仅在x86_64下编译, 并遵循3-clause BSD开源协议. 在使用上, 可以说它很像boost asio, 可能是由于我对boost asio的接口设计很有爱吧, 而且对于boost asio在异步编程方面的思想, 我个人也比较认同, 但至今我也没有仔细阅读过boost asio的源码, 一是boost的模板化编程在可读性上让我比较折磨, 其二则是不想在对设计先入为主的情况下去开发chaos, 很多事情只有我们自己亲自去思考, 才能有所收获. 阅读全文
