Performance differences between DEV and Production environment MYSQL server











up vote
0
down vote

favorite












I'm building an app with Laravel 5.6 and VueJS requesting data from an API on the Laravel backend. In my DEV environment the queries take no time at all, but in the Production environment the response on the API takes 85.7 seconds opposed to 0.1 seconds in the DEV environment. Data is in both environments the same.



Using the follwoing commands in my Controller I was able to get the exact queries that run and I can test them one by one:



DB::enableQueryLog();

// then my eloquent stuff
$query = Sportevent::whereHas('photos')->with('photos');
if($request->input('year')){
$year = $request->input('year');
$query = $query->where('date','like', $year.'%');
}
if($request->input('country')){
$country = $request->input('country');
$query = $query->where('country',$country);
}
$sportevents = $query->orderBy('date',"DESC")->paginate(10);

// then I display the queries:
dd(DB::getQueryLog());


Here are the queries that are produced, not having selected a year or a country, incl performance in both environments with time:



// --------------------------------------------------------------
// DEV: 0.0208 seconds | PROD: 73 seconds (had to use stopwatch)
// --------------------------------------------------------------
select count(*) as aggregate from `events` where exists
(select * from `photos` where `events`.`id` = `photos`.`eventID`
and `active` = 1)

// ------------------------------------------
// DEV: 0.025 seconds | PROD: 38.9721 seconds
// ------------------------------------------
select * from `events` where exists (select * from `photos` where
`events`.`id` = `photos`.`eventID` and `active` = 1)
order by `date` desc limit 10 offset 0

// ------------------------------------------
// DEV: 0.0112 seconds | PROD: 0.0141 seconds
// ------------------------------------------
select * from `photos` where `active` = 1 and `photos`.`eventID` in
(11194, 11087, 10506, 10797, 9910, 10118, 10212, 9655, 10047, 10049)


The table events contains about 6000 entries and photos less than 50000 entries. If you need further details when it comes to table structure, let me know before down voting in the comments section :-)



On the production server are many other applications running with Laravel or Wordpress using databases on the same MySQL installation and none of them have similar issues.










share|improve this question






















  • dev and production db are different? If yes make sure indexes are present on production also.
    – Web Artisan
    Nov 20 at 7:21










  • It's all identical, there are no indexes apart from id as primary key defined on both tables.
    – Edwin Krause
    Nov 20 at 7:29










  • May be your production server db engine configuration is much lower than your dev environment. Try to contact your hosting provider.
    – Web Artisan
    Nov 20 at 7:34












  • It's on a VPS... So I should be the master of my MySQL server
    – Edwin Krause
    Nov 20 at 7:41






  • 2




    I just added an index on column photos.eventID that seems to do the trick. Fast as a rocket now... : 0.4 seconds for the API to respond
    – Edwin Krause
    Nov 20 at 7:45

















up vote
0
down vote

favorite












I'm building an app with Laravel 5.6 and VueJS requesting data from an API on the Laravel backend. In my DEV environment the queries take no time at all, but in the Production environment the response on the API takes 85.7 seconds opposed to 0.1 seconds in the DEV environment. Data is in both environments the same.



Using the follwoing commands in my Controller I was able to get the exact queries that run and I can test them one by one:



DB::enableQueryLog();

// then my eloquent stuff
$query = Sportevent::whereHas('photos')->with('photos');
if($request->input('year')){
$year = $request->input('year');
$query = $query->where('date','like', $year.'%');
}
if($request->input('country')){
$country = $request->input('country');
$query = $query->where('country',$country);
}
$sportevents = $query->orderBy('date',"DESC")->paginate(10);

// then I display the queries:
dd(DB::getQueryLog());


Here are the queries that are produced, not having selected a year or a country, incl performance in both environments with time:



// --------------------------------------------------------------
// DEV: 0.0208 seconds | PROD: 73 seconds (had to use stopwatch)
// --------------------------------------------------------------
select count(*) as aggregate from `events` where exists
(select * from `photos` where `events`.`id` = `photos`.`eventID`
and `active` = 1)

// ------------------------------------------
// DEV: 0.025 seconds | PROD: 38.9721 seconds
// ------------------------------------------
select * from `events` where exists (select * from `photos` where
`events`.`id` = `photos`.`eventID` and `active` = 1)
order by `date` desc limit 10 offset 0

// ------------------------------------------
// DEV: 0.0112 seconds | PROD: 0.0141 seconds
// ------------------------------------------
select * from `photos` where `active` = 1 and `photos`.`eventID` in
(11194, 11087, 10506, 10797, 9910, 10118, 10212, 9655, 10047, 10049)


The table events contains about 6000 entries and photos less than 50000 entries. If you need further details when it comes to table structure, let me know before down voting in the comments section :-)



On the production server are many other applications running with Laravel or Wordpress using databases on the same MySQL installation and none of them have similar issues.










share|improve this question






















  • dev and production db are different? If yes make sure indexes are present on production also.
    – Web Artisan
    Nov 20 at 7:21










  • It's all identical, there are no indexes apart from id as primary key defined on both tables.
    – Edwin Krause
    Nov 20 at 7:29










  • May be your production server db engine configuration is much lower than your dev environment. Try to contact your hosting provider.
    – Web Artisan
    Nov 20 at 7:34












  • It's on a VPS... So I should be the master of my MySQL server
    – Edwin Krause
    Nov 20 at 7:41






  • 2




    I just added an index on column photos.eventID that seems to do the trick. Fast as a rocket now... : 0.4 seconds for the API to respond
    – Edwin Krause
    Nov 20 at 7:45















up vote
0
down vote

favorite









up vote
0
down vote

favorite











I'm building an app with Laravel 5.6 and VueJS requesting data from an API on the Laravel backend. In my DEV environment the queries take no time at all, but in the Production environment the response on the API takes 85.7 seconds opposed to 0.1 seconds in the DEV environment. Data is in both environments the same.



Using the follwoing commands in my Controller I was able to get the exact queries that run and I can test them one by one:



DB::enableQueryLog();

// then my eloquent stuff
$query = Sportevent::whereHas('photos')->with('photos');
if($request->input('year')){
$year = $request->input('year');
$query = $query->where('date','like', $year.'%');
}
if($request->input('country')){
$country = $request->input('country');
$query = $query->where('country',$country);
}
$sportevents = $query->orderBy('date',"DESC")->paginate(10);

// then I display the queries:
dd(DB::getQueryLog());


Here are the queries that are produced, not having selected a year or a country, incl performance in both environments with time:



// --------------------------------------------------------------
// DEV: 0.0208 seconds | PROD: 73 seconds (had to use stopwatch)
// --------------------------------------------------------------
select count(*) as aggregate from `events` where exists
(select * from `photos` where `events`.`id` = `photos`.`eventID`
and `active` = 1)

// ------------------------------------------
// DEV: 0.025 seconds | PROD: 38.9721 seconds
// ------------------------------------------
select * from `events` where exists (select * from `photos` where
`events`.`id` = `photos`.`eventID` and `active` = 1)
order by `date` desc limit 10 offset 0

// ------------------------------------------
// DEV: 0.0112 seconds | PROD: 0.0141 seconds
// ------------------------------------------
select * from `photos` where `active` = 1 and `photos`.`eventID` in
(11194, 11087, 10506, 10797, 9910, 10118, 10212, 9655, 10047, 10049)


The table events contains about 6000 entries and photos less than 50000 entries. If you need further details when it comes to table structure, let me know before down voting in the comments section :-)



On the production server are many other applications running with Laravel or Wordpress using databases on the same MySQL installation and none of them have similar issues.










share|improve this question













I'm building an app with Laravel 5.6 and VueJS requesting data from an API on the Laravel backend. In my DEV environment the queries take no time at all, but in the Production environment the response on the API takes 85.7 seconds opposed to 0.1 seconds in the DEV environment. Data is in both environments the same.



Using the follwoing commands in my Controller I was able to get the exact queries that run and I can test them one by one:



DB::enableQueryLog();

// then my eloquent stuff
$query = Sportevent::whereHas('photos')->with('photos');
if($request->input('year')){
$year = $request->input('year');
$query = $query->where('date','like', $year.'%');
}
if($request->input('country')){
$country = $request->input('country');
$query = $query->where('country',$country);
}
$sportevents = $query->orderBy('date',"DESC")->paginate(10);

// then I display the queries:
dd(DB::getQueryLog());


Here are the queries that are produced, not having selected a year or a country, incl performance in both environments with time:



// --------------------------------------------------------------
// DEV: 0.0208 seconds | PROD: 73 seconds (had to use stopwatch)
// --------------------------------------------------------------
select count(*) as aggregate from `events` where exists
(select * from `photos` where `events`.`id` = `photos`.`eventID`
and `active` = 1)

// ------------------------------------------
// DEV: 0.025 seconds | PROD: 38.9721 seconds
// ------------------------------------------
select * from `events` where exists (select * from `photos` where
`events`.`id` = `photos`.`eventID` and `active` = 1)
order by `date` desc limit 10 offset 0

// ------------------------------------------
// DEV: 0.0112 seconds | PROD: 0.0141 seconds
// ------------------------------------------
select * from `photos` where `active` = 1 and `photos`.`eventID` in
(11194, 11087, 10506, 10797, 9910, 10118, 10212, 9655, 10047, 10049)


The table events contains about 6000 entries and photos less than 50000 entries. If you need further details when it comes to table structure, let me know before down voting in the comments section :-)



On the production server are many other applications running with Laravel or Wordpress using databases on the same MySQL installation and none of them have similar issues.







mysql laravel-5 phpmyadmin eloquent






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 20 at 7:09









Edwin Krause

1,08311021




1,08311021












  • dev and production db are different? If yes make sure indexes are present on production also.
    – Web Artisan
    Nov 20 at 7:21










  • It's all identical, there are no indexes apart from id as primary key defined on both tables.
    – Edwin Krause
    Nov 20 at 7:29










  • May be your production server db engine configuration is much lower than your dev environment. Try to contact your hosting provider.
    – Web Artisan
    Nov 20 at 7:34












  • It's on a VPS... So I should be the master of my MySQL server
    – Edwin Krause
    Nov 20 at 7:41






  • 2




    I just added an index on column photos.eventID that seems to do the trick. Fast as a rocket now... : 0.4 seconds for the API to respond
    – Edwin Krause
    Nov 20 at 7:45




















  • dev and production db are different? If yes make sure indexes are present on production also.
    – Web Artisan
    Nov 20 at 7:21










  • It's all identical, there are no indexes apart from id as primary key defined on both tables.
    – Edwin Krause
    Nov 20 at 7:29










  • May be your production server db engine configuration is much lower than your dev environment. Try to contact your hosting provider.
    – Web Artisan
    Nov 20 at 7:34












  • It's on a VPS... So I should be the master of my MySQL server
    – Edwin Krause
    Nov 20 at 7:41






  • 2




    I just added an index on column photos.eventID that seems to do the trick. Fast as a rocket now... : 0.4 seconds for the API to respond
    – Edwin Krause
    Nov 20 at 7:45


















dev and production db are different? If yes make sure indexes are present on production also.
– Web Artisan
Nov 20 at 7:21




dev and production db are different? If yes make sure indexes are present on production also.
– Web Artisan
Nov 20 at 7:21












It's all identical, there are no indexes apart from id as primary key defined on both tables.
– Edwin Krause
Nov 20 at 7:29




It's all identical, there are no indexes apart from id as primary key defined on both tables.
– Edwin Krause
Nov 20 at 7:29












May be your production server db engine configuration is much lower than your dev environment. Try to contact your hosting provider.
– Web Artisan
Nov 20 at 7:34






May be your production server db engine configuration is much lower than your dev environment. Try to contact your hosting provider.
– Web Artisan
Nov 20 at 7:34














It's on a VPS... So I should be the master of my MySQL server
– Edwin Krause
Nov 20 at 7:41




It's on a VPS... So I should be the master of my MySQL server
– Edwin Krause
Nov 20 at 7:41




2




2




I just added an index on column photos.eventID that seems to do the trick. Fast as a rocket now... : 0.4 seconds for the API to respond
– Edwin Krause
Nov 20 at 7:45






I just added an index on column photos.eventID that seems to do the trick. Fast as a rocket now... : 0.4 seconds for the API to respond
– Edwin Krause
Nov 20 at 7:45














1 Answer
1






active

oldest

votes

















up vote
0
down vote



accepted










Although the first two queries don't output much they have to go through the most data and therefore seem to be very memory and/or CPU intense queries.



It appears that my DEV environment has more power than my production environment and therefore I had this huge differences.



The solution at the end was simple: I added an INDEX of type INDEX to the column photos.eventID which would have been a good idea anyway.



This little change made my API respond in 0.4 seconds instead of 85.7






share|improve this answer





















  • Tip for the future, EXPLAIN on both DEV and PROD would have clearly identified the missing index on PROD.
    – Wilson Hauck
    Nov 24 at 20:33










  • Thanks, I just need to figure out how to use that command :-)
    – Edwin Krause
    Nov 26 at 7:20










  • @kevinkrause For initial research in Google search for 'mysql explain tutorial' You will find it is truly EASY, precede your SELECT xxxxx with EXPLAIN - give it a shot, learn how to interpret the results, you will be amazed.
    – Wilson Hauck
    Nov 26 at 8:25










  • Thanks, but sorry I don't use google anymore... I couldn't get around the documentation on dev.mysql.com/doc/refman/8.0/en/explain.html , that's why I was asking for a quick pointer....
    – Edwin Krause
    Nov 26 at 10:10










  • Alternatives to google include bing.com or yahoo.com - wherever you search for things on the web will work. This is the quickest pointer I know. Have you tried what I suggested? EXPLAIN before SELECT ..... for your introduction.
    – Wilson Hauck
    Nov 26 at 12:34











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53387911%2fperformance-differences-between-dev-and-production-environment-mysql-server%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
0
down vote



accepted










Although the first two queries don't output much they have to go through the most data and therefore seem to be very memory and/or CPU intense queries.



It appears that my DEV environment has more power than my production environment and therefore I had this huge differences.



The solution at the end was simple: I added an INDEX of type INDEX to the column photos.eventID which would have been a good idea anyway.



This little change made my API respond in 0.4 seconds instead of 85.7






share|improve this answer





















  • Tip for the future, EXPLAIN on both DEV and PROD would have clearly identified the missing index on PROD.
    – Wilson Hauck
    Nov 24 at 20:33










  • Thanks, I just need to figure out how to use that command :-)
    – Edwin Krause
    Nov 26 at 7:20










  • @kevinkrause For initial research in Google search for 'mysql explain tutorial' You will find it is truly EASY, precede your SELECT xxxxx with EXPLAIN - give it a shot, learn how to interpret the results, you will be amazed.
    – Wilson Hauck
    Nov 26 at 8:25










  • Thanks, but sorry I don't use google anymore... I couldn't get around the documentation on dev.mysql.com/doc/refman/8.0/en/explain.html , that's why I was asking for a quick pointer....
    – Edwin Krause
    Nov 26 at 10:10










  • Alternatives to google include bing.com or yahoo.com - wherever you search for things on the web will work. This is the quickest pointer I know. Have you tried what I suggested? EXPLAIN before SELECT ..... for your introduction.
    – Wilson Hauck
    Nov 26 at 12:34















up vote
0
down vote



accepted










Although the first two queries don't output much they have to go through the most data and therefore seem to be very memory and/or CPU intense queries.



It appears that my DEV environment has more power than my production environment and therefore I had this huge differences.



The solution at the end was simple: I added an INDEX of type INDEX to the column photos.eventID which would have been a good idea anyway.



This little change made my API respond in 0.4 seconds instead of 85.7






share|improve this answer





















  • Tip for the future, EXPLAIN on both DEV and PROD would have clearly identified the missing index on PROD.
    – Wilson Hauck
    Nov 24 at 20:33










  • Thanks, I just need to figure out how to use that command :-)
    – Edwin Krause
    Nov 26 at 7:20










  • @kevinkrause For initial research in Google search for 'mysql explain tutorial' You will find it is truly EASY, precede your SELECT xxxxx with EXPLAIN - give it a shot, learn how to interpret the results, you will be amazed.
    – Wilson Hauck
    Nov 26 at 8:25










  • Thanks, but sorry I don't use google anymore... I couldn't get around the documentation on dev.mysql.com/doc/refman/8.0/en/explain.html , that's why I was asking for a quick pointer....
    – Edwin Krause
    Nov 26 at 10:10










  • Alternatives to google include bing.com or yahoo.com - wherever you search for things on the web will work. This is the quickest pointer I know. Have you tried what I suggested? EXPLAIN before SELECT ..... for your introduction.
    – Wilson Hauck
    Nov 26 at 12:34













up vote
0
down vote



accepted







up vote
0
down vote



accepted






Although the first two queries don't output much they have to go through the most data and therefore seem to be very memory and/or CPU intense queries.



It appears that my DEV environment has more power than my production environment and therefore I had this huge differences.



The solution at the end was simple: I added an INDEX of type INDEX to the column photos.eventID which would have been a good idea anyway.



This little change made my API respond in 0.4 seconds instead of 85.7






share|improve this answer












Although the first two queries don't output much they have to go through the most data and therefore seem to be very memory and/or CPU intense queries.



It appears that my DEV environment has more power than my production environment and therefore I had this huge differences.



The solution at the end was simple: I added an INDEX of type INDEX to the column photos.eventID which would have been a good idea anyway.



This little change made my API respond in 0.4 seconds instead of 85.7







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 20 at 8:22









Edwin Krause

1,08311021




1,08311021












  • Tip for the future, EXPLAIN on both DEV and PROD would have clearly identified the missing index on PROD.
    – Wilson Hauck
    Nov 24 at 20:33










  • Thanks, I just need to figure out how to use that command :-)
    – Edwin Krause
    Nov 26 at 7:20










  • @kevinkrause For initial research in Google search for 'mysql explain tutorial' You will find it is truly EASY, precede your SELECT xxxxx with EXPLAIN - give it a shot, learn how to interpret the results, you will be amazed.
    – Wilson Hauck
    Nov 26 at 8:25










  • Thanks, but sorry I don't use google anymore... I couldn't get around the documentation on dev.mysql.com/doc/refman/8.0/en/explain.html , that's why I was asking for a quick pointer....
    – Edwin Krause
    Nov 26 at 10:10










  • Alternatives to google include bing.com or yahoo.com - wherever you search for things on the web will work. This is the quickest pointer I know. Have you tried what I suggested? EXPLAIN before SELECT ..... for your introduction.
    – Wilson Hauck
    Nov 26 at 12:34


















  • Tip for the future, EXPLAIN on both DEV and PROD would have clearly identified the missing index on PROD.
    – Wilson Hauck
    Nov 24 at 20:33










  • Thanks, I just need to figure out how to use that command :-)
    – Edwin Krause
    Nov 26 at 7:20










  • @kevinkrause For initial research in Google search for 'mysql explain tutorial' You will find it is truly EASY, precede your SELECT xxxxx with EXPLAIN - give it a shot, learn how to interpret the results, you will be amazed.
    – Wilson Hauck
    Nov 26 at 8:25










  • Thanks, but sorry I don't use google anymore... I couldn't get around the documentation on dev.mysql.com/doc/refman/8.0/en/explain.html , that's why I was asking for a quick pointer....
    – Edwin Krause
    Nov 26 at 10:10










  • Alternatives to google include bing.com or yahoo.com - wherever you search for things on the web will work. This is the quickest pointer I know. Have you tried what I suggested? EXPLAIN before SELECT ..... for your introduction.
    – Wilson Hauck
    Nov 26 at 12:34
















Tip for the future, EXPLAIN on both DEV and PROD would have clearly identified the missing index on PROD.
– Wilson Hauck
Nov 24 at 20:33




Tip for the future, EXPLAIN on both DEV and PROD would have clearly identified the missing index on PROD.
– Wilson Hauck
Nov 24 at 20:33












Thanks, I just need to figure out how to use that command :-)
– Edwin Krause
Nov 26 at 7:20




Thanks, I just need to figure out how to use that command :-)
– Edwin Krause
Nov 26 at 7:20












@kevinkrause For initial research in Google search for 'mysql explain tutorial' You will find it is truly EASY, precede your SELECT xxxxx with EXPLAIN - give it a shot, learn how to interpret the results, you will be amazed.
– Wilson Hauck
Nov 26 at 8:25




@kevinkrause For initial research in Google search for 'mysql explain tutorial' You will find it is truly EASY, precede your SELECT xxxxx with EXPLAIN - give it a shot, learn how to interpret the results, you will be amazed.
– Wilson Hauck
Nov 26 at 8:25












Thanks, but sorry I don't use google anymore... I couldn't get around the documentation on dev.mysql.com/doc/refman/8.0/en/explain.html , that's why I was asking for a quick pointer....
– Edwin Krause
Nov 26 at 10:10




Thanks, but sorry I don't use google anymore... I couldn't get around the documentation on dev.mysql.com/doc/refman/8.0/en/explain.html , that's why I was asking for a quick pointer....
– Edwin Krause
Nov 26 at 10:10












Alternatives to google include bing.com or yahoo.com - wherever you search for things on the web will work. This is the quickest pointer I know. Have you tried what I suggested? EXPLAIN before SELECT ..... for your introduction.
– Wilson Hauck
Nov 26 at 12:34




Alternatives to google include bing.com or yahoo.com - wherever you search for things on the web will work. This is the quickest pointer I know. Have you tried what I suggested? EXPLAIN before SELECT ..... for your introduction.
– Wilson Hauck
Nov 26 at 12:34


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53387911%2fperformance-differences-between-dev-and-production-environment-mysql-server%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

404 Error Contact Form 7 ajax form submitting

How to know if a Active Directory user can login interactively

Refactoring coordinates for Minecraft Pi buildings written in Python