4

I have a large application written using Laravel 5.2. The application seems to be running good for a while "day or two" and then it starts slowing down "each request table 15+ seconds."

I am trying to figure out what could be causing the speed degrade. To get started, I listed the top 4 categories "below" that I should review in order.

  1. SQL Server problems. Locks, long running queries.
  2. PHP problem which could be causing extra/not needed work like long running loops
  3. Web Server Issues like memory leaks or slow response time.
  4. Network Issues.

For the first category "i.e. SQL Problems" I evaluated all of the queries and everything seems to be light and fairly fast. There are no long running queries, and I find no SQL locks. Although I did not eliminate this as a possible issue, but for now it is fair to look elsewhere. One thing to note that the application is generating lots of queries which suggests that I may be running into the N+1 case.

While categories 3 and 4 are important, I like to focus some time on the second category "i.e. Code problem" which is where I need help. I need to be able to figure out couple of things to help me make an educated judgement if there is an code issue or not. Here are few thing that I like to know/start logging.

  1. How long each class takes to execute to see if one takes longer time to run.
  2. How many/list of all queries that being generated from each class where I can identify the source of the N+1 case.

I am using Clockwork extension in Google Chrome which is helping me a log. But, I am unable to break down the result at the class level which will give me a deep understanding of what is going on.

How can gather the 2 items listed above? Is it possible to hook into Clockwork and add that info as a filter to it where I just see all that into Google Extension?

Junior
  • 11,602
  • 27
  • 106
  • 212
  • 1
    I have found that most bottlenecks are SQL problems. Are your tables properly indexed? This can make a **huge** difference. Can you reduce the *number* of queries performed by rethinking your logic? – Mike Jun 01 '16 at 17:42
  • Thanks Mike. I think you were reading my mind :) I actually changes my logic and reduced the amount of queries. and I am happy with my indexes for couple of reasons. First the tables are not very large yet so even with tables scans I should not experience 15+ seconds. Second, if the indexing is a problem I would have seen slow "1+ second" running queries when I analyzed my queries. While I am still working on the logic, being able to have class level execution time and queries will give me a best staring point as the app is pretty large and I don't want to read every class. – Junior Jun 01 '16 at 17:48
  • *if the indexing is a problem I would have seen slow "1+ second" running queries when I analyzed my queries* - Not necessarily. MySQL caches queries. So the first time you execute it it could take 1+ seconds and the second time it would be almost instant. – Mike Jun 01 '16 at 17:50
  • See: http://stackoverflow.com/questions/181894/mysql-force-not-to-use-cache-for-testing-speed-of-query – Mike Jun 01 '16 at 17:51
  • Agreed but when reading from cache it will be very fast and can't cause degrade. So that is a benefit and not an issue. Additionally, I should mention that I am using SQL Server not MySQL. But both will cache queries in to RAM. – Junior Jun 01 '16 at 17:52
  • Yes, but it makes finding bottlenecks during testing more difficult if the query you're executing is being cached. Anyway, years ago I used an old version of https://github.com/phryneas/loggedPDO. I might have modified it a bit, but I remember it would output a list of all queries executed at the end of the page including the execution times. Give it a go. It might help. – Mike Jun 01 '16 at 17:57
  • Meh. I see the code I used isn't too long. This is what I have outputting the queries as a table. I can't vouch for the code quality, but AFAIK it works: http://pastebin.com/fjyqdU6n – Mike Jun 01 '16 at 18:05
  • You may also want to check out: https://xdebug.org/ – Mike Jun 01 '16 at 18:08

0 Answers0