I hope I have given as much details as needed. This is on a fresh WP 3.4, no other plugins. How long the call to mandrillapp.com actually takes is of course dependent on network connection speeds and latency. I guess there’s a bit of latency between Sweden and the US (if Mandrill doesn’t have EU sites) but my question is really about WHY the call is made at all.
Ok, it looks like the constructor of the Mandrill class does a ping request to the web service. And the Mandrill class is instanced by wpmandrill.php on every page request regardless of if it is needed at all.
That would explain it.
Now my question is not “why does this happen?” but more of “why, oh why, did you code it like this?”.
And then:
wpmandrill.php line 75 :: isReady()
one more call to ping, but this time through Mandrill::users_ping()
So that is TWO blocking http calls to a web service on every page load of a busy WordPress site. Removing these two ping calls dropped my page load time to a reasonable 0.2 seconds again.
I’m suggesting you only load Mandrill in the admin_init action on the admin pages that actually use it. And then load it on demand when sending mail from front end pages.
The pings should only be needed after changing the API key in admin, to verify that it works. Other than that I think we can trust that the service is still up until a real request, like sending mail, actually fails.
Hi Per,
This issue will be addressed on the next release. I’m sorry for the inconveniences.
And thanks for the suggestions.
Let me know if v1.12 solved the problems you mentioned.
If so, I’ll appreciate if you mark this thread as solved.
Ok, we’re getting there.
Now you don’t ping twice for every page load. That is good. That was the “WTF is happening here?!?” issue.
Now you just ping twice for almost every thing you do through the API. The first ping still happens in the constructor of the Mandrill class at line 20:
$response = $this->request('users/ping2', array( 'key' => $api ) );
if ( !isset($response['PING']) || $response['PING'] != 'PONG!' ) throw new Mandrill_Exception('Invalid API key');
The second ping is done in isConnected() on line 451 in wpmandrill.php.
What I was trying to explain earlier was that there is only one time we ever need to do the whole ping thing, that is directly after the user has changed his API key through the settings page. That is a good time to verify that the key works. After that single time we must be able to trust the fact that the key is still valid and the Mandrill server is still online. When any of these two facts are no longer true, we will get to know that since a call to any of the API methods that actually do something of value (like sending mail) will fail.
Consider this scenario (events are written in the order they happen in time):
1. I call wpMandrill::mail()
2. self::isConnected() does the ping and everything is still OK
3. The Mandrill service goes down or the API key is revoked
4. self::$mandrill->messages_send($message); fails
Now what was the reason to do (2)?
I’d agree with Per Wiklander on this one. There is no need to perform a ping for every email sent. Transactional email services are primarily high volume mailing systems. Repeating these pings on every send mail call would exponentially rise for high volumes and eventually bring down the site to it’s knees.
