不好意思，我本来不想回这句的，但是 es5219 自己有讲：「希望大家不论是在 功能或是造型上都可以尽量给我们意见」，你可以回去翻他的文章。 我实在是很不想跟你计较这个，枉费我还觉得你上一篇写的不错。你不用到处找 人抬杠，如果要消磨时间， Programming 板的 tester 先生是个很好的对象 (没错， 你已经找对人了，去吧)。 RIA 当然有用，要不然也不会订出这个新名词，目前 Macromedia 做的最好 (对 ，就是他的 Flash 产品，呵) 你既然会提出 RIA 这个名词，那你应该不会不知道这 件事情吧？ 我想跟 es5219 强调的是 Flash 没那麽烂，那位 es5219 的外国顾问根本讲错 了，Flash 也是可以做到很大。他引用顾问的话：「用不用 ajax 只是早晚的事情 flash是绝对做不起来这个相簿的」，这种说法让我产生很大的怀疑也不以为然。所 以才回了一个连结 http://fotologue.jp/ 告诉他这就是一个日本的多人相簿大站， 而且刚好就是用外国顾问所不屑的 Flash 做的。 好，我已经解释完了，能不能了解我的意思是个人的造化。 接着我说效能卡在 Server 上，这是事实。做相簿这种东西， Server 端本来就 很重要，效能也的确就卡在那边。就算做了 Cache 机制，就算针对你跑的 CGI 语言 装了强力的 Accelerator 。最终的大问题还是卡在 Server 上。尤其是 Disk I/O， 信不信随便你，前人的经验就是这样。 如果你只是一个几个人玩的小相簿，那当然感觉不出来 Server 效能的重要性， 只要机器不要太烂，你根本感觉不出来太大的差异。如果跑的慢，加上 RAM 换 CPU 就好了啊！但问题是他们公司既然要放出来给大家用，那 Server 的机制当然就重 要了啊！ 我不知道你那句「AJAX程式乱写也没关系? 效能在server嘛」是在什麽样的逻 辑下演绎出来的。如果你真的要这样想也没关系，反正对我不会有害处，最多只是 这个就业市场上少一个脑袋转不过来的竞争对手而已。 另外，如果 Server 那边的机制不重要，那何必现在一堆针对多人设计的相簿 都有 Cache 机制呢？简单的讲，伺服器产生的缩图要不要存起来？是不是每次读 相簿的时候都要直译一次？伺服器什麽时候要产生缩图，是一上传马上就产生吗？ 还是等到人少的时候再产生？这些都关系到效能的问题，而且事关重大。简单的说 ，要是多人使用的相簿每次都还要重新产生缩图，那整个相簿根本跑不动。 Server 端的机制超级重要的，这麽简单的观念还需要实验？(叹气) 如果你硬要跟我抬杠，我真的不知道你怎麽会那闲。 Client 只要不要乱写，不论是 Ajax 或是 Flash 都会很好。 Interface 写 得差就容易造成 Client 乱 request ，或是增加传输的 overhead ，但是重点根 本不是在这边，传图档一张就几百 KB 去了，一般的情况等待的时间会卡在传图档 上，不会卡在 request & response 上面。只要 request 不要多到太扯，基本上都 是可以接受的。 当然，在 Server 那边已经做得很好之後，有些人就会开始考虑 Client 的机 制，最简单下手的地方就是把所有的 CSS 和 JS 分别整合到一个档，这样就只要发 一个 request 然後等着收就好，可以节省个别等待 response 的时间，而且也可以 减少传输「多余」header 所「浪费」的「bytes」 ，还有搭配 Ajax 或是 Flash 来改变以往 HTTP 文件 require by once 的特性，减少多余的传输。 我不知道这些观念你知不知道，如果没听过就当大家分享经验，我也不会介意 ，如果以前就知道了，那就好好想想自己干麽那麽无聊到处找人抬杠。 -- The Internet: where men are men, women are men, and children are FBI agents. --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 220.130.223.207 ※ 编辑: roga 来自: 220.130.223.207 (06/02 15:18)