|
Jeremy Thompson
|
April 26, 2014 at 6:41 pm
Wordpress 3.9, EE3, Pagelines
We just went live at adjmkt.com from our test server and the payment settings page is loading incredibly slowly (up to 3 minutes to load). Presumably it’s not affecting our front end, but any suggestions on what might be causing this and how to fix it?
|
|
Tony
|
April 27, 2014 at 10:08 am
Hi Jeremy,
I’ve just ran a test registration with fake card details to test and found no issues.
Each page loaded within seconds.
Is this no longer an issue or can you provide steps to reproduce this so we can test please?
|
|
Jeremy Thompson
|
April 27, 2014 at 12:07 pm
Hi Tony,
It is fine for users, fortunately. Where we’re seeing the problem is from the admin side. Every settings page of Event Espresso loads great, except for “Payment Settings”. When you click that one, the site hangs for literally two to three minutes. It only happens when an Authorize.Net payment type is activated – if those are deactivated, the payment settings page loads instantly. In order to see the problem you will have to log in to our WordPress site as an admin. Where can I email you the credentials?
|
|
Dean
|
April 28, 2014 at 12:08 am
Hi Jeremy,
You can send the detail securely via this form – https://eventespresso.com/send-login-details/
NOTE: login details need to be Admin level and FTP details are appreciated.
|
|
Dean
|
May 6, 2014 at 2:55 am
Hi Jeremy,
It’s very strange why this is affecting only that page.
I ran a few tests and as far as I can tell there was nothing out of the ordinary. In fact for the most part the site seemed to be idling. There are no errors or anything like that.
It’s obviously not a PHP issue as the default timeout is 30 seconds, and this is running for 3 minutes every time.
Right now the best advice I can give is:
1) Try disabling all other addons and reverting to a default theme and see if that resolves the issue.
2) Try bumping up the memory allocation to 128mb – http://codex.wordpress.org/Editing_wp-config.php#Increasing_memory_allocated_to_PHP
3) Contact your host to see if they can see any issues in the logs.
|
|
Jeremy Thompson
|
May 6, 2014 at 10:01 am
Hi Dean,
Unfortunately the changes don’t seem to make a difference – it’s still slow.
I have complete access to all the logs myself. I did a tcpdump on the network and this is what I see when I click the “payment settings” page:
15:51:44.121532 IP http://www.c.utopian-bonito-534.internal.59053 > http://www.http: tcp 0
15:51:45.121406 IP http://www.c.utopian-bonito-534.internal.59053 > http://www.http: tcp 0
15:51:45.262108 IP http://www.c.utopian-bonito-534.internal.46684 > http://www.https: tcp 0
15:51:46.261464 IP http://www.c.utopian-bonito-534.internal.46684 > http://www.https: tcp 0
15:51:48.261432 IP http://www.c.utopian-bonito-534.internal.46684 > http://www.https: tcp 0
That request comes out several times. As I mentioned before, this only happens when the Authorize.net modules are enabled. Is it possible that those modules are attempting to contact the server itself but somehow failing, and that’s why we’re seeing the three minute timeout?
|
|
Lorenzo Orlando Caum
|
May 6, 2014 at 10:11 am
Hi Jeremy,
This is very strange. I’ve never seen anything like this. Was it also slow to respond on the test server?
—
Lorenzo
|
|
Jeremy Thompson
|
May 6, 2014 at 10:20 am
Hi Dean,
I continued to troubleshoot and the problem is now solved. The Authorize.net module must behave as I expected – it sends some network requests and waits for a response before continuing to load. I altered the network configuration to ensure that those requests could properly go through, and now the page loads in a more normal 5 seconds or so.
Thanks, Jeremy
|
|
Jeremy Thompson
|
May 6, 2014 at 10:25 am
Hi Lorenzo,
Sorry, didn’t see your message until after I posted. The test server did not exhibit this behavior. To get technical, the problem was that the requests were using the server’s global IP address, which was forcing the requests to go out through Google’s firewall and come back in (and probably get rejected). I modified the /etc/hosts file to prevent this behavior and force the server to use its own locally accessible address instead. This problem may be unique to the way in which Google Compute Engine handles IP addresses – the hosted machines seem to have no knowledge of their actual outward-facing IP addresses. Hopefully this experience will save someone else a lot of frustration!
Best,
Jeremy
|
|
Lorenzo Orlando Caum
|
May 6, 2014 at 11:42 am
Thanks for sharing how you solved this issue!
—
Lorenzo
|
|
Dean
|
May 15, 2014 at 12:07 am
Hi Jeremy,
Sorry that I didn’t see your response until now, but I also just wanted to say well done on resolving it, and thank you for sharing how!
|
