I upgraded to 7.02 a week or so ago, and 7.03 last night. I'm getting calls about poor response time, or no response. I had noticed this as well, but hoped it would go away! Browsing the site seems fine. The poor response occurs when viewing the cart and at checkout. Checkout is really, really slow - to the point where some people are giving up. There aren't any known server issues that would be causing this. Any response time issues with v7 that are known? Anyone else experiencing this?
Announcement
Collapse
No announcement yet.
Slower response times w/ 7 than w/ 6?
Collapse
X
-
Obviously v7 is slightly slower than v6 was. The slower performance is down to the new features added (especially discounting). We do not have exact measurements for v7 performance but this topic contains an independent performance analysis up to v6. I believe the same tendency applies between v6 and v7.
Regards,
Comment
-
that's a thread about a general script error... ? ? ?
I think the problem is this...
this is a site doing only a few tens of orders a day - not hundreds, or even thousands?
It's on a DEDICATED server - admittedly, it's not a super, monster server - but it's a server with 512Mb of RAM and the site kicks out about less than 20Gb of data in a month - most of which is NOT even Actinic.
The fact that the Actinic scripts are the slowest portion of the site is SIGNIFICANT to both the client and me... (the host).
I have to ask, why are the script so slow?
Has anyone ever successfully used perlcc to compile them?
Any move afoot for compiled actinic scripts? or a move to php (many php solutions with database backends appear to be a LOT faster than Actinic in the add-to-cart and search functionalities)...
Comment
-
Yes, that was the starting point of the discussion but it moved far forward.that's a thread about a general script error... ? ? ?
Although it is called "script" due to its implementation method (using a scripting language) it is a complex application in the reality. During the checkout different calculations should be done (including tax, shipping and discounts). The checkout part also does order encryption what is a real resource eating process (unless its binary is not installed - search for ActEncrypt1024). If UPS is used for shipping then the communication to the UPS server also slows down the checkout. And so on...I have to ask, why are the script so slow?
Its result is a binary which would significantly limit our sever side platform independency. Therefore we didn't consider it at all. However you may find users here who has tried this already.Has anyone ever successfully used perlcc to compile them?
Obviously we got plans which would address most of the current online problems. But it is too early to say any details.Any move afoot for compiled actinic scripts? or a move to php (many php solutions with database backends appear to be a LOT faster than Actinic in the add-to-cart and search functionalities)...
If the processor speed is not the main requirement for this site then probably you can consider to move it to a higher spec non dedicated server as an option.this is a site doing only about 30 orders a day.
It's on a DEDICATED server - admittedly, it's not a super, monster server - but it's a server with 512Mb of RAM and the site kicks out about less than 20Gb of data in a month - most of which is NOT even Actinic.
If the real performance bottleneck is the last stage of the checkout then you can consider the installation of ActEncript1024 to speed up the encryption.
If you are using Apache server then installation of mod_perl is also an option to improve the performance.
I hope I could help.
Regards,
Comment
-
Okay, Greg -- my 20 years of IT mainframe experience isn't helping me out much here! I'm afraid most of this has gone right over my head. I grasp the general information, but I'm glad you are participating in this thread. I'll trust you to tell me what we need to do differently, if anything, to get a better response time.
One thing I did read that worries me -- discounts. I just went through and changed all my clearance items to use discounts. Up until this morning, I had the prices adjusted in quickbooks, so the discounted price was stored in Actinic. Today I changed the prices to retail prices, and used the new discount feature in Actinic. This makes it easier for me to move items on down the clearance chain. But now I think maybe this was the wrong thing to do? Do all orders take a performance hit, or just those orders that included discounted items?-------
Pat
Comment
-
Zoltan,
I have a question about ActEncrypt1024...
we have two versions of Perl on most of our servers:
/usr/bin/perl - 5.005_3
/usr/local/bin/perl - 5.8.3
Now - if I compile ActEncrypt1024 against the 5.005_3 version, what will the outcome be for clients who have configured actinic to use /usr/local/bin/perl (the later version of perl)...
Basically, which is the safest perl to compile against, and do I have any issues with that (recommended) method?
cheers
Greg
Comment
-
I'm fairly certain it is checkout -- that was my experience when I was testing to see if I had the discounts setup properly. I'll tinker a bit more, and it I get different results, I'll let you know.Originally posted by webyourbusiness
Pat,
at which point is the biggest increase in lag - add-to-cart- or checkout finalization?
regards
Greg-------
Pat
Comment
-
Originally posted by pharryI'm fairly certain it is checkout -- that was my experience when I was testing to see if I had the discounts setup properly. I'll tinker a bit more, and it I get different results, I'll let you know.
Perhaps we can get an answer from Actinic....
when the user hits the checkout button from the cart, it seems to load CA0000001.pl and then OS000001.pl - why does it load one script to load another - that seems a little redundant... and this seems to be the step that is the slowest...
Does this bounce use the bounce delay timing found in the design options | Shop defaults | bounce delay setting?
Comment
-
Obviously the check of cart contents agains the discounts defined is done all the time when the cart is displayed. But it shouldn't take long if discounts are not calculated.Do all orders take a performance hit, or just those orders that included discounted items?
The performance loss really depends on the number of discounts defined. If you have only a couple then you will not notice the difference. It can only be seen on the performance if you have 10's of discounts.
Regards,
Comment
-
If you install the module for the perl in /usr/bin/perl then it will not have effect on the sites using /usr/local/bin/perl.Now - if I compile ActEncrypt1024 against the 5.005_3 version, what will the outcome be for clients who have configured actinic to use /usr/local/bin/perl (the later version of perl)
The module should compile for both as far as I can recall the requirements. But it makes sense to use a later version of perl.Basically, which is the safest perl to compile against, and do I have any issues with that (recommended) method?
Regards,
Comment
Comment