Jump to content

[SOLVED] Backoffice very slow ...

bloggus
 Share

Recommended Posts

bloggus Contributor

bloggus

Posted
Posted (edited)

I tried 1.5.5 and 1.5.6 and I get a very slow back office. New installation. Front office is fine.

 

I change the setting for debugging and get huge times for initContent - what is that for the BO? What should I check?

 

Same parameter for the FO is fine, but huge time in BO ...

 

 

 

Load time: 15.205s
You'd better run your shop on a toaster

  • config: 80ms
  • constructor: 0ms
  • init: 10ms
  • checkAccess: 0ms
  • setMedia: 2ms
  • postProcess: 0ms
  • initHeader: 5ms
  • initContent: 15.101s
  • initFooter: 0ms
  • display: 7ms
Edited by bloggus (see edit history)
Link to comment
Share on other sites
fcosta Newbie

fcosta

Posted
Posted (edited)

I have the same issue.

 

The BO from my 1.4.x stores have a decent performance. But the BO from several new 1.5.6 installations is very slow, 40s on average. The only fast page is the "Advanced Parameters > Performance"! (try it, it should be the same for you).

 

I also had a 1.5.4 installation with a good performance on the BO, but after upgrade to 1.5.6 it went slow.

 

So this must be a real issue on 1.5.6.

 

Any suggestions ? 

Edited by fcosta (see edit history)
Link to comment
Share on other sites
fcosta Newbie

fcosta

Posted
Posted

---------------

One curious test that I made was...

comparing the query time made from Prestashop (by activating the debug_profiling and dev_mode )  to making the same query on my mySQL server with PhpmyAdmin.

 

The difference is huge!... any idea why ?

on Prestashop 15.403 ms 

Query :SELECT SQL_NO_CACHE h.`name` as hook, m.`id_module`, h.`id_hook`, m.`name` as module, h.`live_edit` FROM `ps_module` m INNER JOIN `ps_hook_module` hm ON hm.`id_module` = m.`id_module` INNER JOIN `ps_hook` h ON hm.`id_hook` = h.`id_hook` WHERE ((SELECT COUNT(*) FROM ps_module_shop ms WHERE ms.id_module = m.id_module AND ms.id_shop IN (1)) = 1) AND (h.name != "displayPayment") AND (hm.id_shop = 1) ORDER BY hm.`position`
in /home/pouparen/public_html/estore/classes/Hook.php:334
 
on PHPmySQL
1,6ms : Showing rows 0 - 29 ( 212 total, Query took 0.0016 sec)
 
Query (without Order by): SELECT SQL_NO_CACHE h.`name` as hook, m.`id_module`, h.`id_hook`, m.`name` as module, h.`live_edit` FROM `ps_module` m INNER JOIN `ps_hook_module` hm ON hm.`id_module` = m.`id_module` INNER JOIN `ps_hook` h ON hm.`id_hook` = h.`id_hook` WHERE ((SELECT COUNT(*) FROM ps_module_shop ms WHERE ms.id_module = m.id_module AND ms.id_shop IN (1)) = 1) AND (h.name != "displayPayment") AND (hm.id_shop = 1) 
Link to comment
Share on other sites
bloggus Contributor

bloggus

Posted
  • Author
Posted (edited)

I actually found the problem in my installation.

 

Upon installation of Prestashop, there are some XML-files downloaded from (api.prestashop.com or/and api.addons.prestashop.com). Those are put into config/xml-folder. Also with that there are some tables created. I had no xml-files and only 236 tables instead of 244.

 

On the managed VPS I'm runing they are strict with the security and most of downloads from other domains are blocked.

 

Once I opened the two domains to prestashop API on the server, did a new installation, the files were downloaded, right tables created, my BO is fast as the flash! :)  No more problems for me.

 

Maybe it helps some people here ... check if you have the XML-files in canfig/xml, there should not be empty and amount of tables in the database.

Edited by bloggus (see edit history)
Link to comment
Share on other sites
fcosta Newbie

fcosta

Posted
Posted (edited)

Hi Bloggus, 

 

I'm running it on a Cpanel/Whm account, and I think I have the same security issue.

 

 

NOTE: I just checked in WHM and ... "You do not have access to ConfigServer Firewall."

 

 What shell I do, is there a way to open it on cpanel ? to open these two url (api.prestashop.com or/and api.addons.prestashop.com) ?

 

cheers,

Edited by fcosta (see edit history)
Link to comment
Share on other sites
Dallerdkj Newbie

Dallerdkj

Posted
Posted
Could i just put these files in my windows/host file? I have read about this is a solution, but dunno where to call it

 

91.240.109.42 -> prestashop.com

91.240.109.21 -> api.prestashop.com

91.240.109.40 -> addons.prestashop.com

91.240.109.26 -> translations.prestashop.com

Link to comment
Share on other sites
bloggus Contributor

bloggus

Posted
  • Author
Posted (edited)

fcosta,

 

sorry can't help you there. Runing a managed VPS, so just email the staff and they do the change.

 

 

 

Danielkjadaller,

 

not sure. You could do a new installation somewhere else, transfer the XML-files from there and also take a look at the database tables, to see if you are missing any. Not really qualified to help you in terms of a guide, since I noticed it during a test manual upgrade from 1.4.x to 1.5.6 .

Edited by bloggus (see edit history)
Link to comment
Share on other sites
  • 1 month later...
  • 5 months later...
  • 2 weeks later...
tothzoltan01 Newbie

tothzoltan01

Posted
Posted

Hi,

I had the same problem with th slow BO. I dont know what causes that isuue, it's strange that some files were changed in folder config/xml/ heaving no content, 0 size. My solution was (I'm not a programmer and will never be) to overwrite those empty xml files with good ones from an other installation. By reloading the BO, voila... :) Site is www.jucariiplastic.ro.

  • Like 1
Link to comment
Share on other sites
  • 3 months later...
  • 6 months later...
  • 6 months later...
  • 2 weeks later...
endohaus Newbie

endohaus

Posted
Posted

Just checked today with dig tool:

91.240.109.42 -> prestashop.com
91.240.109.21 -> api.prestashop.com
91.240.109.53 -> addons.prestashop.com
91.240.109.26 -> translations.prestashop.com
 
 
But, as I understand, most people are concerned about Prestashop Core making calls to the Prestashop servers, which is for sure not PCI compliant thing.
I tried to block all outgoing connections to 91.240.109.0/24 subnet, and my admin panel takes about 11.5 seconds to load, with initContent - 10356 ms
 
That is not right! We need to have some options to block these weird outbound calls that happen on each page load in admin panel!
Link to comment
Share on other sites
endohaus Newbie

endohaus

Posted
Posted

Is is good to delete xml files from /config/xml/ folder? Will it not affect indexing by search engines?

you can delete everything in that folder, and on next admin page load the Prestashop Core will recreate needed files again. Make sure the xml folder is writable by your Web Server user, such as www-data.

 

Many people have slow loading times in their backend, because on linux systems there is no proper permission set on xml folder, so Prestashop Core tries to save files in the xml folder, but can't. So, that is one of very slow load times in backend. Hope it helps.

Link to comment
Share on other sites
  • 3 weeks later...
aron22 Newbie

aron22

Posted
Posted

Hi Guys, I am having the same problem with my BO. Unable to do anything as it takes so much time. 

 

Load time: 15428 ms

 

initContent 15035

SELECT SQL_NO_CACHE h.`name` as hook, m.`id_module`, h.`id_hook`, m.`name` as module, h.`live_edit`
FROM `ps_module` m
INNER JOIN ps_module_shop module_shop
ON (module_shop.id_module = m.id_module AND module_shop.id_shop = 1 AND module_shop.enable_device & 1)
INNER JOIN `ps_module_shop` ms ON ms.`id_module` = m.`id_module`
INNER JOIN `ps_hook_module` hm ON hm.`id_module` = m.`id_module`
INNER JOIN `ps_hook` h ON hm.`id_hook` = h.`id_hook`
WHERE (h.name != "displayPayment") AND (hm.id_shop = 1)
GROUP BY hm.id_hook, hm.id_module
ORDER BY hm.`position`

 

12.1 ms 

 

I did delete all the files from config/xml folder and reloaded the back office but no luck. 

 

Can someone help please?

Link to comment
Share on other sites
goldhub Newbie

goldhub

Posted
Posted (edited)

Hi Guys, I am having the same problem with my BO. Unable to do anything as it takes so much time. 

 

Load time: 15428 ms

 

initContent 15035

SELECT SQL_NO_CACHE h.`name` as hook, m.`id_module`, h.`id_hook`, m.`name` as module, h.`live_edit`

FROM `ps_module` m

INNER JOIN ps_module_shop module_shop

ON (module_shop.id_module = m.id_module AND module_shop.id_shop = 1 AND module_shop.enable_device & 1)

INNER JOIN `ps_module_shop` ms ON ms.`id_module` = m.`id_module`

INNER JOIN `ps_hook_module` hm ON hm.`id_module` = m.`id_module`

INNER JOIN `ps_hook` h ON hm.`id_hook` = h.`id_hook`

WHERE (h.name != "displayPayment") AND (hm.id_shop = 1)

GROUP BY hm.id_hook, hm.id_module

ORDER BY hm.`position`

 

12.1 ms 

 

I did delete all the files from config/xml folder and reloaded the back office but no luck. 

 

Can someone help please?

 

From my experience working with Prestashop under Linux/Unix compatible system is as follows:

1) make sure your read/write permissions are set to 775 on folders, and 664 on .xml files ../your_ps_store_root/config/xml

2) Turn on Debug mode in ../your_ps_store_root/config/defines.inc.php line 29 - define('_PS_MODE_DEV_', false); > define('_PS_MODE_DEV_', true);

3) with Debug on you will be able to see what is slowing down your load time. Prestashop makes calls to their dev servers for statistics or something... Blocking the outgoing connections to prestashop servers does not help, but instead worsens the situation. The load times are about 15 seconds a page in backoffice. Best bet would be to fork the code @github and rip off all the crap code they put into it!

 

If you cannot solve the load time issue after me pointing out... post your screenshots with debug info, basic server setup specs, or just copy-paste debug output. Will do my best to help you out, bud!

 

P.S. Tried Magento - got close to mental hospital,.. tried CS-Cart - got ripped off,.. tried WooCommerce - Got sick of Wordpress bloat,.. tried Open Cart, Joomla, you name it... - all BS, BWT... Prestashop - ohhhh, not the perfect but free, and easy to work with... finally fell in love with it,.. coding with please till 6 am every night :)

 

Good luck!

Edited by goldhub (see edit history)
Link to comment
Share on other sites
aron22 Newbie

aron22

Posted
Posted

Great thanks mate.. Really appreciate your help. 

 

1. All my folders have permission 775 and files have 664 and It has been always the case and I never changed those permissions before.

 

2. Turned on debug mode and I can see it takes so much time to execute certain things but not sure where to find information regarding  " outgoing connections to prestashop servers" - could you please let me know how can i find this information? Sorry mate I am not very technical so excuse my naivety.. 

 

I couldn't paste my screenshots here either so I will inbox you the screenshots.  Thanks very much..

Link to comment
Share on other sites
goldhub Newbie

goldhub

Posted
Posted

Great thanks mate.. Really appreciate your help. 

 

1. All my folders have permission 775 and files have 664 and It has been always the case and I never changed those permissions before.

 

2. Turned on debug mode and I can see it takes so much time to execute certain things but not sure where to find information regarding  " outgoing connections to prestashop servers" - could you please let me know how can i find this information? Sorry mate I am not very technical so excuse my naivety.. 

 

I couldn't paste my screenshots here either so I will inbox you the screenshots.  Thanks very much..

 

The "outgoing connections to prestashop servers" stuff is hardcoded into the code.

Link to comment
Share on other sites
aron22 Newbie

aron22

Posted
Posted

After multiple attempt, I finally figured out what was causing the issue in my back office. I should have tried this first but better late than never.. 

 

I contacted my hosting and they informed that they have an automated scanning cron which disables port 80/443 of a user, when the user account has malicious file(s). Also, it disables all such file(s) with immutable attribute and null permission to avoid further infection. 

 

They advised which files they think as malicious and guess what turns out to be one of the prestashop modules. Luckily I wasn't using that module so i was able to delete it without any issue. 

 

I then unblocked the port 80 using cpanel and now back office works without any issue.. 

 

Hope this might help someone. 

Link to comment
Share on other sites
  • 1 month later...
  • 8 months later...
  • 3 months later...
 Share
Go to topic listing
×
×
  • Create New...