老是把timeout加大也不是辦法，你就算拖到10分鐘，要是使用者等不住直接關掉，或是日後資料量更多時跑的更慢，timeout可不是無極限拉大的啊，應該先把問題找出來
看是不是SQL查詢的方式耗費太多處理時間？那就設法精簡查詢方式，或是以ajax異步執行的方式把大量的資料分開處理，而不要全部集中在啟動頁面時加載
還是做無意義的爬別人網站的資料太久？讓客戶端久等，如果是，那把爬到的資料做成快取資料存在自己的主機上，變動不大的資料比如說台灣千大企業、上市櫃公司通訊資料，這些就不用即時去爬，做成快取一天爬一次甚至一個星期或一個月爬一次都無所謂，如果是爬股市行情，也請善用異步處理，一股一股分開查，查不到也不要直接卡死網頁，這樣就會減低timeout的機會
至於頁面連接量過大，大過你的主機或網路最大限度，看看那些連接是否都是有效連接(非惡意攻擊DDoS)，如果是惡意阻絕攻擊多，那就想辦法在防火牆上設法處理，如果是正常連接但連接量過大，那就花錢提升頻寬、更新網路設備到1G或10GB級、還有伺服器的處理器、記憶體，作業系統版本、MY/MSSQL的最大可連接數也是你要考量的對象
您好
感謝您的提醒，但我遇到的情況如下：
網站執行某個動作後會發出請求，對方收到請求後，處理完成會回傳處理結果，我的網站收到結果後顯示到網頁上。
但是對方執行的動作中包含將資料插入資料庫，而資料庫分布在全球，每次更新資料庫都會需要一點時間，這部分我無法做調整，所以我只能先延長timeout，確保User使用是正常。
另外，這個網站有測試環境，只有我在使用，與正式環境一樣，發出請求後等待2min都會出現time-out，所以應該不是惡意攻擊或連線數飽和，其他硬體配置、MySQL連線數也沒有超出限制。
再麻煩各位提供可能的解決方案，謝謝
是否可以把這個Request做成async處理？
可以做成非同步處理，但對方的回傳結果需要顯示在網頁上，所以網頁還是得等到收到結果才行，那現在等不到回傳就先遇到了2min的timeout限制。
或者您是指其他的處理方式?
金流交易就真的沒辦法，timeout就觸發fail再延時幾秒再查，畫面上讓使用者看到"第N次重試等候回應"並提示可能的等候時間，不然真的怕用戶等不住直接給你按F5刷頁面或狠心關閉...eric1223
eric1223
可以請對方修改API，讓你下達更動資料庫命令和查詢執行結果兩件事分開做嗎？就像我做網頁發送簡訊的功能一樣，我對簡訊平台的API發送簡訊，只取得一個TOKEN，我會在網頁前端用個類似手機轉圈圈的圖案讓使用者等，我會每隔幾秒去平台用拿到的TOKEN輪詢傳送結果，是手機收到了呢？還是手機號碼無效？還是拒收？還是系統封鎖？
而不是在用戶發送訊息出去到API之後，讓使用者空等...
PHP網站???
若是網站的話，
建議回頭檢視程式碼是否效能太差或有異常
幾個建議
若是背景執行的話，可以加下面這兩行，使其可以背景執行
// Ignore user aborts and allow the script to run forever
ignore_user_abort(true);
// disable php time limit
set_time_limit(0);
昨天本來要回應的。但喝醉了...
正常來說，你直接第一個想法，是要增加timeout的時間。
這是一個很要不得的想法。
如果主機架設評分100分。
你這個想法會直接扣50分。
甚至相關人員，會因為你這個想法。而完全不敢給你主機的操控權。
因為你這樣的想法。正是操死主機的原兇之一。
好吧，唸到這就好。
那或許你會說，我就是需要等待回應怎麼辦?
處理這種長時間等待的。你並不需要一直佔住人家門口。
你可以先回家，打電話問一下。或是等對方通知。
沒有一種金流，會需要你連著他等他1分以上的。(30秒就很危險了)
有這樣的金流的話，我一定不敢用。太可怕了。
至於如果是對岸那微啥或支啥還是寶啥的東東。
那是無解的東西。且可以的話，建議一下你的上級。不要再x下去了。
會xxx人的。
以上....頭好痛。宿醉中
空大總是一針見血..(我已血流成河)
j大該不會也用的卡啥寶啥的...
目前都是用轉啥的。
雲啥的雖然有客戶要求。現在一律不處理了。
因為用啥死啥「貝加立口」多。
我說啥的??懂就好，不懂可以問，但我也不會回答。
懂嘛?
我沒在處理金流的事，畢竟公司面對的客戶都是政府機關、台塑、聯電這些大廠...誰跟我們玩線上金流啊，都嘛LC或TT
至於支什麼宝的，我是有在用啊，沒遇過什麼交易過久而錯誤訊息的事，基本上是按完密碼送出，一秒完成所有交易，微X的話是很少用，需要的話都是把QRCODE傳給對岸的朋友幫我付掉，我再轉支X宝的錢給她就完成，反倒是手機操作比電腦還順暢
感謝兩位大大的解說，其實我的系統比較簡單，也沒像兩位負責的這麼有重要性，就是個線上學習的管理系統，只是公司有在海外的員工，所以全球都有當地的資料庫，有的在雲上有的在地上，所以當我的系統把線上課程的資料指派出去(有支API會分送到當地的資料庫)，就需要回傳是否成功的訊息，以免有漏掉。
目前來說，執行指派課程可能2-3個月才會做一次，使用頻率很低，但如果人數多或網路不穩定就一定會需要時間，我只是想避免user遇到網頁掛掉的問題，同時也想確認這個2min的timeout到底是從哪裡回報出來的?
至於對方的那支API我也正在協調中，但近期內應該很難解決 "縮短插入資料庫到回傳結果"的反應時間。
不要有「不可能」縮短這樣的想法。
這樣你就不會再進步。
一般來說，如果像你說的只是單純的插入資料。
要先來看的是，要從何下手。
插入資料的量下手。還是對方的api運做原理下手。
如果說是需要一次性好幾千萬筆的資料插入。
是否可以分批傳入??檔案性傳入?還是??
能否步進處理(需要對方配合)
背景式處理?
我用個說明
像我也曾經碰過需要超過等待幾分的情況。
我就將其動作改成cron背景式命令處理。
而前端只是單純發出指令及資料後。不等待回應。
再利用背景式運行的特性，無timeout問題。
來處理並檢查資料。
很多事情，還是會受限於硬體及環境的情況影響。
而這條路是行不通的。
要找出能行的通的方式。
如1t的東西，要求10秒內完成上下載。
這是不可能辦到的事。(雖然我說了不可能)
但是，先找出是否有其必要性一次真的需要1t上下傳。
能否分批處理，能否後進式處理.....
來達到像是10秒就完成。
還是直接加大頻寬??硬體設備??
我了解您的意思，這種處理方式我這邊需要重寫邏輯，讓Call API的動作放到背景或有支排程去執行，而客戶端則不用等這麼久。
我會往這方向去處理，感謝解答。
iThome鐵人賽
看影片追技術