q00153提到：
即時變化的資料流

即時資料運算慢, 可能會有兩種瓶頸:

1. Disk I/O 太慢
2. 軟體運算速度太慢

從硬體層面, 應先量測出運算期間的 DIsk I/O, 是否已經超過硬體負荷水準? 如果硬體超限未改善, 妳的軟體如何改善都沒用, 照樣被硬體拖垮.

軟體運算問題牽涉很多, 有可能演算法寫得不好, 也有可能程式結構不好 (如您所猜測的型別轉換問題), 但也可能是程式語言本身就慢....這些都需要一一去釐清.

我有個客戶用 Java 存取 SQL 資料, 以前都沒有問題, 某天它們將 DB Schema 中的某個欄位型別, 從 varchar 改為 nvarchar, 因為資料內容相同, 所以他們沒有去改程式裡面的 SQL 指令型別.

結果隔天, SQL DB 的 CPU 暴衝, 反應速度奇慢無比, 找我求救, 我幫她從原本的 4 CPU, 一路加到 20 顆 CPU, 才稍微緩解掉速度慢的問題. 問他們原因, 都說:「沒改程式, 不是程式問題」, 後來查出, 因為 Schema 的型別和 SQL 下的指令不同, 導致每一筆 Select/Update/Insert 指令, CPU 都要費時去做型別轉換, 導致 CPU 爆掛...後來將程式裡的 SQL 指令型別改為跟 DB 一致之後, CPU 用量就下降.

另一個例子, 也是 SQL 查詢速度很慢, 經過 SQL Profiler 的分析, 發現是慢在某一條 SQL 指令的邏輯, 將此問題告知設計人員, 經她重新安排 SQL 查詢的邏輯之後, 整體查詢速度提高 12 倍.

此外, 也並不是即時資料就一定只能當場查詢所有資料. 試想, 當你在查詢 20 幾萬筆資料時, 即時資料還是持續在跑啊! 除非你能叫資料停下來. 假設你的需求是: 統計 20 幾萬筆資料的平均值的話, 其實不需要一次撈 20 萬筆, 妳可以用一個 Store Procedure 取代 Insert/Update 的動作, 每進來一筆, 就做一次總平均的計算, 然後把結果存起來. 這樣做, 當最後一筆資料進來後, 平均值就已經算好了, 不需要再重新撈一次所有資料. 雖然每次 Update/Insert 會多花一點點時間, 但是那一點點如果夠快的話, 其實不影響原本的更新動作, 但卻可以省下最後要一次撈數十萬筆的大量時間.

此外, PHP 並非速度最快的程式語言, 如果你確信: 硬體/演算法/SQL邏輯, 都沒有改善的空間了, 那麼可能要考慮提升程式語言本身的能力. 在這個評比中, PHP 花了 44 分鐘才完成評比項目, Python 花了 33 分鐘, 但是 Java 只花了 68 秒.

如果上述條件都成立, 但你沒有能力更換程式語言的話, 可以考慮將 PHP 編譯過再執行, 這類的 JIT Compilation 套件有如: Zend, HHVM等, 都可以加速 PHP 的執行, 不過這是治標不治本.