Fill out the request with the origination and destination info (doesn't matter if it's domestic or international).
Response returns all rates for all services that are available from the carrier (whether you are using those shipping services or not).
Each method then calls to get its rate (which have already been retrieved)
The rates associated with each method are displayed.
Unless the products, origination or destination changes (I.e. the packages of products in the current cs-cart), a new request is NOT made. There is additional caching so that when going from the cart page to checkout, rates are not re-acquired unless one of the three things have changed since the last request.
It is possible that it's taking UPS longer to return international rates due the the variety of destinations. However, I would measuer that in milli-seconds, not seconds. Just my opinion.
I ran 1.3.4 and earlier versions for a couple years on Bluehost and was always slow but a compeditor complained of copyrighted material from another website or something of that nature which was not true we have our own white room but Bluehost hit us with 800.00 usd fees for this issue which was a rip and theft but they had are amex on file and to get it back would cost more so we went to another and was the best move, they really pack alot of accounts per server and was always slow
It is possible that it's taking UPS longer to return international rates due the the variety of destinations. However, I would measuer that in milli-seconds, not seconds. Just my opinion.
[/quote]
I fully agree with this, the time difference to return domestic vs. international rates to your store will be negligible. My bet is that one of your international realtime methods is setup incorrectly which is causing a bottleneck in having your rates returned. I would remove all of your intl methods & test. Then add each one back one at a time to help pinpoint the problem.
The solution was found by the CS-Cart support! I now have all the shipping methods enabled (both domestic and international) and it only takes about 2-3 seconds instead of 10-15 seconds!
The were changes made in the fn.cart.php file and not sure what they were yet but it works. Later tonight I will compare the original with the modified fn.cart.php file to see what the changes were (the file is huge so I did not have time to do a quick compare this morning).
Great that you were able to get the issue resolved!
However, will be interesting to know if this was an actual bug in the un-modified fn.cart.php file from the 2.2.4 Release, or if you had a corrupted file which they repaired?
Original code: ```php
if (function_exists(‘curl_multi_init’) && fn_check_curl() && false) {
Changed to: ```php
if (function_exists('curl_multi_init') && fn_check_curl()) {
```<br />
<br />
So basically just the ```php
&& false
``` was removed.<br />
<br />
That cost me 20 support credits?!? You would think they would reward me 20 credits for finding the problem (well not the solution but reported the problem anyhow). <img src="upload://zpvGXU83KUgZwhE2OOlB1CZIceX.png" class="bbc_emoticon" alt="^_^"><br />
<br />
<br />
Another website I know of too has the same exact problem ([url="http://bti-tool.com"]http://bti-tool.com[/url]) plus there might be some others out there no aware or concerned about that problem. Speaking of that I will have to send chrisbti a message to let him know the fix was found.
Just to update I moved everything to a ServInt VPS (Virtual Private Server).
The service is the $49 a month Essential VPS (Managed).
60 GB Storage
1 TB Monthly Transfer
768 MB Guaranteed RAM
1.5 GB Burst RAM
Hardware RAID 10
CentOS 6 64-bit
4 IP Addresses
Incredibly fast disk I/O
I can tell everything is running faster / more quickly to respond.
But the main problem again was when viewing the shopping cart (example when clicking the ‘Get Rates’ button).
On the shared server, it was taking between 12-14 seconds for the rates to appear.
On the VPS, it is now taking roughly 8-10 seconds for the rates to appear.
Faster but not fast enough … or is it just the Shipping processors USPS and UPS just could be more efficient? I have isolated the problem down to the shipping processors and when they reach out to get the live rates. For instance I can disable the UPS and just get USPS rates which then the ‘view cart problem’ is only a 2-3 second delay. UPS takes much longer to pull rates.
So aggravating.
I only have just one domain/website on the server. Maybe I will try to just install a ‘fresh’ copy of 2.2.4 and see how that runs. Or maybe I need to run only a $100 a month server to have enough power available for CS-Cart.
My CS-Cart is not open yet (as trying to get it running faster still) but here is the access link:
Basically just add an item or two into the cart then click the ‘View Cart’ and you’ll see the long delay (which it is checking rates). Then enter something like California / 90210 into the get rates box and click ‘Get Rates’ which you can again see the long long long delay.
Maybe someone else encountered this but was able to solve the problem??
-Tim
[/quote]
Hi Tim,
So your dedicated server is working well?
I am using the server at Bluehost, and yesterday an advertisement ran and I got about 200 people in a time so my website went so slow, so if you would recommend servint.net?
I am using the server at Bluehost, and yesterday an advertisement ran and I got about 200 people in a time so my website went so slow, so if you would recommend servint.net?
[/quote]
I would recommend ServInt. Comparing to Bluehost, the over speed of everything is so much faster. One of the biggest things is my FTP is very fast.
I have only had one problem so far that developed, but the support there had it fixed with-in 10 minutes. My site response time was getting very slow, then I was getting Out of Memory errors…so I contacted support and they found something gone wrong with the spamassassin program so the cut it and reinstalled.
It is a managed VPS so even though it is technically your dedicated portion of a server, if you ever need anything checked, installed, etc they will help you…and the response time is very good…even on weekends!
Just to update I did contact support and they were very considerate of the 20 credits. Basically as explained the credits were removed as the problem escalated up the support ladder. However since the end result was a ‘testing/debugging’ code that was left in the software on the latest release, they did promptly refund the 20 support credits!
Original code: ```php
if (function_exists(‘curl_multi_init’) && fn_check_curl() && false) {
Changed to: ```php
if (function_exists('curl_multi_init') && fn_check_curl()) {
```<br />
<br />
So basically just the ```php
&& false
``` was removed.<br />
<br />
That cost me 20 support credits?!? You would think they would reward me 20 credits for finding the problem (well not the solution but reported the problem anyhow). <img src="upload://zpvGXU83KUgZwhE2OOlB1CZIceX.png" class="bbc_emoticon" alt="^_^"><br />
<br />
<br />
Another website I know of too has the same exact problem ([url="http://bti-tool.com"]http://bti-tool.com[/url]) plus there might be some others out there no aware or concerned about that problem. Speaking of that I will have to send chrisbti a message to let him know the fix was found.<br />
[/quote]<br />
<br />
I did this and it did seem to help, but it's still not as fast as my old oscommerce store pulling the same rates from the same place under the same account, and that site is still on my old, much slower server. I'd like to see 1 sec times as someone stated above. I'm using a fresh install of 2.2.4 as well.
@Tim - good for you! You actually asked. So many others here just complain but never bring up the issue with anyone who can address it. I've never had a problem receiving credits when the problem has been related to a product defect.
@dotell - There are so many factors as to why it could be slow. One would have to profile various parts of the operation to determine exactly where the time is being spent. Could be database contention, poor network out of your hosting company, overloaded server, etc. just to name a few. Unless you're using multiple realtime shipping vendors (like UPS, USPS and FedEx), the removal of the “&& false” won't do much. It only runs paralell requests beween carriers, not between shipping methods within a carrier.
