在構建 SaaS 應用程式時定義一個多線程閾值

回到雲島：所有 SaaS 使用者都很高興。因為他們能獲得快速響應。因為這些使用者惟一擁有的控制權就是對 訪問應用程式的控制，他們不擔心應用程式是否有多線程常式；也不擔心在雲中有多少核心用於並行加速多線 程的處理。問題應用程式被成功地從內部多線程 COBOL 遺留系統中遷移出來。

當然，有一天，SaaS 應用程式的速度會慢下來，而且越來越慢；直到使用者無法忍受。他們這時才發現：

只有一個核心在正 常運行，其餘核心都發生了故障。

SaaS 訂閱僅限於兩個核心，而不是所有四個核心。

SaaS 應用程式近 來升級出現了多線程缺陷。

容錯移轉計劃失敗。

同時，在島上的功能部門，Team Dev的人們聚在一 起思考各種解決方案，想讓系統再次恢複運轉。

本文協助您探索多線程的效能問題，文中介紹了我第 一次遇到多線程時的遭遇（簡言之，我會儘力將損失降至最低）。然後，本文查看了多線程式控制制模型雲使用者是 否在 Java 和 COBOL 中進行訪問，並建立一個簡潔的內建多線程支援。本文旨在向您展示供應商能夠採取哪 些積極措施來停止傷害、解決問題、恢複系統和通知客戶。

多線程效能

CPU 中的核心越多，在 執行程式代碼指令時，多線程的表現就會越好，但是使用的核心數量不是決定多線程軟體執行情況的惟一因素 。另一個因素是：對於某個任務或者進程，使用一個演算法來完成完整的線程並行並不總是可行的。某些線程的 計算已經在之前的步驟中並行化了，可能得到一個連續的結果。

考慮到應用程式分散在模組中，每個 都被設計用於完成一個任務或者進程。在一個模組中，可以有 6 個幾乎並行的單一線程。我們假設：

a 是線程 1，b 是線程 2，c 是線程 3，d 是線程 4，e 是線程 5，f 是線程 6

結果 r0、r1 和 r2 分別作為兩個獨立線程的組合并行線程進行計算，如下所示：

r0 = a + b
r1 = c + d
r2 = e + f

然而，添加所有三個並行線程結果（r0，r1 和 r2）會得到連續結果 g — 這並不是一 個新並行線程，如下所示：

g = r0 + r1 + r2

所有連續的部分都必須等待上一步中並行化的線 程發出準備好的訊號。程式中的連續部分越多，從多核中獲得的好處就越少。

其他影響多線程演算法的 因素包括：

COBOL 的 THREAD 編譯器選項限制。

Java 的多線程程式的限制。

將緊耦合 COBOL 程式中的缺陷分解到松耦合 SaaS 應用程式中。

雲使用者控制。

多線程閾值缺失。

我第一次遭遇線程

十幾年前，在我第一次使用主機 COBOL 時，我考慮用非 COBOL 語言與其互動。我與一位教授進行了 有關的討論，計劃將此作為有關 COBOL 介面效能的論文主題。我分享了關於在程式碼中並行化線程來獲得 子程式的想法。

為了弄清楚什麼會影響效能，我根據 “Fortran 介面適用於 CODASYL 資料庫工作群組 規範”（參閱 參考資料）對迷你 COBOL/Fortran 介面進行了實驗。Fortran 是當時的流行語言。那個時候， COBOL 還不像我們現在這樣擁有 THREAD 選項。與如今我們見到的大型處理器相比，當時最大容量的處理器也 非常小。

在我的實驗中，我發現部分 COBOL 資料類型沒有 Fortran 等同物。當應用程式不再需要的 資料或者對象存在於磁碟上時，我根據需要調用子程式繞開了記憶體限制，然後在不需要資料或者對象時釋放它 們並自動刪除不再需要的資料。

每個子程式執行一個或者多個任務。在某些任務中，幾個線程作為一 個並行線程進行計算（r0 = 線程 a + 線程 b）。所有連續部分都在等待上一步中的並行化線程發出準備好的 訊號。等待很短暫。

如果當時我們有雲，就可以使用運行在多核虛擬機器上的平台即服務 (PaaS) 上的 多線程常式來開發一個 SaaS 應用程式。