高性能服务器架构第四篇

转自：http://www.doserv.com/article/2012/0831/5299117.shtml

其他方面

我已经阐述完了影响性能的四个主要方面. 然而还有一些比较重要的方面需要说一说，大所属都可归结于你的平台或系统环境：

你的存储子系统在大数据读写和小数据读写，随即读写和顺序读写方面是如何进行?在预读和延迟写入方面做得怎样?

你使用的网络协议效率如何?是否可以通过修改参数改善性能?是否有类似于TCP_CORK, MSG_PUSH,Nagle-toggling算法的手段来避免小消息产生?

你的系统是否支持Scatter-Gather I/O(例如readv/writev)? 使用这些能够改善性能，也能避免使用缓冲链(见第一节数据拷贝的相关叙述)带来的麻烦. (说明：在dma传输数据的过程中，要求源物理地址和目标物理地址必须是连续的. 但在有的计算机体系中，如IA，连续的存储器地址在物理上不一定是连续的，则dma传输要分成多次完成. 如果传输完一块物理连续的数据后发起一次中断，同时主机进行下一块物理连续的传输，则这种方式即为block dma方式. scatter/gather方式则不同，它是用一个链表描述物理不连续的存储器，然后把链表首地址告诉dma master. dma master传输完一块物理连续的数据后，就不用再发中断了，而是根据链表传输下一块物理连续的数据，最后发起一次中断. 很显然 scatter/gather方式比block dma方式效率高)

你的系统的页大小是多少?高速缓存大小是多少?向这些大小边界进行对起是否有用?系统调用和上下文切换花的代价是多少?

你是否知道锁原语的饥饿现象?你的事件机制有没有"惊群"问题?你的唤醒/睡眠机制是否有这样糟糕的行为: 当X唤醒了Y, 环境立刻切换到了Y,但是X还有没完成的工作?

我在这里考虑的了很多方面，相信你也考虑过. 在特定情况下，应用这里提到的某些方面可能没有价值，但能考虑这些因素的影响还是有用的. 如果在系统手册中，你没有找到这些方面的说明，那么就去努力找出答案. 写一个测试程序来找出答案;不管怎样，写这样的测试代码都是很好的技巧锻炼. 如果你写的代码在多个平台上都运行过，那么把这些相关的代码抽象为一个平台相关的库，将来在某个支持这里提到的某些功能的平台上，你就赢得了先机.

对你的代码, "知其所以然", 弄明白其中高级的操作, 以及在不同条件下的花销. 这不同于传统的性能分析, 不是关于具体的实现,而是关乎设计. 低级别的优化永远是蹩脚设计的最后救命稻草. map注：下面这段文字原文没有，这是译者对于翻译的理解.

附录：奥德修斯Odysseus，又译"奥德赛"，神话中伊塔刻岛国王，《伊利亚特》和《奥德赛》两大史诗中的主人公(公元前11世纪到公元前9世纪的希腊史称作"荷马时代". 包括《伊利亚特》和《奥德赛》两部分的《荷马史诗》，是古代世界一部著名的杰作). 奥德修斯曾参加过著名的特洛伊战争，在战争中他以英勇善战、足智多谋而著称，为赢得战争的胜利，他设计制造了著名的"特洛伊木马" (后来在西方成了“为毁灭敌人而送的礼物”的代名词). 特洛伊城毁灭后，他在回国途中又经历了许多风险，荷马的《奥德赛》就是奥德修斯历险的记述. "斯库拉和卡律布狄斯"的故事是其中最惊险、最恐怖的一幕.

相传，斯库拉和卡律布狄斯是古希腊神话中的女妖和魔怪，女妖斯库拉住在意大利和西西里岛之间海峡中的一个洞穴里，她的对面住着另一个妖怪卡律布狄斯. 它们为害所有过往航海的人. 据荷马说，女妖斯库拉长着12只不规则的脚，有6个蛇一样的脖子，每个脖子上各有一颗可怕的头，张着血盆大口，每张嘴有3 排毒牙，随时准备把猎物咬碎. 它们每天在意大利和西西里岛之间海峡中兴风作浪，航海者在两个妖怪之间通过是异常危险的，它们时刻在等待着穿过西西里海峡的船舶. 在海峡中间，卡律布狄斯化成一个大旋涡，波涛汹涌、水花飞溅，每天3次从悬崖上奔涌而出，在退落时将通过此处的船只全部淹没. 当奥德修斯的船接近卡律布狄斯大旋涡时，它像火炉上的一锅沸水，波涛滔天，激起漫天雪白的水花. 当潮退时，海水混浊，涛声如雷，惊天动地. 这时，黑暗泥泞的岩穴一见到底. 正当他们惊恐地注视着这一可怕的景象时，正当舵手小心翼翼地驾驶着船只从左绕过旋涡时，突然海怪斯库拉出现在他们面前，她一口叼住了6个同伴. 奥德修斯亲眼看见自己的同伴在妖怪的牙齿中间扭动着双手和双脚，挣扎了一会儿，他们便被嚼碎，成了血肉模糊的一团. 其余的人侥幸通过了卡律布狄斯大旋涡和海怪斯库拉之间的危险的隘口. 后来又历经种种灾难，最后终于回到了故乡——伊塔刻岛.

这个故事在语言学界和翻译界被广为流传。前苏联著名翻译家巴尔胡达罗夫就曾把"斯库拉和卡律布狄斯"比作翻译中"直译和意译". 他说: "形象地说，译者总是不得不在直译和意译之间迂回应变，犹如在斯库拉和卡律布狄斯之间曲折前行，以求在这海峡两岸之间找到一条狭窄然而却足够深邃的航道，以便达到理想的目的地——最大限度的等值翻译."

德国著名语言学家洪堡特也说过类似的话: "我确信任何翻译无疑地都是企图解决不可能解决的任务. 因为任何一个翻译家都会碰到一个暗礁而遭到失败，他们不是由于十分准确地遵守了原文的形式而破坏了译文语言的特点，就是为了照顾译文语言的特点而损坏了原文. 介于两者之间的做法不仅难于办到，而且简直是不可能办到."

历史上长久以来都认为，翻译只能选择两个极端的一种：或者这种——逐字翻译(直译); 或者那种——自由翻译(意译). 就好像翻译中的斯库拉和卡律布狄斯一样。如今斯库拉和卡律布狄斯已成为表示双重危险——海怪和旋涡的代名词，人们常说介于斯库拉和卡律布狄斯之间, 这就是说：处于两面受敌的险境，比喻危机四伏，用来喻指译者在直译和意译之间反复作出抉择之艰难.

高性能服务器架构第四篇相关推荐

高性能服务器架构(High-Performance Server Architecture)
原文: https://blog.csdn.net/marising/article/details/5186643 High-Performance Server Architecture 高性能服 ...
高性能服务器架构(High-Performance Server Architecture) .
// http://blog.csdn.net/bsplover/article/details/7498718 High-Performance Server Architecture 高性能服务 ...
High performance server architecture(高性能服务器架构)
from: http://pl.atyp.us/content/tech/servers.html http://www.cppblog.com/isware/archive/2011/07/19/1 ...
高性能网站架构之缓存篇—Redis集群搭建
看过高性能网站架构之缓存篇--Redis安装配置和高性能网站架构之缓存篇--Redis使用配置端口转发这两篇文章的,相信你已经对redis有一定的了解,并能够安装上,进行简单的使用了,但是在咱们的 ...
高性能服务器架构思路「不仅是思路」
在服务器端程序开发领域,性能问题一直是备受关注的重点.业界有大量的框架.组件.类库都是以性能为卖点而广为人知.然而,服务器端程序在性能问题上应该有何种基本思路,这个却很少被这些项目的文档提及.本文正式 ...
web 服务器内存影响_高性能服务器架构思路「不仅是思路」
在服务器端程序开发领域,性能问题一直是备受关注的重点.业界有大量的框架.组件.类库都是以性能为卖点而广为人知.然而,服务器端程序在性能问题上应该有何种基本思路,这个却很少被这些项目的文档提及.本文正式 ...
高性能服务器架构思路【不仅是思路】
在服务器端程序开发领域,性能问题一直是备受关注的重点.业界有大量的框架.组件.类库都是以性能为卖点而广为人知.然而,服务器端程序在性能问题上应该有何种基本思路,这个却很少被这些项目的文档提及.本文正式 ...
高性能服务器架构思路
在服务器端程序开发领域,性能问题一直是备受关注的重点.业界有大量的框架.组件.类库都是以性能为卖点而广为人知.然而,服务器端程序在性能问题上应该有何种基本思路,这个却很少被这些项目的文档提及.本文正式 ...
linux socket recv函数如何判断收完一包_linux服务器端编程之高性能服务器架构设计总结...
所谓高性能就是服务器能流畅地处理各个客户端的连接并尽量低延迟地应答客户端的请求:所谓高并发,指的是服务器可以同时支持多的客户端连接,且这些客户端在连接期间内会不断与服务器有数据来往. 这篇文章将从两个 ...

高性能服务器架构第四篇

高性能服务器架构第四篇相关推荐

最新文章

热门文章

高性能服务器架构 第四篇

高性能服务器架构 第四篇相关推荐

最新文章

热门文章

高性能服务器架构第四篇

高性能服务器架构第四篇相关推荐