"Cart Contents" and "checkout" painfully slow

[Guest]

I've tried both OS Commerce and AlgoZone's build of OS Commerce and find that both are dreadfully slow when viewing cart contents or when going through the checkout process. This is on out-of-the-box installations.

 

I have installed both versions on Dual Xeon, Dual Pentium III, and single Pentium II boxes. On machines where phpbb and other PHP/MySQL apps are extremely fast (installed several for testing - none of the machines have any load on them, and most are at 1GB RAM with 7200rpm/8mb cache HDDs with DMA enabled, one Dual Xeon is all SCSI w/15,000rpm drives).

 

Sample Environment (my dual Pentium III workstation):

Dual Pentium III, clocked at 150Mhz FSB (975Mhz)

1GB RAM

7200RPM HDD, 16MB buffer, DMA enabled

 

Single NIC with a single IP (not multihomed, rule that out)

Firewall is disabled

 

Suse Linux 9.1

Apache: Apache/2.0.49 (Linux/SuSE)

Loaded Modules core prefork http_core mod_so mod_access mod_actions mod_alias mod_auth mod_auth_dbm mod_autoindex mod_cgi mod_dir mod_env mod_expires mod_include mod_log_config mod_mime mod_negotiation mod_setenvif mod_ssl mod_suexec mod_userdir sapi_apache2

 

MySQL: mysql Ver 12.22 Distrib 4.0.18, for suse-linux (i686)

Linux 2.6.5-7.111.19-smp #1 SMP Fri Dec 10 15:10:58 UTC 2004 i686 i686 i386 GNU/Linux

 

PHP info:

PHP Version 4.3.4

PHP API 20020918

PHP Extension 20020429

Zend Extension 20021010

Debug Build no

Thread Safety disabled

Registered PHP Streams php, http, ftp, https, ftps, compress.zlib, compress.bzip2

Apache 2 configured with prefork MPM (changed to worker for testing, no improvement)

GZip compression enabled, level 5 (should not make any difference for local testing)

 

OS Commerce configuration:

Category count disabled

Out-of-the-box sample data (for both straight OS Commerce and Algo's The Store Zone)

persistent connections disabled

 

Other info: While waiting for the pages to load, total CPU utilization remains below 3% total. MySQL and httpd are nearly idle, and the system remains extremely responsive. Booting with nosmp kernel option makes no difference (rule out race conditions from poor thread management).

 

Any ideas?

[Guest]

speed of the server is probably not the problem, could be the connection to the internet.

on another note, php 4.3.4 is old and has bugs, you should upgrade to php 4.3.10 asap

[Daemonj]

It sounds like mysql is your likely culprit.

 

Either that or you have a contribution like Ship in Cart or are using real-time shipping quote contributions (e.g. FedEx, UPS, and/or USPS).

 

If that is the case then the delay is the obtaining of actual quotes from the shippers' server and there is nothing that can be done about that.

 

If you are using GZip compression, what value are you using? It should be 1.

 

As Mibble already stated, upgrade your version of PHP as well.

[Guest]

with osComnmerce 99% of the time it is not hardware but a contribution, something of the like that Jim stated. yet you have not responded with what you have installed contribution wise. are you hosting your own site or is it at a host somewhere?

[Guest]

speed of the server is probably not the problem, could be the connection to the internet.

 

As I previously indicated, I am running it locally. In addition, even if I were running it over the Internet, I have 3mbps downstream/768mbps upstream and latency is *usually* lower than 30ms to the backbone, and is usually under 10ms to the host I partner with.

 

<{POST_SNAPBACK}>[/right]

 

Upgrade for the sake of upgrading, just shooting from the dark? No thanks, I'm looking for quantifiable known issues rather than to randomly make changes. Besides, I've tried it on previous builds of PHP on other Linux boxes (suse 9.1 out of the box - no patches) and encounter the same symptoms.

[Guest]

upgrading is not just for shooting in the dark. many worms have come out the last few weeks, which exploit php and just about every single host out there has forced everyone to upgrade, because of what the worms do. it is even stated here on the forum that you should upgrade to php 4.3.10 or higher. Jim even stated you need to upgrade. that was not stated just for grins but for a legitimate reason.

just because you have 3 mbps down and 768 up doesnt mean it is guranteed. most isp's, (comcast, verizon, etc) limit what you are really accessing, especially if you are not on their business account for hosting.

 

there are many variables.

 

we are trying to help, if you dont want the help, i do understand.

[Guest]

Upgrade for the sake of upgrading, just shooting from the dark? No thanks, I'm looking                                                                                                                                            for quantifiable known issues rather than to randomly make changes. Besides, I've tried it on previous builds of PHP on other Linux boxes (suse 9.1 out of the box - no patches) and encounter the same symptoms.

<{POST_SNAPBACK}>

As was mentioned previously, 99% of problems with osCommerce is due to installed contributions. However, since it's a vanilla install that can be eliminated.

 

You have posted the hardware for the systems and it should not be lacking in performance. My local network dev server is an old 333 Mhz running CentOS (just another Red Hat flavor) and I still get sub .1 second loads on every page.

 

So, let's start some debugging :)

 

Modify tep_db_query() which is located in *catalog*/includes/database.php to log queries that take longer than "x" seconds to execute. I posted the code in this thread: How to debug a nasty query problem. Be sure to turn on the option to store queries after you change the code to start the logging. Also, modify the execution time ($_time > 5.00) to suit your needs.

 

That modification will help you pinpoint EXACTLY where MySQL is taking longer than normal to execute and also what query is at fault. If you find that MySQL is not to blame then move on to debugging the code...

 

Let's see how the MySQL logging goes and if nothing turns up we'll start to work on the code debugging.

 

Bobby