All the pages within Mailchimp module load at a normal speed, except the campaign list. It is extremely slow, often timing out. Any ideas? Thanks.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

johndubo created an issue. See original summary.

johndubo’s picture

It often results in a 503 first byte timeout. The platform I am running on doesn't allow configuration of that timeout length.

trumanru’s picture

Version: 7.x-4.8 » 7.x-4.9

Same problem for more than 2 years.

bisonbleu’s picture

Priority: Normal » Major

I have the same issue with version 7.x-4.11.

Escalating to Major because I'm completely unable to access the Campaigns tab because of platform timeouts (Pantheon.io).

Roderik de Langen’s picture

Might this not also be due to the fact that the campagins table is not paginated? One of our clients already has over 80 campagins. Ofc this takes a long time. It is an idead to paginate this table

amccune’s picture

Also seeing this issue on 7.5.4

Campaign page does not complete load, sometimes does appear some blank entries and messages like "An error occurred while getting campaign 0ef6694d2e. Would you like to delete it?"

Adding a new campaign also painfully slow and times out, I assume because campaign page is being loaded in the return.

There are a lot of campaigns to list - over 50

trumanru’s picture

Problem solved with:

  • Mailchimp module version 7.x-5.4
  • thinkshout/mailchimp-api-php library version 1.0.10

About hundred campaigns. After clear all caches (flush-cache) the capmpaigns list opens for a long time but next tries take about 1 second.

bisonbleu’s picture

Update: I made some progress (with 7.x-4.11). I was getting 25+ errors of the following kind:

"An error occurred while getting campaign 78dfe729aa. Would you like to delete it?"

I could not delete those campaigns from the UI because I suspect they do not exist. So I deleted the entries directly in the database using the following command in MySQLWorkbench:

DELETE FROM `database_name`.`mailchimp_campaigns` WHERE `mailchimp_campaigns`.`mc_campaign_id` = '78dfe729aa';

After doing this, I'm able to load some 50 campaigns in 30 sec i.e. without a timeout. It's not great but it's not terrible.

dwayne_w’s picture

I spent a good chunk of time debugging this for a client on 8.x-1.8 and thought I would post my findings here as it appears to apply to this version as well.

While in my case there were number of Campaigns (600+) the root cause was actually related to loading in available Lists via the MC API, initiated from mailchimp_get_lists in mailchimp.module.

A direct API call - GET https://usX.api.mailchimp.com/3.0/lists - was taking 90+ seconds to return it's payload (!!). The workaround was to specify minimal fields to be returned, which sped up the response greatly.

So on line 126 in mailchimp.module I changed:

$result = $mcapi->getLists(array('count' => 500));

to:

$result = $mcapi->getLists(array('count' => 500, 'fields' => 'lists.id,lists.name,lists.web_id,total_items'));

Looking at 7.x-4.11 I can see the same issue so hopefully this will help someone - my Campaigns page now loads at a much more acceptable speed. I'd also deleted all but the last 10 Campaigns in my database but it was the above fix that made the difference.

baikho’s picture

Version: 7.x-4.9 » 7.x-4.x-dev
johndubo’s picture

Yeah. Paginating this list seems like the answer. I updated to 7.55, and I can actually get the list to load now, but it still timed out a few times before it would load.

Any thoughts about paginating it?

dennis_meuwissen’s picture

We ran into this issue as well for a client that has almost 90 audiences/campaigns. Loading the list took between 10 and 20 seconds every time, which includes the first page load after the caches have been cleared. The change from #9 reduces that long wait down to nothing. I've attached a patch that applies those changes.

torgosPizza’s picture

Status: Active » Needs review

Setting to Needs Review since there's a patch here. It also looks like the patch can still apply on 5.x but probably creating a new patch / issue would work better for that.