"postProcess" takes insanely long time during order confirmation

[j.kaspar]

Hi, I have Prestashop 1.6.1.13 with default theme, with customized css and a few modifications in tpl files and translations.

 

A big problem is, that order confirmation, it means between push of a confirmation button for example in bankwire and the final confirmation page, takes always around 30 seconds, sometimes more. On the browser side, most of the time is spent on virtually nothing... Just waiting. The debug profiling mode clearly shows, that the problem is in some "postProcess". It takes 19 seconds, before something else happens. Here is the debug output:

 

 

Furthermore, there is a significant delay here:

 

and here:

 

I use google smtp for mail communication.

I discovered prestashop just a month ago, so I am still learning and am clueless what more I could do to find out what the postProcess actually does and what could be the cause of the delay. Could somebody please point me the right direction?

 

Thank you in advance

Edited June 8, 2017 by j.kaspar (see edit history)

[j.kaspar]

update: turning off the mail alert module, that has been used to send a message, when a customer makes an order, made the process a little bit faster. In the debug report, pretty much everything is green now, except the "postProcess". I did not find info what it does and what could be the cause of the huge delay.

[PrestaHeroes USA]

for finding what is hooked 

modules-->module positions-->

 

in the search box type the hook that is causing delay.

 

note: you may need too enable display non-positionalbe hooks

 

see screen shot

 

https://www.screencast.com/t/1S3wmfIS44ri

 

--------

Maybe this is mis-configuration of your advanced parms-->performance page?  Can you  provide screen shot smarty and CCC settings?

[j.kaspar]

El Patron, thank you for reply. I checked the hooks. It seems, that it is no longer an issue. The process is a bit faster, but the huge delay on postProcess still remains.

 

The CCC looks like this:

 

in other words, everything is on. Could it be a problem?

It is worth saying, that I use file system caching (with directory depth 2). I am aware that this is far from optimal, but since the hosting I currently use cannot offer any other caching system, it is my only option for now.

[bellini13]

Go to advanced parameters > email and temporarily disable email and try again.  I suspect this will dramatically reduce the order confirmation time.

 

Connecting to 3rd party SMTP servers (especially those like office365 and gmail) that require START TLS is an extremely time consuming process.  The mail library packaged with Prestashop (swift mailer) does not handle that connection very well.

[j.kaspar]

bellini13, thank you, I tried it as you suggested, but unfortunatelly it had zero positive impact on the duration. This time it took 36 seconds.

 

 

10 hooks, 35 modules with total time 1390ms, so it clearly is not caused by some module. 

 

Suspicious are data from "Object model instances" section.

There are 90 instances of "Category" -  51x /modules/blocktopmenu/blocktopmenu.php [599], 1x /modules/blockcategories/blockcategories.php [200] and 38x /classes/Link.php [177]

and 18 instances of "Carrier" - 16x /classes/Cart.php [1865] (the number differs in each row), 1x /classes/PaymentModule.php [278] and 1x /classes/order/OrderInvoice.php [644]

 

I don't really know what that means...

[bellini13]

Then you likely have some other module or customization that executes in the postProcess function.  I can't determine that with the information you have provided, but the information exists in the profile page

 

Nothing out of the box in Prestashop will cause postProcess to take 31 seconds (31069 milliseconds).  So you certainly have added something that is causing it.  If you can't figure that out from the profiling information, then go back to the basics and start removing things that you have added one by one and see what effect it is having.

[PrestaHeroes USA]

with info provided it's not possible to isolate issue.

 

An easy way to determine if a module and/or override are causing performance issue try this:

 

back office-->advan parms-->performance

 

here you can 'disable' third party modules and/or overrides

.

You can determine if issue is module related by disabling one or both and run your timing tests.  If when one or both are disabled and tests are 'much' better then you will need then to isolate which module and/or override is causing issue.

[j.kaspar]

I invested a lot of time to test it. Eventually, it turned out, that using php mail() function does help, and the process is noticeably faster, than with google SMTP. However, the delay is still there. No overrides, no third party modules, and it is still there. So now I blame it on the hosting. The duration of the delay varies from several seconds to dozens of seconds. On a local computer, the delay is sometimes 0, sometimes 1500ms. As a temporary "solution", added a progress indicator to the payment modules. It is triggered by "confirm order" button. At least now the customer knows, that the button has been pushed and the system is doing something. The indicator covers the whole page, so nothing else, that could "disturb" the confirmation process, can be done.

 

Could someone please explain to me, what the "postProcess" actually is?

Edited June 19, 2017 by j.kaspar (see edit history)

[PaulM-pack]

I invested a lot of time to test it. Eventually, it turned out, that using php mail() function does help, and the process is noticeably faster, than with google SMTP. However, the delay is still there. No overrides, no third party modules, and it is still there. So now I blame it on the hosting. The duration of the delay varies from several seconds to dozens of seconds. On a local computer, the delay is sometimes 0, sometimes 1500ms. As a temporary "solution", added a progress indicator to the payment modules. It is triggered by "confirm order" button. At least now the customer knows, that the button has been pushed and the system is doing something. The indicator covers the whole page, so nothing else, that could "disturb" the confirmation process, can be done.

 

Could someone please explain to me, what the "postProcess" actually is?

 

Hi,

I had the same problem with potprocess.

I tested in localhost. the processing time was about 70-80 seconds !!!

On the server, I had set max-execution-time to 30 sec

on localhost I set max-execution-time unlimited

I have tried all the variations described in this topic.

In my case it was the mailchimp module. I uninstalled it and everything went back to normal.

Now the local postprocess takes 5-7 seconds and on the shared account server 9-14 seconds.

[j.kaspar]

It is very interesting. Actually I had a lot of problems with mailchimp module too and also uninstalled it. It was filling my error log quite a lot. But I cannot say, if it helped with the original issue, because meanwhile, I moved the shop to VPS with nginx, php7, lot of resources etc., and it is sooo much faster, that this issue stopped bothering me immediatelly after the migration.

 

 

Hi,

I had the same problem with potprocess.

I tested in localhost. the processing time was about 70-80 seconds !!!

On the server, I had set max-execution-time to 30 sec

on localhost I set max-execution-time unlimited

I have tried all the variations described in this topic.

In my case it was the mailchimp module. I uninstalled it and everything went back to normal.

Now the local postprocess takes 5-7 seconds and on the shared account server 9-14 seconds.