I wouldn't couch it in quite such terms, but we've been having
performance issues too.  Satchmo's method of dealing with custom
product types basically means a lot of extra queries and a lot of in-
code processing that could otherwise be done in the database.

I used Django Debug Toolbar to figure out where the most queries (and
the most duplicate queries) were being run (we were seeing as many as
450 queries on a page listing 4 products).  We ended up forking
Satchmo to cache the output of the most frequently used functions and
methods using django-cache-utils, which cut that number down by better
than a factor of 10.

We also upgraded our server memory and made sure to use a database on
the same physical server (which may not be the best idea in the long
run but certainly cuts down on the round-trip time for those hundreds
of queries).

Mike has some excellent suggestions too, and I'll probably try a
couple of those.  Certainly indexing slugs and using InnoDB over
MyISAM can't hurt.

I've had to make enough customizations at this point that when we next
have to update it I'm inclined to build a custom cart instead of
trying to merge changes, but we'll see what happens.


On Jul 28, 10:11 am, Bobby Roberts <[email protected]> wrote:
> satchmo has become a bloated manatee of a codebase.  Does anyone know
> why it run so slowly now?  Or, do you have to feed it treats or
> something secretive to get it running properly?  I've got two satchmo
> sites on a 256mb slice at slicehost and they are pretty much unusable
> at the moment.

-- 
You received this message because you are subscribed to the Google Groups 
"Satchmo users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/satchmo-users?hl=en.

Reply via email to