技术测试：你是oltp应用开发方面的高手吗？
整理文章整理出来的，很早时候caoz写的，翻出来备份
这里是一篇技术测试的文章，希望所有那些自称的和被人吹捧的技术高手来看一看，做做我们的几个测试，看看你属于那种层次的高手？
以下测试是针对oltp开发而言的，对于做算法和桌面程序的，不是我这里要讨论的对象。
好了，第一个考题：你能否做一个统计系统，功能上和易数差不多，能够通过页面嵌入方式记录一个网站的显示次数，来访分析，时段分析，日期分析等等。怎么，这就被难住了，那你算哪门子高手？啊哈，这位说了，这些都easy，手到擒来，很好，很好，看来在实现功能上，你具有了高手的基本能力，不过且慢，如果你认为可以实现这些功能就能自称做个易数统计出来，未免也太小瞧了技术这碗饭的分量，实现这些功能，就中国而言，至少有6位数的程序员可以作到，而设计这么一套系统（仅从功能考虑），也至少有5位数的程序员可以作到，明白吗？你不过是这里面平平常常的一个而已了，要高兴还早呢。
第二个考题：呵呵，其实还是做这些功能，不过加个条件，我只给你一台PC Server（单/双PIII 733+512M Ecc内存+18G SCSI硬盘），你要支撑300万/天的请求调用。琢磨琢磨吧。
简简单单的一个cgi+数据库，那是肯定死翘翘了，怎么办？
第一，你要建立三层体系模型，后台数据库必须通过中间应用层和前台CGI分开。
第二，合理分配使用共享内存空间，并合理通过IPC信号量防止内存区的读写冲突和死锁。
第三，必要时改写web server原代码以获得效率最优化，比如改写apache server的http_log.c程序并重新编译。
如果你对建立这么一套系统的整体架构非常清楚，那么恭喜，你可以在一个比较不错的网络公司做一个CTO了，中国能够清晰搭建这样系统的人，不过4位数而已（当然，能够在这样系统里进行编码工作的，肯定还是有5位数以上的，毕竟左右都是c语言而已）。
知道为什么层出不穷那么多统计系统，虽然功能花哨，但是最后都撑不过易数，基本功不扎实，光靠功能花哨，那是没前途的。
在这个领域做的比较好的，好耶，网易，adsunion，腾讯，太极链等几家而已。
那些所谓广告交换没什么技术瓶颈的人，自己做一套大并访系统出来再说话。
第三个考题，还是这些功能，（我够贫的是吧）我要你一天能记录下3000万次浏览日志，不但要统计，还要完整记录，以供随时查验，当然主机环境提升一下，处理数据的主机用集群，但是核心数据库还是用一台电脑的，这次用sun的小型机，比如RS6000什么的；还有这次再加个条件，数据损失不能超过 0.01%。
这个已经不再象建立一个网站了，到象是大型电信的计费中心。你能胜任吗？
这时候要求对整体操作系统，对C语言，对数据库核心都必须有深入骨髓的理解，甚至于，对于数据的导入导出和一些日志的数据库记录，你已经不能再用sql去写了！要利用数据库产品的核心接口按照其数据存储格式直接进行文件或设备块的读写操作！对于一些负载非常大而性能要求又非常高的系统，甚至你需要建立一套独立的数据库体系和数据结构体系。这不是玩笑，因为我领教过这样的系统。
在中国，能搭建这样平台的高手，最多3位数而已。主要集中在电信计费领域，如亚信这样的企业。
第四个考题，这次每天的请求不是3000万了，而是3万万，我没说胡话，3万万！不过你的工作变了，我不要你再做后面的数据处理，我只让你做一个前端报文转发处理，这次我很苛刻，给你一台PII的PC服务器，256M Ecc内存，而数据损失要求则绝对不能超过0.0001%，你的工作很简单，对来往的请求进行简单识别并转发到合适的应用服务器处理。
你用web server转发？别开玩笑了！这时候，你已经别无选择，用汇编自己写一套报文处理程序，作为看守进程驻入内存并挂在接收报文的端口上，你对效率的理解，应当已经超出了对操作系统的认识，对编程语言的认识，而直接达到对CPU指令集的认识程度上，是的，你必须清楚自己的每一条汇编指令是不是已经达到最小的 CPU指令占用。必须能计算出分解和处理一条报文的流程需要多少CPU指令循环，是不是已经针对CPU的指令集达到了最大优化，当然，你还必须很熟悉 TCP/IP协议对每一种报文的格式定义和规范，不过这和汇编指令的效率优化而言，到不显得有多高深了。
我们经常说CISCO是硬件产品服务商，错了！他们的利润主要就来自于这样的算法！！中国联想、华为等等都想强占这块肥肉的市场，但是在高端领域（其实并不是硬件高端，而是算法高端！），我们还是彻底的空白。
庆幸的是，我知道国内有人在做这样的事情了，当宽带不可避免的成为主流的时候，这种算法的强度和要求，会成为攫取利润的最好途径。
中国在这方面能达到标准的，又有几个人呢？
出了这四个考题，没别的意思，我刚大学毕业的时候，也是自视甚高，因为当时的感觉是，和专业课的计算机作业相比（我是力学专业的，动不动要求编程解一个偏微分方程的收敛解，来分析什么旋流场的速度、温度等的分布），做wewebb开发简直毫无算法可言。再加上当时国内做web数据库的也少，动辄以为自己已经是满高手了，结果幸好跑到给电信做计费的企业混了一年，接触了国内最大的电信集中计费中心的解决方案（一直在运营，还不错），才知道敢情OLTP应用里面学问大的很，自己这点皮毛拿出来吹嘘简直是不知天高地厚。现在看看外面一堆和我当初一样的小毛孩子整天做两个烂程序就自诩高手，只好出来说几句。
其实对于OLTP应用而言，功能的实现一般都非常容易，和那些从事力学、数学、物理等行业的数值计算相比简直毫无算法可言，而OLTP的技术难点主要在于性能，也就是你做一个桌面程序或算法程序，都不会面临并访过高的处理问题，但是做一个OLTP应用，无论如何你都必须直视一下子很多访问冲上来的情况，如果这个问题解决不了，无论多好的创意，多好的功能，都不会得到持续和长远的发展。
由于很多创业者和投资者对技术不通或半通，他们往往拿一个性能指标有很大缺陷的东东当个宝贝，因为一般而言，开发出新东东大家都只是忙着测试功能，很少有对性能进行完整测评的，只有持续运营到一定阶段，并访达到一定程度，性能缺陷开始暴露，才临急抱佛脚，这时候造成的损失就很不核算，甚至是压根解决不了，只好放弃某种功能，从而使品牌信誉整体下降。
加强算法基础，加强技术基础，少卖弄一些花里胡哨的东西，是走向技术高手的真正路线，那些今天学会了什么语言，明天又学会了什么语言的主儿，别吹嘘了，从70年代到现在，最值钱的程序员一直是写汇编和写标准C的，不为什么，因为这是真功夫。
—————————————————–
搜出来这个帖子，呵呵，稍微回复一下。
caoz早期也做过asp，中国最早的asp中文教程，是caoz翻译的，那是1998年的事情。但是后来（99年）换了php，不是因为asp不好，而是因为安全性，安全性的问题，根源在microsoft，这个和程序员没关系，但是程序员规避风险的话，还是linux下塌实一些，顺便说一下，caoz 在安全公司混过一年半的程序员。
asp和php相比，在某些应用的效率上，甚至更胜一筹，这个原因也不是语言的问题，而是本身系统的进程模式，Asp是线程模式，线程间的数据通信是非常简单的，写过asp的都知道，可以用application变量做，非常简单。而php在apache下只能是进程模式就麻烦很多，虽然也有共享内存支持，但是调用时候需要做信号量锁定，很麻烦，否则就有内存索引崩溃的危险。就进程间通信而言，asp不是略胜一筹的问题，而是拥有无可比拟的优势。
所以一个统计系统效率还还是不好，语言并不是决定因素，但是阿江有一点说的过了，一台服务器千万次的静态调用就达到极限？
caoz告诉你，在apache 下，caoz所能达到的数字是4000万次，而且是普通的服务器。
阿飞做过极限测试，单服务器最高的一天，统计量达到了3670万次（真实网络流量，不是测试机的模拟流量），单p4的机器，配置很一般的那种。当然这种极限测试不代表真正的应用环境，毕竟单用户和多用户对统计系统负载开销是不同的，但是单服务器在应用环境下每日支撑千万次以上的统计，却并非难事。关键不是看语言，而是看设计。cnzz可以做到，50bang也可以做到。
技术无止境，对比千兆的网络数据包分析工具（如千兆路由器，千兆IDS，千兆黑洞等），那种每秒解析上百万数据包变态应用，的现在的站点统计系统，日千万次处理简直是小儿科的东西。
不过说实话，国内统计系统技术依然有很大的提升空间，阿江的，caoz的，不外如此，处理效率上去只是一方面，分析能力提高也是很考验技术实力的。就这一点，caoz坦承，Google Analytics的数据挖掘能力，无可比拟，完全超越了caoz的技术理解力。当然，这是另一个话题了。
—————————————————
阿江的回帖
看了那个顶上了的贴，接受里面的一些批评，
我自己的观点也在实践中变化，我仔细的看过CNZZ的统计报告并对其统计方式进行了推断。
我的结论是，影响效率差异的主要因素并不在操作系统和WEB服务软件上，
而是在数据结构和程序结构上。
对于一次访问，51LA立即更新统计报告，保存统计报告，
而CNZZ则很傲能是追加访问记录，而在显示统计报告时检索汇总，或者每天还会把前一天的数据汇总后保存。
所以差异出现在这里：向数据库里追加行少数次 VS 更新数据库中指定的行多次
后者的效率明显要低的多。
虽然51LA在统计程序效率上有差距，
但是这种设计思路可以实现统计报告的完整、快速显示、翻页、排序、筛选，
这对很多站长是非常有用的，也是很多人喜欢51LA的原因。
这也正是我迟迟不肯使用承受力更强的新思路重写统计的原因。
另外，MSSQL数据库是一个库一个文件，而MYSQL是一个表一个文件，
这使MSSQL在磁盘操作上稍逊一筹，因为要处理的是大文件。
加上直接更新统计报告的统计方式增加了数据库操作次数，效率大打折扣。