Kryptronic Software Support Forum

EagleWolf,02/07/2005 03:23:56 PM wrote:

Make sure that you are running the cart using mysql, and that you have mysql tuned.

Yes I have convert my database to mysql but the cp-app.cgi still eat the cpu.

What do you mean by 'mysql tuned'?

thanks

This suggestion will start generating a log of log errors, however you can run ccp under mod_perl.  We currently do this and there was a huge boost in speed and decrease in server load.  The one draw back is CCP wasn't designed to run under mod_perl so it generated a lot of log errors, depending on how you log errors.

You can setup Apache (or whatever) to not log as many errors if you want.  You will need to run CCP under PERLRUN mod_perl method instead of the full mod_perl.

Example Apache conf setup:



(Adjust for other web servers)

I don't know your server specs, but you might need a more power server.  Our low end Sun boxes handle loads better than most high end x86 boxes non 64-bit systems..  Better data paths and such.

I should also add that MySQL isn't always faster.  In fact for certain tables it may be better to leave as CSV's.

Size is an issue.  When you pass a call to a database MySQL or whatever you are having to go through another engine.  In fact in my Oracle 8/8i OCP training we learned that a tiny database like a 1 MB or so is much faster at the flatfile level.

So you may actually want to bring some of your small tables out MySQL so you have less db engine calls (which would free up MySQL resources for invoice calls and such) and allow flatfile calls.

Why make calls to a table with 50 entries, for example?  We use a combine of both MySQL and CSV tables.

I would also run a program like top and watch it some to see what is really eating up your memory.  We have also noted on some of boxes Apache does a poor job of managing memory.  You may need to set Apache to kill clients faster and clear memory to help system performance.

First, I would look at admin and see if you are running in csv mode or in the database mode.  Also, check your data, especially in the products table and see if you have any duplicates in the Product ID column.  If you have duplicates, it drives the server load up while the server is trying to figure out which record to display.

As for running a more recent version of the cart, I don't believe that there has been anything done to the code that would help a load situation since the major structural change going fro 5.101 to 5.102.  You might want to update just for some additional functionality and for security reasons.

If this can not be resolved on your present server, then go looking for a new host.  Start by looking at the partner hosts listed on this page.