我有這個項目拍賣入口，問題是有時候用戶不能出價或者更好的單詞是請求出價有時候需要2-3秒才能註冊，衝突是拍賣是在系統檢測到有人出價之前已關閉。瓶頸問題mysql
我添加了一個日誌，看看是怎麼回事，這裏是我發現：
Bid insert date | Auction close date
2012-06-25 14:40:57 2012-06-25 14:40:54
正如你所看到的，拍賣已經接近，但出價被後期處理3秒鐘。 只是澄清，如果拍賣已經關閉，用戶不能出價，所以我確信請求是在關閉之前完成的。
這發生在每天1個成交，我不知道有什麼可以觸發這個問題。 我正在使用PHP和MySQL。
不要匹配的確切截止時間戳記，但它與 （截止時間 - turnaround_time）進行比較。
比方說關閉時間是14:00:00和週轉時間的請求是10秒。然後，如果在13:59:50之前提出請求，則只會予以考慮。
你的實現與規格有點不同。我不能只是改變它來解決這個問題。 – Paengski 2012-07-10 07:40:54
一個可能的原因是，用戶加載包括「出價」按鈕的頁面，拍賣結束時，按鈕仍然存在和作用得到相應的執行。如果您要在插入之前驗證拍賣是否已關閉，則不應發生此情況。 SELECT和INSERT之間的時間不應該大於0.1秒。我假設您在添加最後一次出價之前不會驗證拍賣的狀態。
正如我所提到的。如果拍賣已經結束，用戶將無法拍賣以及登錄。有一些過程會導致一個瓶頸，至少每天只發生一次。邏輯是正確的，以及驗證。 – Paengski 2012-07-10 07:34:12
@Rafael你說這個邏輯是正確的，但是如果你知道這個問題是什麼，你不會在這裏問，所以一些關於你在做什麼檢查的細節可能會有幫助 - 如果可能的話，最好是實際的代碼。 – Braiba 2012-07-10 07:58:32
@Rafael：這意味着您上次驗證和插入之間的時間超過3秒。因此，我藐視你的陳述，你的邏輯是正確的。我至少懷疑它。 – Sherlock 2012-07-10 08:03:51
2-3秒？
多少查詢你在出價請求的點上運行？我會想象：
1）用戶是否登錄？ 2）有沒有賬號可以出價？ 3）拍賣是否仍然開放？ 4）投標
我不會想象這4個查詢將花費超過一秒的時間運行，除非你有非常寫的查詢。你使用的是哪個MySQL數據庫層？你確保你的代碼儘可能簡化嗎？即多久你打開數據庫等
如果他們出價之前被處理他們的出價，堅韌餅乾拍賣結束。你沒有贏。有時在eBay上也會發生同樣的事情，而且它很艱難。如果問題在於您的系統允許延遲競標，那麼您需要在這方面重新訪問您的代碼。最後的出價嘗試應該確保在出價保存前查看拍賣是否仍在運行。這不應該接近一秒鐘。
也許你應該查看你的表索引了。太少，數據搜索速度慢，數量太多，數據插入速度受到影響。
從簡單的索引錯誤到不友好的查詢/循環等等，可能會有很多錯誤。
我對「您打開數據庫的頻率」感興趣。我不熟悉線程和/或數據庫配置。 我相信，當我嘗試出價立即註冊時，查詢的優化以及索引，大部分時間。所以這意味着處理非常快。然而，隨機的時候，有人會抱怨用戶出價但沒有註冊，而且這種情況每天只發生1到2次。 我不確定他們的互聯網連接，打開連接或數據庫配置是否太多導致此問題 – Paengski 2012-07-10 08:30:32
你可以提供一些關於你的網站託管的信息嗎？它只是一個單獨的LAMP服務器，還是你有多個服務器，並且你使用的是什麼類型的硬件和負載平衡？還有關於獲得多少流量的信息將有助於確定這是否是您的代碼或硬件的問題。 – 2012-07-10 06:49:58
我們應該想象哪個是您的硬件，代碼，您使用的查詢等？或者，我們是否應該點擊您提供的鏈接？ – Marco 2012-07-10 06:51:24
我們使用Windows服務器，我不熟悉我們的服務器規格。但我認爲它足夠支持每一個請求。流量還不是很高，因爲只有不到200名成員，其中大部分都不活躍。 正在運行的mysql事件正在運行X秒用於檢查每次拍賣的狀態以及是否有人爲投標人設置了自動出價。 我懷疑它是mysql的配置，但我不知道要檢查什麼，我已經將一些表遷移到innoDB，因爲大多數表正在改變 – Paengski 2012-07-10 07:46:08