Responsiveness of admin site with over 1,700 products

48 views
Skip to first unread message

bel

unread,
Jun 20, 2012, 6:32:21 PM6/20/12
to satchmo-d...@googlegroups.com
We have a store with over 1,700 products. When navigating to the "Product -> Products" module in the admin site, we get delays of up to 1.5 minutes. The client finds this unacceptable. What should be some avenues we should look at for addressing this?

Dave Brown

unread,
Jun 20, 2012, 7:48:03 PM6/20/12
to satchmo-d...@googlegroups.com
You need to add more memory to your server, and increase your database buffer size. 
1700 products is nothing - on one of my stores I have 1697 and it loads in 900ms.

Dave

On Wed, Jun 20, 2012 at 6:32 PM, bel <bel...@gmail.com> wrote:
We have a store with over 1,700 products. When navigating to the "Product -> Products" module in the admin site, we get delays of up to 1.5 minutes. The client finds this unacceptable. What should be some avenues we should look at for addressing this?

--
You received this message because you are subscribed to the Google Groups "Satchmo developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/satchmo-developers/-/LXY7LdTNBWwJ.
To post to this group, send email to satchmo-d...@googlegroups.com.
To unsubscribe from this group, send email to satchmo-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/satchmo-developers?hl=en.



--
Dave Brown
CEO/Founder
Rampframe.com - Action Sports Network

Dave Brown

unread,
Jun 20, 2012, 7:49:57 PM6/20/12
to satchmo-d...@googlegroups.com
Just to give you some more info (sorry to make that last email short) - I have a psql shared_buffer size of 512mb.
I also use memcached (not sure if admin is cached if you use the 'cache all pages' middleware for django - but i have 512mb set to that also.
had 2gb total (not a problem) but now run 4gb (i run other stores - much larger - on this server)

Dave

Chris Cauley

unread,
Jun 20, 2012, 8:31:21 PM6/20/12
to satchmo-d...@googlegroups.com

Raw id fields. That's the biggest problem with the admin site. Every place there is a foriegn key to proguct you're executing 1700 queries to populate the drop down. And they are queries in the templating engine!! The templating engine is the weakest link in django and you should avoid putting queries in for loops while in the templating engine. I'm on my cell now but if you're interested just respond and I'll throw up and example first thing tomorrow.

On Jun 20, 2012 5:32 PM, "bel" <bel...@gmail.com> wrote:
We have a store with over 1,700 products. When navigating to the "Product -> Products" module in the admin site, we get delays of up to 1.5 minutes. The client finds this unacceptable. What should be some avenues we should look at for addressing this?

--

Dave Brown

unread,
Jun 20, 2012, 8:37:36 PM6/20/12
to satchmo-d...@googlegroups.com
Chris,
I think he is talking about the products list - not the product detail page - but even that for me loads in under 2 seconds. 

Dave

Chris Cauley

unread,
Jun 21, 2012, 9:59:23 AM6/21/12
to satchmo-d...@googlegroups.com
Ah, it's in the list_view. I missed that part. A news site my company maintains has 16.7k news articles and the list_view loads in under a second. Have you done anything to modify the product admin? Are you somehow filtering these items? You could try nuking the product list_display. In the admin.py file of any app that appears after product in INSTALLED_APPS, try unregistering the product admin, limiting the list_display to the name only, and then re-registering it.

from dajngo.contrib import admin
from product.models import Product
from product.admin import ProductOptions

admin.site.unregister(Product)

class NewProductOptions(ProductOptions):
    list_display = ('name',)
    list_display_links = ('name',)

admin.site.register(Product,NewProductOptions)

I just tested this on my localserver and (with only 300 products in the database) the difference in page load between the two is 2 seconds before and 0.7s after (5 refreshes). I can't see why this would be affected by the number of products in the database, but it clearly makes a difference.

If this works for you try adding items back into list_display one at a time and see what one is causing the problem. I believe "price" and "product subtypes" are the only thing that could be causing a problem.

Good luck,
Chris Cauley

bel

unread,
Jun 21, 2012, 6:35:01 PM6/21/12
to satchmo-d...@googlegroups.com
Yes it was the product list. Apparently, the subtype field was what was causing the majority of the delay (we have configurable products with about 10-20 variations each).

Thanks to chriscauley suggestion, I limited list_display to ('sku', 'name') and that increased the query time went from 2457ms to 54ms.

Now I want to limit the queryset only to products with subtype ConfigurableProduct. Would that help since most of my products are variations? And how would I do this?

Also looking at MySQL optimization. If anyone has any advice there, I'd be appreciative.
Chris Cauley

To post to this group, send email to satchmo-developers@googlegroups.com.
To unsubscribe from this group, send email to satchmo-developers+unsub...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/satchmo-developers?hl=en.

--
You received this message because you are subscribed to the Google Groups "Satchmo developers" group.
To post to this group, send email to satchmo-developers@googlegroups.com.
To unsubscribe from this group, send email to satchmo-developers+unsub...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/satchmo-developers?hl=en.
--
Dave Brown
CEO/Founder
Rampframe.com - Action Sports Network

--
You received this message because you are subscribed to the Google Groups "Satchmo developers" group.
To post to this group, send email to satchmo-developers@googlegroups.com.
To unsubscribe from this group, send email to satchmo-developers+unsub...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages