什麼導致我的Laravel應用程序放慢速度？

Question

我有一個使用Laravel 5.2和Eloquent ORM開發的應用程序。該應用程序連接到MS SQL Server以讀取/寫入數據。

我遇到了應用程序有時減慢性能問題「的頁面需要至少5秒鐘響應」

我安裝了「發條」試試，看看有什麼是需要長時間來執行。在深入瞭解多個請求之後，我注意到有些查詢需要很長時間才能完成。

這是查詢耗時約1600ms完成的一個示例。 （1600ms之間包括犯下和網絡延遲。）

INSERT into [items] ([control_id], [created_at], [interview_id], [is_default], [item_id], [item_title], [item_type], [reporting_value], [updated_at]) 
values ('328', '2016-06-23 23:12:02', '6278', 'No', '1105', '1 (Poor)', 'Answer', '1', '2016-06-23 23:12:02'), 
('328', '2016-06-23 23:12:02', '6278', 'No', '1106', '2', 'Answer', '2', '2016-06-23 23:12:02'), 
('328', '2016-06-23 23:12:02', '6278', 'No', '1107', '3', 'Answer', '3', '2016-06-23 23:12:02'), 
('328', '2016-06-23 23:12:02', '6278', 'No', '1108', '4', 'Answer', '4', '2016-06-23 23:12:02'), 
('328', '2016-06-23 23:12:02', '6278', 'No', '1109', '5', 'Answer', '5', '2016-06-23 23:12:02'), 
('328', '2016-06-23 23:12:02', '6278', 'No', '1110', '6', 'Answer', '6', '2016-06-23 23:12:02'), 
('328', '2016-06-23 23:12:02', '6278', 'No', '1111', '7', 'Answer', '7', '2016-06-23 23:12:02'), 
('328', '2016-06-23 23:12:02', '6278', 'No', '1112', '8', 'Answer', '8', '2016-06-23 23:12:02'), 
('328', '2016-06-23 23:12:02', '6278', 'No', '1113', '9', 'Answer', '9', '2016-06-23 23:12:02'), 
('328', '2016-06-23 23:12:02', '6278', 'No', '1114', '10 (Excellent)', 'Answer', '10', '2016-06-23 23:12:02'), 
('328', '2016-06-23 23:12:02', '6278', 'No', '1608', 'Don''t Know', 'Others', '98', '2016-06-23 23:12:02'), 
('328', '2016-06-23 23:12:02', '6278', 'No', '1708', 'Does not have item/department', 'Answer', '99', '2016-06-23 23:12:02'), 
('338', '2016-06-23 23:12:02', '6278', 'No', '1205', '1 (Poor)', 'Answer', '1', '2016-06-23 23:12:02'), 
('338', '2016-06-23 23:12:02', '6278', 'No', '1206', '2', 'Answer', '2', '2016-06-23 23:12:02'), 
('338', '2016-06-23 23:12:02', '6278', 'No', '1207', '3', 'Answer', '3', '2016-06-23 23:12:02'), 
('338', '2016-06-23 23:12:02', '6278', 'No', '1208', '4', 'Answer', '4', '2016-06-23 23:12:02'), 
('338', '2016-06-23 23:12:02', '6278', 'No', '1209', '5', 'Answer', '5', '2016-06-23 23:12:02'), 
('338', '2016-06-23 23:12:02', '6278', 'No', '1210', '6', 'Answer', '6', '2016-06-23 23:12:02'), 
('338', '2016-06-23 23:12:02', '6278', 'No', '1211', '7', 'Answer', '7', '2016-06-23 23:12:02'), 
('338', '2016-06-23 23:12:02', '6278', 'No', '1212', '8', 'Answer', '8', '2016-06-23 23:12:02'), 
('338', '2016-06-23 23:12:02', '6278', 'No', '1213', '9', 'Answer', '9', '2016-06-23 23:12:02'), 
('338', '2016-06-23 23:12:02', '6278', 'No', '1214', '10 (Excellent)', 'Answer', '10', '2016-06-23 23:12:02'), 
('338', '2016-06-23 23:12:02', '6278', 'No', '1618', 'Don''t Know', 'Others', '98', '2016-06-23 23:12:02'), 
('338', '2016-06-23 23:12:02', '6278', 'No', '1721', 'Does not have item/department', 'Answer', '99', '2016-06-23 23:12:02'), 
('408', '2016-06-23 23:12:02', '6278', 'No', '1472', '1 (Poor)', 'Answer', '1', '2016-06-23 23:12:02'), 
('408', '2016-06-23 23:12:02', '6278', 'No', '1473', '2', 'Answer', '2', '2016-06-23 23:12:02'), 
('408', '2016-06-23 23:12:02', '6278', 'No', '1474', '3', 'Answer', '3', '2016-06-23 23:12:02'), 
('408', '2016-06-23 23:12:02', '6278', 'No', '1475', '4', 'Answer', '4', '2016-06-23 23:12:02'), 
('408', '2016-06-23 23:12:02', '6278', 'No', '1476', '5', 'Answer', '5', '2016-06-23 23:12:02'), 
('408', '2016-06-23 23:12:02', '6278', 'No', '1477', '6', 'Answer', '6', '2016-06-23 23:12:02'), 
('408', '2016-06-23 23:12:02', '6278', 'No', '1478', '7', 'Answer', '7', '2016-06-23 23:12:02'), 
('408', '2016-06-23 23:12:02', '6278', 'No', '1479', '8', 'Answer', '8', '2016-06-23 23:12:02'), 
('408', '2016-06-23 23:12:02', '6278', 'No', '1480', '9', 'Answer', '9', '2016-06-23 23:12:02'), 
('408', '2016-06-23 23:12:02', '6278', 'No', '1481', '10 (Excellent)', 'Answer', '10', '2016-06-23 23:12:02'), 
('408', '2016-06-23 23:12:02', '6278', 'No', '1648', 'Don''t Know', 'Others', '98', '2016-06-23 23:12:02'), 
('408', '2016-06-23 23:12:02', '6278', 'No', '1733', 'Does not have item/department', 'Answer', '99', '2016-06-23 23:12:02') 

當我直接用MS SQL Server Management Studio中它完成於00:00:00告訴我，數據庫服務器運行正常執行這個查詢，也沒有數據服務器端的延遲。

由於插入了大量數據，我在考慮PDO花費很長時間來準備聲明，這會導致延遲，因爲這裏有36行正在準備中。但是，問題也可能是PDO需要一段時間才能連接數據庫，這就是爲什麼我看到延遲是一個會延遲整個應用程序的查詢。

這是另一個簡單的查詢，它在1300 ms後返回1行，在MS SQL Management Studio中執行它時在00:00:01完成。

SELECT * FROM [stext] WHERE [interview_id] = '6278' and [control_id] in ('306') ORDER BY [id] ASC 

此查詢沒有太多的準備，但仍需要1300多萬年才能完成。

Web服務器和數據服務器都在同一個網絡和主機上。兩者都位於同一個實體房間，所以不應該有任何網絡問題。我甚至試圖ping服務器，ping看起來很正常。

我如何知道是什麼導致我的應用程序變慢？是PDO績效問題，還是花言巧語需要很長時間才能做好準備？

我該如何解決這個問題？

爲上面的查詢，這是雄辯的代碼，我使用

$records = array(array(...), array(...)); 
Item::insert($records); 

Answer 1

以我的經驗，最好不要使用PDO對於批量插入與記錄thundreds。這是緩慢的大量準備好的數據。 最好爲此目的創建簡單的查詢。