Admin login page loads very slow.

[OldNGrey]

Here is another instance of 155 admin login pages and all other admin pages being slow to load.
Production is a new build of ZC155a with the data base migrated from 1.3.9h.

In production:
Admin takes 60.57 seconds to log on and takes 60 secs + to load any page in admin eg Profiles 60.25s; Coupon Admin 61.02s; Customer 60.79s
whereas the response for a customer using the catalog is : view a special produc 0.52s; login screen 3.36s; logging in 0.91s; search on random part number 0.72s

It is as if something is being called in admin and then times out after 60 seconds.

There are no ZC error logs entries.
ZC internal error logging is set to false.

Environment:
ZC155a
Apache 2.4
Server OS Linux 3.13.0
PHP 5.5.9-1
MySQL 5.6.33

[OldNGrey]

Here is an update Monday 3 October 2016 9:04PM AEST (GNT +10). During diagnosis testing both my test installation ( Windows local server) and the Linux production server came alive!

Production response times are now:
Admin log on 1.15s; Profiles 1.00s; Coupon Admin 1.31s; Customer 1.93s.

What external dependencies are there in ZC Admin where it is waiting for a response from an external server or trying to download something?

[carlwhat]

check the network tab in your browser's developer tools. it will tell you what is getting loaded and where your slowdown is... if it exists.

[OldNGrey]

The network tab only lists the main page sent to the browser and not the server side page includes.

The issue turned out to be the calls to Zen Cart and OzPost websites that occur in the header, The header is resent for every page and action. Slow response from the called servers resulted in the slowness of the pages. OzPost version check every page can be turned off in the Shipping \ OzPost module itself. The Zen Cart check on every page can be turned off in admin\includes\local\skip_version_check.ini.

I know what version is being used so there is no need for a check to be made on every page load - once a day would be sufficient.

[RodG]

The issue turned out to be the calls to Zen Cart and OzPost websites that occur in the header, The header is resent for every page and action. Slow response from the called servers resulted in the slowness of the pages.

I would like to add that the slowness observed will only occur if there is a problem with the ozpost server, and this is quite a rare occurrence.

OzPost version check every page can be turned off in the Shipping \ OzPost module itself. The Zen Cart check on every page can be turned off in admin\includes\local\skip_version_check.ini.

Correct, but in both instances, when the servers are functioning normally the time it takes for the requests are really quite small (just a few microseconds), so if anyone is having constant slow page loads the problem is likely to be something other than these version checks.

I know what version is being used so there is no need for a check to be made on every page load - once a day would be sufficient.

I do tend to agree with you here, so I'll look into seeing if I can do something to remedy this in the next ozpost update. There are basically two options available.
1) To store the results in a SESSION file, but this may not be suitable because it would depend on when ZenCart creates/destroys its SESSIONS. (Something I'll need to investigate).
2) Store the results in a database table - My concern here is that a DB access can actually be slower than a response from the server(s), which is possibly the reason why the ZenCart devs didn't take this approach.

FWIW, I followed the ZenCart method of version checking for OzPost, which uses the @file($URL) command. I figure that they had good reason (and good success) using this method, the code is simple, quick, and generally reliable. It obviously has a shortcoming if there is a problem with the remote server(s) though. The 'cure' may be worse than the problem.

Perhaps one of the ZenCart dev's would like to step in with a comment?

Cheers
RodG

[DrByte]

The Zen Cart check on every page can be turned off in admin\includes\local\skip_version_check.ini.

a. It's not checked on every page
b. You can also turn it off more easily from within your Admin by going to Configuration->My Store-> Show if version update available


You didn't state where your webserver is located. I wonder if this issue is simply a latency delay with DNS lookups. And if that's the case, certainly turning off the automatic check (which in turn replaces it with a manual check which you can do by clicking the button that appears) is the simplest and ideal fix.

[soki]

I made a new database and import old database data and now its working fast. So the solution is to make a new database.

[soki]

I made a new database and import old database data and now its working fast. So the solution is to make a new database.

sorry it was a bot attack finally

I edit the .htaccess file and block the bot and now admin load fasts