私の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') 

私が直接、データベースサーバが正常に動作していないと何があることを私に伝えて00:00:00に終了したMS SQL Server Management Studioを使用して、このクエリを実行するとデータサーバ側の遅延。

私はPDOがここに準備されている36行があるという単純な事実のために遅延を引き起こしている文を準備するのに長い時間がかかっている考えています挿入されるデータがたくさんあるので。しかし、問題は、PDOがデータベースを接続するのに時間がかかることがあります。なぜなら、遅延は、アプリケーション全体を遅延させるクエリだからです。ここで

は、MS SQL管理スタジオでそれを実行する際に午前0時00分01秒で完了した1行を返すために1300msを引き継いだ別の単純なクエリです。

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

このクエリではあまり準備する必要はありませんが、1300msを超えています。

Webサーバとデータ・サーバの両方が同じネットワークとホスト上にあります。どちらも同じ物理的な部屋に配置されているので、ネットワークに問題はないはずです。私はさらにサーバにpingを試みましたが、pingは非常に正常です。私は自分のアプリケーションを遅くする原因になっているものを伝えることができますどのように

？それはPDOのパフォーマンスの問題ですか、それとも、文章を準備するのに時間がかかりますか？

どうすればこの問題を解決できますか？上記のクエリのための

、これは私はレコードのthundredsで一括挿入のためにPDOを使用しない方がよい私の経験では

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

Answer 1

を使用雄弁コードです。大量の準備データではゆっくりです。 この目的のために簡単なクエリを作成する方が良いです。