Caching

To prevent overloading of their systems, payment processors may limit the number of calls that can be made by an account in one day. It is important to manage how often your site accesses the payment processor when using externally owned campaigns or you may find your site unable to request current donation totals.

Changes made in Workflow #1 to a Drupal campaign record (editing and publishing) force an immediate refresh of remote campaign data. This will use 1 or more calls on each edit that count toward a daily API limit. Additional calls will be used throughout the day when CK marks a campaign’s remote data as stale (every 5, 15, 30, etc. minutes; see below).

User stories that obtain data from remote data sources (like payment processors) cache their data according to the “Cache Remote Data” configuration setting. Options include:

• “No caching” (use only for testing)

• 5 minutes

• 15 minutes

• 30 minutes

• 60 minutes

• 1 year (campaign ended)

Assuming the vendor limits API calls to 2000 per day, a busy campaign with no caching will use the entire allotment on one campaign with 2400 visitors (an undesired situation; the account will be limited by the vendor and visitors will see stale data). Furthermore, usually these daily limits must be shared among all campaigns in the account.

Thus, employing caching will thereby allow you to run multiple campaigns (especially important for child campaigns).

Assuming the 2400 visitors arrive evenly spread out throughout the day, even just a 5-minute cache will reduce the number of calls to 288 day—already much better (24hr x 60min/hr / 5min/call = 288 calls).