腳本運行時間長

㈠ 腳本長時間運行是什麼意思

腳本長時衡山間運行是指腳本未響應。腳本運行時間的最長限制默認值為90秒，這是防止無限次循者攔伏環的進行，腳本正常運行超過九十秒的情況不會發生，首攜這時候腳本是未響應的。

㈡ 網頁JAVASCRIPT腳本需長時間才能運行完成

腳本長時間運行的問題通常是由兩個問題引起的：過長的、過深嵌套的函數調用或者是進行大量的處理循環。

第一種情況差不多需要重構你的程序，將函數或者對象之間解耦，減少相互依賴；
第二種情況可以通過展開循環體（通過「達夫設備」之類的演算法來完成，適用於處理大數組的情況）、分塊處理（通過多個定時器分開調用處理該循環，使用於處理的數據無須同步按順序完成的情況）等

㈢ 如何使用Docker構建運行時間較長的腳本

問題
讓我們從這個我試圖解決的問題開始。我開發了一個會運行很長時間的構建腳本，這個腳本中包含了很多的步驟。
這個腳本會運行1-2個小時。
它會從網路下載比較大的文件（超過300M）。
後面的構建步驟依賴前期構建的庫。
但最最煩人的是，運行這個腳本真的需要花很長的時間。
文件系統是固有狀態
我們一般是通過一種有狀態的方式與文件系統進行交互的。我們可以添加、刪除或移動文件。我們可以修改文件的 許可權或者它的訪問時間。大部分獨立的操作都可以撤銷，例如將文件移動到其它地方後，你可以將文件恢復到原來的位置。但我們不會通過快照的方式來將它恢復到 原始狀態。這篇文章我將會介紹如何在耗時較長的腳本中充分利用快照這一特性。
使用聯合文件系統的快照
Docker使用的是聯合文件系統叫做AUFS（譯者註：簡單來說就是支持將不同目錄掛載到同一個虛擬文件系統下的文件系統）。聯合文件系統實現了Union mount。顧名思義，也就是說不同的文件系統的文件和目錄可以分層疊加在單個連貫文件系統之上。這是通過分層的方式完成的。如果一個文件出現在兩個文件系統，那最高層級的文件才會顯示（該文件其它版本也是存在於層級中的，不會改變，只是看不到的）。
在Docker中，每一個在Union mount轉哦給你的文件系統都被稱為layers（層）。使用這種技術可以輕松實現快照，每個快照都是所有層的一個Union mount。
生成腳本的快照
使用快照可以幫助構建一個長時運行的腳本。總的想法是，將一個大的腳本分解為許多小的腳本（我喜歡稱之為 scriptlets），並單獨運行這些小的腳本，腳本運行後為其文件系統打一個快照 （Docker會自動執行此操作）。如果你發現一個scriptlet運行失敗，你可以快速回退到上次的快照，然後再試一次。一旦你完成腳本的構建，並且 可以保證腳本能正常工作，那你就可以將它分配給其它主機。
回過頭來再對比下，如果你沒有使用快照功能了？當你辛辛苦苦等待了一個半小時後，腳本卻構建失敗了，我想除了少部分有耐心的人外，很多人是不想再來一次了，當然，你也會盡最大努力把系統恢復到失敗前的狀態，比如可以刪除一個目錄或運行make clean。
但是，我們可能沒有真正地理解我們正在構建的組件。它可能有復雜的Makefile，它會把把文件放到文件系統中我們不知道的地方，唯一真正確定的途徑是恢復到快照。
使用快照構建腳本的Docker
在本節中，我將介紹我是如何使用Docker實現GHC7.8.3 ARM交叉編譯器的構建腳本。Docker非常適合做這件事，但並非完美。我做了很多看起來沒用的或者不雅的事情，但都是必要的，這都是為了保證將開發腳本的總時間降到最低限度。構建腳本可以在這里找到。
用Dockerfile構建
Docker通過讀取Dockerfile來構建鏡像。Dockerfile會通過一些命令來具體指定應該執行哪些動作。具體使用說明可以參考這篇文章。在我的腳本中主要用到WORKDIR、ADD和RUN。ADD命令非常有用因為它可以讓你在運行之前將外部文件添加到當前Docker鏡像中然後轉換成鏡像的文件系統。你可以在這里看到很多scriptlets構成的構建腳本。
設計
1. 在RUN之前ADD scriptlets
如果你很早就將所有的scriptletsADD在Dockerfile，您可能會遇到以下問題：如果你的腳本構建失敗，你回去修改scriptlet並再次運行docker build。但是你發現，Docker開始在首次加入scriptlets的地方構建！這樣做會浪費了大量的時間並且違背了使用快照的目的。
出現這種情況的原因是由於Docker處理它的中間鏡像（快照）的方式。當Docker通過Dockerfile構建鏡像時，它會與中間鏡像比較當前命令是否一致。然而，在ADD命令的情況下被裝進鏡像的文件里的內容也會被檢查。如果相對於現有的中間鏡像，文件已經改變，那麼Docker也別無選擇，只能從這點開始建立一個新的鏡像。因為Docker不知道這些變化會不會影響到構建。
此外，使用RUN命令要注意，每次運行時它都會導致文件系統有不同的更改。在這種情況下，Docker會發現中間鏡像並使用它，但是這將是錯誤的。RUN命令每次運行時會造成文件系統相同的改變。舉個例子，我確保在我的scriptlets我總是下載了一個已知版本的文件與一個特定MD5校驗。
對Docker 構建緩存更詳細的解釋可以在這里找到。
2.不要使用ENV命令來設置環境變數，請使用scriptlet。
它似乎看起來很有誘惑力：使用ENV命令來設置所有構建腳本需要的環境變數。但是，它不支持變數替換的方式，例如 ENV BASE=$HOME/base 將設置BASE的值為$HOME/base著很可能不是你想要的。
相反，我用ADD命令添加一個名為set-env.sh文件。此文件會包含在後續的scriptlet中：
THIS_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
source $THIS_DIR/set-env-1.sh
如果你沒有在第一時間獲取set-env.sh會怎麼樣呢？它很早就被加入Dockerfile並不意味著修改它將會使隨後的快照無效？
是的，這會有問題。在開發腳本時，我發現，我已經錯過了在set-env.sh添加一個有用的環境變數。解決方案是創建一個新的文件set-env-1.sh包含：
THIS_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
source $THIS_DIR/set-env.sh
if ! [ -e "$CONFIG_SUB_SRC/config.sub" ] ; then
CONFIG_SUB_SRC=${CONFIG_SUB_SRC:-$NCURSES_SRC}
fi
然後，在所有後續的scriptlets文件中包含了此文件。現在，我已經完成了構建腳本，我可以回去解決這個問題了，但是，在某種意義上，它會破壞最初的目標。我將不得不從頭開始運行構建腳本看看這種變化是否能成功。
缺點
一個主要缺點是這種方法是，所構建的鏡像尺寸是大於它實際需求的尺寸。在我的情況下尤其如此，因為我在最後刪除了大量文件的。然而，這些文件都仍然存在於聯合掛載文件系統的底層文件系統內，所以整個鏡像是大於它實際需要的大小至少多餘的是刪除文件的大小。
然而，有一個變通。我沒有公布此鏡像到Docker Hub Registry。相反，我：
使用docker export導出內容為tar文件。
創建一個新的Dockerfile簡單地添加了這個tar文件的內容。
產生尺寸盡可能小的鏡像。
結論
這種方法的優點是雙重的：
它使開發時間降至最低，不再做那些已經構建成功的子組件。你可以專注於那些失敗的組件。
這非常便於維護構建腳本。構建可能會失敗，但只要你搞定Dockerfiel，至少你不必再從頭開始。
此外，正如我前面提到的Docker不僅使寫這些構建腳本更加容易，有了合適的工具同樣可以在任何提供快照的文件系統實現。