推 mrbigmouth:前端 client端都會跑太久的東西 server肯定吃不下 12/21 14:28
→ mrbigmouth:而前後端在跑的時後前端還不是一樣要等? 12/21 14:28
→ mrbigmouth:分功上 後端要作的在於有安全需要的東西 比如說帳號 12/21 14:29
推 adamp3:肯定是前端 你試想假設同時有幾萬人做同樣的指令 要放哪好? 12/21 15:53
→ TonyQ:資料整理聽起來是server side , data provider 該負責產出 12/22 01:46
→ TonyQ:的 json ，這個應該是歸類在server side 。 12/22 01:46
→ TonyQ:我的看法是「提供資料」=> server side的責任 12/22 01:47
→ TonyQ:界面、事件、互動=> client side的責任 12/22 01:47
→ TonyQ:另外我不同意mrbig 說client端跑太久的東西 server吃不下 12/22 01:47
→ TonyQ:client 的 performance 相對於 server 是超級弱的。 12/22 01:47
→ TonyQ:同樣一個xml parsing , server 只要1s , client 可能要2~4s 12/22 01:48
→ TonyQ:只是client用的是使用者的資源，server用的是server的資源 12/22 01:48
→ TonyQ:考慮到資源的運用上，能盡量轉嫁給user的就盡量凹。 12/22 01:48
→ TonyQ:但 server 是不是吃不下，要視狀況決定。 12/22 01:49
推 mrbigmouth:假設server的速度是client的4倍 同時有4人以上使用serv 12/22 10:41
→ mrbigmouth:er的機率有多少? 如果很少甚至通常只有一人的話當然可 12/22 10:41
→ mrbigmouth:以全丟給server... 12/22 10:41
→ mrbigmouth:但還要考慮網路傳輸的問題 通常情況,未經過處理的原始 12/22 10:42
→ mrbigmouth:資料會比經過處理格式化的資料要小 傳輸速率也會快 12/22 10:42
→ mrbigmouth:再怎考慮各種情形 我還是覺得能轉嫁給user的就全給user 12/22 10:44
→ mrbigmouth:server只要考慮"應該丟給使用者什麼資料才安全"即可 12/22 10:44
推 mrbigmouth:除非你的主機已經強大到跟google一樣的可當雲端層級... 12/22 11:07
→ mrbigmouth:而且還到處都有分支主機保證傳輸速率在一定之內... 12/22 11:09
→ mrbigmouth:雲端計算的模式才會有比較快的可能 12/22 11:10
→ TonyQ:我覺得你想的有點多 如果是預先處理好的資料 在存檔時就可以 12/22 14:11
→ TonyQ:先按照他要輸出的資料格式先做好。我用1:4 是很客氣的假設 12/22 14:11
→ TonyQ:他輸出時還要經過處理，正常來講作為資料提供通常都已經先 12/22 14:12
→ TonyQ:做好該作得資料格式轉換甚至是cache 。而且server橫豎是需要 12/22 14:12
→ TonyQ:提供資料的。而且未經過處理的資料怎麼可能比格式化還小， 12/22 14:12
→ TonyQ:真的是這樣那根本是格式有問題吧。 12/22 14:12
→ TonyQ:再加上server 還可以作gzip，比起丟一堆大量的原生資料進行 12/22 14:13
→ TonyQ:分析，當然是先搞定資料啊。Orz 12/22 14:14
→ TonyQ:他的這個需求計算的部份很小，倒是資料怎麼儲存怎麼最低成本 12/22 14:16
→ TonyQ:轉換成VO的多，幾乎都可以將運算量壓到最低的case。 12/22 14:16
→ TonyQ:應該要討論的是怎麼儲存資料跟怎麼轉換成Json最有效率， 12/22 14:17
→ TonyQ:client跟server 的效能根本不是這個問題的重點。 12/22 14:17
→ TonyQ:我不是不同意可以轉嫁成本給 client ，但是幹嘛要先把成本弄 12/22 14:20
→ TonyQ:得很高再讓client 收尾巴，一開始就讓成本很低就好啦... 12/22 14:21
推 mrbigmouth:做gzip也需要主機端的資源 預先以需要輸出的資料格式儲 12/22 14:42
→ mrbigmouth:存也只是把運算時花的時間移到儲存時 12/22 14:42
→ mrbigmouth:我相信這樣搞之後 也許最後加起來的總消耗時間或許真的 12/22 14:43
→ mrbigmouth:比"全部丟給client端就好"加總再平均之後來得快啦... 12/22 14:45
→ mrbigmouth:但你確定原po需要的是這種答案?|| 12/22 14:45
→ mrbigmouth:我所謂"處理過後的資料"指得是"已經確定必須的資料"再 12/22 14:48
→ mrbigmouth:上"格式"後的結果,即使是json都要加上一堆{}"": 更何況 12/22 14:48
→ mrbigmouth:是html...原始資料肯定比較小啊... 12/22 14:49
→ mrbigmouth:至於server端的資料從何而來...我一直以為大部分初學者 12/22 14:51
→ mrbigmouth:都是直接從DB撈啦...如果原po是那種是先按輸出做好格式 12/22 14:52
→ mrbigmouth:外加視情況寫好快取的人...千萬不要聽我的話 我是小咖 12/22 14:52
→ TonyQ:你原始資料還不是要有separator 要有escaping 12/22 14:56
→ TonyQ:不然你怎麼分段切割 12/22 14:57
→ TonyQ:{} "" 那都是判斷資料格式中的必須 你省他只是找自己麻煩 12/22 14:57
→ TonyQ:從db撈出來也不過就是一堆RecordSet 你還是要output啊 12/22 14:58
→ TonyQ:我很確定這個需求不可能產生你說的這種情況，這種需求我 12/22 14:58
推 mrbigmouth:所以你的意思是 json比CVS還小? 從DB撈出來的資料轉為 12/22 14:58
→ mrbigmouth:CVS花的資源比轉為json還大? 12/22 14:59
→ TonyQ:做過沒有二三十次也至少有十次以上，很基本的需求啊。 12/22 14:59
→ mrbigmouth:更正 是CSV 12/22 15:00
→ TonyQ:我覺得如果你output 是 cvs ，1.除非你db就是存cvs字串 12/22 15:00
→ TonyQ:不然轉csv 跟轉json來講，效能上幾乎是一樣的。 12/22 15:00
→ TonyQ:但是前者可以避免client side 的多餘邏輯跟運算效能。 12/22 15:01
→ TonyQ:2.csv 跟json 來講 誰大誰小 以array來講 ok 他的確有機會 12/22 15:01
→ TonyQ:小一點，但是那個差距幾乎可說是小於可忽略的。 12/22 15:01
→ TonyQ: *我的意思是轉json 12/22 15:02
→ TonyQ:而且你說csv，那他就限定不能有多層結構，一有多層結構csv 12/22 15:03
→ TonyQ:絕對沒有json經濟。 12/22 15:03
→ TonyQ:當然 我也不是建議原po輸出html ，如果你以為我說的資料提供 12/22 15:07
推 mrbigmouth:問題就在於從DB撈出來的資料不會有多層結構啊... 12/22 15:07
→ TonyQ:是html，那的確是誤會。因為單就產html這件事情而言，我是 12/22 15:07
→ mrbigmouth:你有多層結構就肯定經過"在處理=花資源"了 12/22 15:07
→ TonyQ:能接受client產html的。 12/22 15:07
→ TonyQ:是嗎？你今天有一個日期有多個事件，這就是一個層次了。 12/22 15:08
→ TonyQ:這些日期可能又會有跨日期的事件，也是層次。而且一樣為什麼 12/22 15:08
→ TonyQ:client 可以直接吃的json 不用，要弄個csv，然後client還要 12/22 15:09
→ mrbigmouth:我覺得我們這樣講滿亂的 你先講吧 我晚上有空再po一篇 12/22 15:09
→ TonyQ:再稿支 csv parser ，量大還會lag(client 效能差) 12/22 15:09
→ TonyQ:我不覺得server產csv跟產json 有量上的差別，你說產xml或 12/22 15:09
→ TonyQ:html會肥 我很同意，但是json 沒有這個問題。 12/22 15:10
→ TonyQ:我覺得我們直接舉實例來討論可能比較快。 12/22 15:10
→ TonyQ:我回文啦 剩下的交給你回吧 12/22 15:14