※ 引述《JYHuang (夏天到了，冷不起来了说)》之铭言： : 先查询的会因为回传慢而後显示？ : 在PHP那方面有取消资料库Query的功能吗？ : client这方面该怎麽防范这种 : 重复执行同一支ajax造成的问题？ : -- : → TonyQ:一个查询进行中时先lock住 ui , 不要让使用者改就好. 05/16 18:03 : → TonyQ:多个ajax同时进行中时 , 的确是不能保证顺序没错. 05/16 18:03 : 推 TonyQ:不然就是你让checkbox的反应时间慢一点 , ex.两秒後才反应 05/16 18:14 : → TonyQ:这段期间使用者的异动让它动这样. 总的来说 ,减少request跟 05/16 18:14 : → TonyQ:提高 mysql 查询的效能 (index,减少查询复杂度) 双管齐下. 05/16 18:15 : → TonyQ:才能得到比较好的效益. 05/16 18:15 : → JYHuang:效能会低我猜主要是因为资料相当多 05/16 19:41 : ※ JYHuang:转录至看板 PHP 05/16 19:42 : → fillano:另一个方法是用queue来管理这些ajax动作，让他保证循序执 05/16 20:43 : → fillano:行。不过我怕如果多了，说不定放在queue里面的东西越来越 05/16 20:44 : → fillano:多...所以lock住ui是第一个选择，除非对方要求... 05/16 20:45 : → JYHuang:我提出的方案也是lock ui，不过不被接受 = =" 05/16 20:54 这个大概只能用硬解（至少小弟也只想的到这种…囧） client 端的硬解有几种，其一是 T 大的 ui lock， 另一种是费大的 request queue， 不过如果是小弟的话，会视情况在 request queue 上做一些手脚， 也就是每一个 ui event / action 转成 request 进入 queue 的时候， 都先 hold 住 2 秒（或 1 秒半或任何比较好的秒数）， 如果确认没有新的 request 送过来，就视为正确然後放他进 queue， 不然就更新当下的 request 并且再多 hold 住 1 秒。 （因为连续性操作有可能是使用者在更新前次的操作失误） 伺服器端的硬解就比较麻烦了，我们将他拆成两个情况检讨， 如果是属於多层次的运算程序，可以在各运算之间插入检查点， 也就是预先准备一个 table 或 file 或 mem 的 cache， 新进的 request 会去产生异动记录，让运算间的检查点做 check， 发现有新的 request 就放弃所有已做过的运算全部重来一次 （也可以视情况不理会，先丢出一个阶段性的结果， 伪装成 ui 的过度操作导致 server 没有收到讯号或着什麽的… :p ） 如果伺服端的运算是属於直深式的那就很难做了， （譬如一组复杂的 SQL 就进去拉结果资料） 当然你可以 show processlist 做 filter 然後 kill（在 mysql 下）， 但若用这种危险到不行的动作，还不如直接让他算完吧… orz 这边能避免的也只有，如果後面有进来新的 request ， 在送出资料前做刚刚提到的最後一次异动检查， 假如需求被更新了，那是不是要放弃目前的结果集再重新捞一次。 讲个比较不负责任的东西 XDD 如果这些 checkbox 的触发，是在对原本的 query 做 filter 或扩展， 那麽上面提到的伺服器端的重新运算，其实可以分别降低成 将已取得的结果集筛选後传回（如果是 filter）， 将目前缺少的集合部份用新的 query 下去取然後合并至目前的（如果是拓展） -- 题外话，要提昇 DB 效能就又是另一回事了， 抓 memcache 出来用，或针对 key data 做衍生的新 table， 甚至用打基础的方式做每日的 data parsing 拆解出 search 用的资料等等… 小弟能想到的几个作法大概也就是这样了吧 XDD --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 220.136.228.229