Admin Area Sloooooooowwwww

[jrafuse]

I've searched everywher, and the only messages related to my problem are in the Archive areas, where I cannot post, or reply, or add anything, so I'm havint to start this thread here.

I am currently running v1.3.0.1 and up until 2-3 days ago (after our most recent "sale" started on Saturday), the Admin Area of Zencart has slowed down to a crawl. The User side (the store) is working like a charm, and is really fast, but the Admin area is almost worse than 'dialup'. I have Category Counts disabled (the only thing I could find to this point as a suggestion), but even the summary front page for the Admin area now takes 25secs to display, where it use to take a max of 2secs. I have even re-compiled my Apache server twice ( the second time upgrading to MySQL 4.1.19, and PHP 5.14 , and nothig has changed ...

The store is running like DynoMite! , but the Admin Area is frustrating me completely. My hosting service has no ideas on this one.

Anyone???

[Kim]

Are you running the Admin as SSL? How many products and categories?

[jrafuse]

Are you running the Admin as SSL? How many products and categories?

I am not running the admin as SSL. I have about 52 categories including sub-categories, and about 3000 products, some disabled right now.

As I said the store is gold ... just the backend is suddenly dialup ... and no ... I didn't change anything in the configs, or the server ... this happened in the middle of a 3-day sale promo, and I wasn't going to do anything in the middle of that :)

John

[jrafuse]

Just an update here ....

Everything is back to normal again as of last night about midnight. The ONLY thing I did last night was clear out the Admin log about a 30 minutes or so prior to this. Aft a half-hour suddenly everything is working like a fine-tuned Ferrari again. Yes, that is how I think of ZenCart !

I don't know if the log clearout had anything to do with it, but I know I hadn't cleared it out since before the upgrade to 1.3.0.1, so I figured after the sale that it was time ... go figure.

If anyone has any clues as to why, and if, this had anything to do with the Admin slowness I would appreciate it!

John

[Reesy]

The admin log file is everything to do with it.
If its too big it will slow your admin down.
In 1.3.0.2 there is some code that checks if its too big or if you havent cleared it for some time and prompts you to clear it.
Cool eh

[DrByte]

Well, technically the admin activity log shouldn't have much of an impact, as there is no attempt to retrieve records from it ... only to insert user-tracking data for audit-trail purposes. While inserts can be slow if there are a lot of indexes on a given table, this is a very simple table, and inserts should be very fast.
However, given that flushing the table has concurrently met with improved speed, it's difficult to rule one way or the other.
Certainly, size was one reason for the alert being added. This is the first I've noticed that this table might be related to a performance problem.

John said that he "cleared out" the log. This suggests a truncate, rather than a drop and recreate, so it doesn't sound as though the table structure or index settings were the culprit, but rather, if this table was the cause, then it would have to be sheer size leading to the symptoms.

"Hmmmmmm......."

[jrafuse]

Well, technically the admin activity log shouldn't have much of an impact, as there is no attempt to retrieve records from it ... only to insert user-tracking data for audit-trail purposes. While inserts can be slow if there are a lot of indexes on a given table, this is a very simple table, and inserts should be very fast.
However, given that flushing the table has concurrently met with improved speed, it's difficult to rule one way or the other.
Certainly, size was one reason for the alert being added. This is the first I've noticed that this table might be related to a performance problem.

John said that he "cleared out" the log. This suggests a truncate, rather than a drop and recreate, so it doesn't sound as though the table structure or index settings were the culprit, but rather, if this table was the cause, then it would have to be sheer size leading to the symptoms.

"Hmmmmmm......."

I simply used the Admin option to clear the log. There was no warning issued from ZenCart that it was getting to the stated limits, but I just thought that since it hadn't been cleared out since before the upgrade, and we had just had a massive sale, that it was a good idea to do so.
Whether that had anything to do with the speedup of the Admin section, I can't even begin to guess. However, it was the ONLY thing which I did between the time that I last noted the slowness by running a sales report for the day, and when I re-ran it after doing the clear-out. It is probably like you say, a co-inkydink, but since it was the only action I took before it cleared up, I mentioned it :)

John

[DrByte]

Great! Thanks for clarifying.