KeyFC欢迎致辞,点击播放
资源、介绍、历史、Q群等新人必读
KeyFC 社区总索引
如果你找到这个笔记本,请把它邮寄给我们的回忆
KeyFC 漂流瓶传递活动 Since 2011
 

[建议]有关Lunariss

[ 6305 查看 / 24 回复 ]

回复:[建议]有关Lunariss

以下引用在2005-9-30 23:39:13的发言:
IE的缓存只能保证每个人只调用一次  如果十个人看帖就要运算十次...
可以考虑在库里放张表,调用函数的时候先select,找不到再合成,并且存表...


这样的缓存是要以牺牲空间为代价的..假设速度一旦很快了,那么就会有更多的人用这个发贴吧。而因为一个帖子的活跃期至少是一天,也就是说缓存要保留一天才有明显效果吧?那么到时候就有很多图片需要缓存..那个容量..
俺は俺であり、そして俺はここにいることを証明し続けるため——
TOP

回复:[建议]有关Lunariss

就目前情况的话总觉得缓存下会比较好
比如这一帖,把IE缓存处理掉肯定要开半天,但其实也就几张图而已,按KFC的帖量,缓存上几天也不成问题,就算一天一千张的图放缓存也占不了多少空间吧,特别有很多人把这个用在签名的,每回一帖不知道要多运算几次...还有可以考虑下判断外连,虽然不知道有没这个问题...
TOP

回复:[建议]有关Lunariss

其实..以上所有建议的措施都并不减少数据传输量的。

其实我写的图片合成代码都是很精简的了,估计也不会消耗CPU运算的大户。

可是一旦加入了什么盗链判断啊缓存机制啊,说不定这些步骤都比单纯的合成一张图耗费更多的CPU资源。

所以我感觉是服务器的带宽问题..和系统本身的设计没什么关系的。

PS:管理员大叔才增加了对话预览功能..就是说图片还没显示出来时,移动鼠标上去可以预览对话内容,暂时能解决一些问题吧。
俺は俺であり、そして俺はここにいることを証明し続けるため——
TOP

回复:[建议]有关Lunariss

数据传输量是没办法的...除非连别人的空间能彻底解决
运算量是能改善的 加入缓存机制理论上除了第一个人比现有系统多执行了一个数据库查询 和if判断数据集EOF外(似乎能忽略哪...)后面的人都只是简单的从库取值而已,直接用现有的参数作主码,数据库操作也很简单,因为查询到的只有一组记录,最多加个时间字段,放一个记时器控件每天清理过期的数据。
这个要改起来似乎不是很麻烦的,因为和原有的系统没什么关联,只要在主函数加一点代码就可以,不用在多处修改...
TOP

回复:[建议]有关Lunariss

像喜剧一样。
TOP