【 在 fancitron (Albatross) 的大作中提到: 】
: 嗯，有cache的话也就无所谓了，不过要是没有cache的话，bbscon.php 里面发送文件
: 是 echo fread(...)，大概需要先把文件读进内存然后再显示出来？@@ 而apache据说
: 有一个效率比较高的sendfile系统调用，对这个调用的细节我不了解，不过据说性能
: 比较好，嘿嘿。

早就知道 sendfile() 了，现在之所以直接用 php 写，就是最开始写的人偷懒而已的。
以前是有过写一个 C 函数放在 phplib 里面的设想，但后来也没动，因为 php 工作
得挺好的，也没见这个东西引起多大的系统负担。

: 对了，我说的性能是指服务器承受的负担，而不是说显示附件的快慢问题。以上都是
: 推测的。显示附件的快慢从客户端来说当然主要取决于网速，难道我连这都不知道...
: 当然，服务器lag的情形除外。
: 此外，附件和正文分离可以在转载或者收录精华的时候节省磁盘空间。
: 当然，我也就是理论探讨一下，嘿嘿~~~

这种情形有过的，不过并不是很好，某站一开始就是这种做法，但后来还是改为
binary 格式文件了，就是被附件没有及时删除烦透了。事实上，如果真的用分离的
办法，就必须有专门的附件清理工具，带来了维护成本。

至于节省空间这个事情，看上去很美，做起来就知道麻烦了。因为这个时候你必须维护
附件的 reference count 了，正文和精华区都指向同一个附件，正文删掉的话，附件还
得留着。当然，在 Unix 里面有一个 link() 可以维护对文件 reference count，但这样
做又有局限性，正文和精华区的文章必须各维护一个附件文件，这个附件文件 hard link
到真正的附件文件。另外一个问题是 hard link 是不能跨文件系统的，这也是局限性。

系统设计是要寻找某种折衷的，可能会有所谓的最优，但不见得这个最优就是最适合的。

: 对了，bbscon.php 貌似对web request里的 ap 参数没有合法性检查，随意给定一个
: 参数会导致页面出错(php)，不过这是否有安全隐患我倒没有研究过。
--
FROM 162.105.242.*