Support

May 12, 2014 at 1:17 am

Hi Jomo,

I assume you’re using AIM? As the software needs to communicate with the Authorize.net server there is a possibility it will be slow, depending on connection speed. That being said, all my tests have had a 4-5 second response time.

Is it possible to see your test event?

I will raise a feature request to add in a loading icon or similar visual notification.

May 12, 2014 at 5:47 am

yes I am using AIM – can I send you a pm with the URL to test?

May 12, 2014 at 6:55 am

Hi Jomo,

Send it via email please, support@eventespresso.com and include a link to this forum post as well.

May 12, 2014 at 7:15 am

Ok – sent. Can you also do a transaction with multiple tickets as well – seems like if you do either 1 ticket or multiple ticket transaction it still takes a good deal of time to do the transaction. thanks!

May 12, 2014 at 7:18 am

Hi,

Thanks for the details.

I ran a test on your site and it somewhere in between both our times, at approx 11 seconds.

There are no errors or obvious issues with the page, so currently it seems to simply be a slow connection.

Basic pings to Authorize.net are taking 8000ms (for me at least).

Currently the best advise I can provide to at least notify your customers would be to put a notice advising them to wait patiently after clicking.

May 12, 2014 at 7:42 am

thank you, – which php file do i need to add that notification text? – ideally above the submit button.

Also, is there anything I can ask my hosting company to check specifically?
Or is it with Authorize.net? We have been doing this for the last 3 years and haven’t experienced this latency – i am just a bit worried when the site gets hit a lot – that a lot of orders could get messed up.

thanks for your assistance!

May 12, 2014 at 10:19 am

Hey Jomo,

Probably the easiest way is to copy the aim directory from event-espresso/gateways over to wp-content/uploads/espresso/gateways.

Then edit wp-content/uploads/espresso/gateways/aim/aim_vars.php and add in something like:

<p>Please only click the submit button once, and wait for the new page to load</p>

or words to that effect, at approximately line 113 (near the bottom) just above the submit button.

“Also, is there anything I can ask my hosting company to check specifically?”

Honestly, I’m not sure. I don’t really think there is much that can be done, especially if it’s a connection issue.

Have you changed host recently?

May 12, 2014 at 4:37 pm

same hosts for last 10 years (Media Temple) -no change – other than had to upgrade to the latest 3v of EE.
It was working great until then… ughh. I hope i can find a solution soon. thanks!

May 13, 2014 at 12:28 am

Hey,

I looked through the plugin’s changelog and we haven’t done much work to the gateways recently, and absolutely nothing in respect to Authorize.net so I’m not seeing how the update could affect it (though with code you just never know!).

May 15, 2014 at 8:35 pm

Transactions are now about 25-27 seconds – i hate to keep bugging about this – but i need to figure out what is going on to speed up this process

– My hosting company says everything is running find and optimized on the backbend DB/php

-I contacted authorize.net and they said “Basically, this means that of those 20-30 seconds, 2-3 seconds is the process of the shopping card communicating to Authorize.Net. The rest of the time, it is your shopping cart causing the delay.”

Also – It seems like i get the email notifications way before the page actually updates to the “success” page. So i don’t know where the latency is coming from. Is it a specific query that could be effecting things?

I have test mode set in authorize.net payment settings – does this actually go out to authorize.net or does EE flag it before so and mark it as a “test’ transaction?

Has anybody ever experienced this? i am already in this a ton of hours just troubleshooting this simple thing – everything else works great. thanks!

Lorenzo Orlando Caum

Support Staff

May 15, 2014 at 9:27 pm

Hello,

We haven’t received any other reports of this long delay. Do you have an alternate WordPress site with this host or another host that you could setup a basic event on and test?

—
Lorenzo

May 23, 2014 at 7:17 am

I will have to set up another instance if site on different host to test- which I really don’t want to do since this has been running fine last few years. But I will if that is last resort.

I am still trying to figure out what is going on behind the scenes.

Is there any clues to the fact that I get my email notifications of successful transactions way before the success screen shows up. For instance, during the 26 seconds of waiting for the success screen – I get the email confirmations 10 seconds after I press submit.

I have a max of 4000 attendees set with a max of 4 people in a group per transaction.

Could there be something with DNS? I do have force https plugin and working for your suggested pages.

Support Staff

May 23, 2014 at 12:58 pm

Usually Chrome dev tools will show you what’s potentially causing a page to slow down. The other thing to check would be the PHP error log on the server to see if there are any errors being thrown.

Also – It seems like i get the email notifications way before the page actually updates to the “success” page. So i don’t know where the latency is coming from. Is it a specific query that could be effecting things?

You can also install the Debug Objects plugin and view all the queries (and almost everything else) going in behind the scenes while the page loads.

I have test mode set in authorize.net payment settings – does this actually go out to authorize.net or does EE flag it before so and mark it as a “test’ transaction?

It does go out to authorize.net and tells them that this is a test transaction, so no actual money gets transferred when it’s in test mode.

May 23, 2014 at 1:19 pm

Thanks Josh – i ran the Debug Ojects plugin and got the following:

NOTICE: wp-content/plugins/wordpress-https/lib/WordPressHTTPS/Url.php:501 – Undefined index: user
NOTICE: wp-content/plugins/wordpress-https/lib/WordPressHTTPS/Url.php:502 – Undefined index: pass
NOTICE: wp-content/plugins/wordpress-https/lib/WordPressHTTPS/Url.php:504 – Undefined index: port
NOTICE: wp-content/plugins/wordpress-https/lib/WordPressHTTPS/Url.php:506 – Undefined index: query
NOTICE: wp-content/plugins/wordpress-https/lib/WordPressHTTPS/Url.php:507 – Undefined index: fragment

Support Staff

May 23, 2014 at 5:44 pm

Hi Jomo,

I do not think that some undefined index notices from your https plugin are slowing the page down. Since you asked about the queries running on the page, I suggested checking out the debug objects plugin, which should give you information about the queries running on the page.

May 23, 2014 at 6:06 pm

OK. I got that info from the debug objects plugin. I guess I just need some guidance on what to activate in that plugin (Assuming queries)and what I should be looking for specifically?

Also – do I need to do a test transaction so the plugin sees they queries etc?

Support Staff

May 23, 2014 at 6:11 pm

Yes, you’ll want to replicate the steps while troubleshooting.

May 24, 2014 at 7:15 am

Ok as far as error logs – i get only (2)- not sure it is related at all:

[Sat May 24 04:27:00 2014] [error] [client xxxxx] ModSecurity: Warning. Match of “rx ^POST$” against “REQUEST_METHOD” required. [file “/etc/apache2/mod_security/custom/wpbrute.conf”] [line “6”] …

[Sat May 24 04:27:01 2014] [error] [client xxxxx] ModSecurity: Warning. Match of “rx ^POST$” against “REQUEST_METHOD” required. [file “/etc/apache2/mod_security/custom/wpbrute.conf”] [line “11”] …

as far as using the debug objects plugin – i ran a sample transaction in a new tab (25 seconds to process) and went back to my admin and see i get a ton of feedback under Db queries, plugin db quires, wp-content db queries, – however i have no clue what i am looking for specifically – where i can isolate this 20-25 lag time? Which tab in debug objects should i be focusing on? and do i have to keep doing transactions over and over to get the latest debug info?

I appreciate your continued help on this issue.

May 26, 2014 at 8:40 am

It is also taking about 10-12 seconds for the cart to load once you click the initial purchase ticket link. The spinner graphic spins and them final the shopping cart table appears. In years past this has been much quicker.

We are opening ticket sales June 2 – so hopefully I can get this resolved by then. 25 seconds+ is definitely a bit long to get any feedback after you click purchase – and scares me if we are having a flood of transactions at the same time.

Support Staff

May 27, 2014 at 8:52 pm

Hi there,

It may help to run some tests with the default WordPress theme activate with all non – Event Espresso plugins temporarily disabled to see if that affects the page speed.

June 1, 2014 at 7:53 am

@dean

I have updated the checkout page to leave a message for users to be patient as it is taking 25 seconds + to check out.

The problem i am seeing now is that it seems to be reverting back to the original file –

here is the file path i am using to edit: wp-content/uploads/espresso/gateways/aim/aim_vars.php

June 1, 2014 at 8:48 am

@josh
I tested with 2014 default theme – with all non EE plugins disabled.
It seemed to not effect at all – still slow. I am trying to pull some more debug data – and will supply shortly.

June 1, 2014 at 11:58 am

I am working with my developer colleague to help me track the root of the latency – the following is what he asking to get info from you guys. Could you help point us in the right direction with his question?

—

“I would ask them what logging options we have available to us. It does seem that the call to auth.net is clean. Guessing auth.net is responding fine. So, we need to log what happens when that callback comes back. I would also ask which files are involved in that callback so we don’t have to waste our time hunting it down. If we know the files, we can add our own log statements in if they don’t have anything pre-baked. That query in and of itself isn’t the issue. It shows that we are pounding the server too hard, but we need to find the cause. That query is just a result of being executed after whatever is killing us. If I run it stand alone it is like .004. We really just need them to give us some direction of how to run this down and get more detail without having to get to know their app intimately.”

Support Staff

June 2, 2014 at 9:39 am

Hi Jomo,

The first tool for logging I recommend is to log wp_debug to a file. This can be set up by adding:

define('WP_DEBUG_LOG', true);

to the wp-config.php file. What this will do is it will log all errors to a file named debug.log in the /wp-content folder. You may need to FTP in and create the debug.log file if the server’s permissions aren’t set to create files.

In addition, there is Event Espresso specific logging that can be switched on. In Event Espresso 3, you go to the Event Espresso > Organization Settings and scroll down to near the end of the Advanced options section. Here you can set “Use full logging?” to Yes, then save. This will write to a log file in /wp-content/uploads/espresso/logs.

June 2, 2014 at 11:17 pm

@josh

Ok – i think we may have found our issue – it seems the conversation with the smtp server is taking 5 seconds per email to send out. Any recommendations on how i can improve this?

Here is the EE log:
[ 2014-06-03 01:01:09 ] email.php -> event_espresso_send_payment_notification
[ 2014-06-03 01:01:09 ] email.php -> espresso_prepare_email_data
[ 2014-06-03 01:01:09 ] email.php -> espresso_prepare_email
[ 2014-06-03 01:01:09 ] email.php -> replace_shortcodes
[ 2014-06-03 01:01:09 ] ical.php -> espresso_ical_prepare_by_meta
[ 2014-06-03 01:01:09 ] email.php -> replace_shortcodes
[ 2014-06-03 01:01:09 ] ical.php -> espresso_ical_prepare_by_meta
[ 2014-06-03 01:01:09 ] email.php -> event_espresso_send_email
[ 2014-06-03 01:01:14 ] email.php -> espresso_prepare_email_data
[ 2014-06-03 01:01:14 ] email.php -> espresso_prepare_email
[ 2014-06-03 01:01:14 ] email.php -> replace_shortcodes
[ 2014-06-03 01:01:14 ] ical.php -> espresso_ical_prepare_by_meta
[ 2014-06-03 01:01:14 ] email.php -> replace_shortcodes
[ 2014-06-03 01:01:14 ] ical.php -> espresso_ical_prepare_by_meta
[ 2014-06-03 01:01:14 ] email.php -> event_espresso_send_email
[ 2014-06-03 01:01:19 ] email.php -> espresso_prepare_admin_email
[ 2014-06-03 01:01:19 ] email.php -> event_espresso_send_email
[ 2014-06-03 01:01:24 ] payment_overview.php -> FILE LOADED
[ 2014-06-03 01:01:24 ] pricing.php -> espresso_payment_type
[ 2014-06-03 01:01:24 ] pricing.php -> event_espresso_paid_status_icon
[ 2014-06-03 01:01:24 ] espresso.php -> ee_init_session
[ 2014-06-03 01:01:24 ] espresso.php -> espresso_load_javascript_files
[ 2014-06-03 01:01:24 ] espresso.php -> espresso_register_validation_for_shortcodes
[ 2014-06-03 01:01:24 ] espresso.php -> espresso_load_jquery
[ 2014-06-03 01:01:24 ] espresso.php -> add_event_espresso_stylesheet
[ 2014-06-03 01:01:24 ] espresso.php -> add_espresso_themeroller_stylesheet
[ 2014-06-03 01:01:24 ] espresso.php -> espresso_info_header