Re: [討論] 前陣看到一個Ajax搜尋的Case

[gpmm (銀色)]

※ 引述《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
→ gpmm:啊…少看到 T 大也有講到暫緩送出這個 XDD
推 Kelunyang:那編號呢？每次返回的時候的編號必須要和client的編號
→ Kelunyang:相符才會顯示？
→ Kelunyang:另外G大這個延伸查詢的方法，意思是要建立很多個View嗎
→ Kelunyang:嗎@@?聽起來好像蠻快的，但是會不會把資料庫搞得很複雜
→ gpmm:編號？編號是指什麼…囧a"
推 Kelunyang:就是因為我不能叫Server砍掉正在查詢的Thread
→ Kelunyang:那我送出request的時候就寫比如id=0001，每次改變都+1
→ Kelunyang:這樣最後返回的東西如果不等於現在的id，就不顯示
→ Kelunyang:這樣不行嗎@@"
→ gpmm:不行 XDDDD
→ gpmm:你的理論正確，但是對使用者來說應該會很挫折 XDD
→ gpmm:因為只要他不小心多按了，回來的資訊就會消失在黑洞裡