Creative Asset Upload Timing Out

[Chris Baclig]

Hi,

I've been noticing that CreativeAsset inserts that previously took a few seconds to complete have begun to take more than a few minutes. Increasing the timeout has helped, but as we plan on only adding more creatives (and assets) over time, we'd prefer not to have to keep waiting longer over time. From my testing, it appears that uploading Creative Assets to only one particular campaignis having issues. That campaign has ~1,300 placement, ~360 creatives and ~360 ads. We have not been organizing our creatives by campaign in DCM but managing the relationships ourselves in our own system, so maybe our misuse of DCM campaigns is finally coming back to haunt us?

For context:

• I've replicated the issue on multiple machines on different networks and environments, so I don't believe its a network-related issue on my end. 
  
• We're using the Ruby client and have specifically been seeing the following errors stemming from our application's call to `insert_creative_asset`: 
  
• `Google::Apis::ServerError: Server error`
• `Google::Apis::TransmissionError: execution expired` stemming from `HTTPClient::ReceiveTimeoutError: execution expired`

Thanks!

Chris

[Lakshmi Prathipati (DCM API Team)]

Hi,

If this was a timeout from our API, you'd receive a 5xx response. We actually automatically fail any request that exceeds 5 minutes, so if this is failing with a 6 minute timeout that suggests the issue isn't related to the API itself. The recommendation here is to increase the wait time which you are already doing now and seeing that requests are successful. Since it is happening only for one campaign, for any further investigation, please send the following details in a private message:

1. A log (JSON format) of the exact request
2. Timestamp of the API request
3. DCM account ID
4. profile id
5. Campaign id
6. Project id (id of the Google Console project)
7. Are you seeing any issue (like taking more than usual time) when you are uploading the creative to this campaign in the UI? With this we can rule out the reason if it is a product level issue.

Thanks,

Lakshmi, DCM API Team

[Chris Baclig]

Thanks for the reply Lakshmi! After some more investigation I found a work around to my issue, which I've added below in case someone else finds this useful down the road. 

Looking more closely at our logs, the problematic API call was uploading backup image assets. When creating or updating HTML5 Creatives in DCM, we had also been explicitly uploading a new backup image asset along with the primary HTML5 .zip asset. However, all of our creatives used the same exact backup image asset with the same asset name (`backup_image.png` in our case). When uploading a creative asset that has the same name as another asset that already exists and belongs to that Advertiser, it appears that DCM attempts to rename the newly uploaded asset to something unique by prepending "N-" to the asset name where "N" is an integer. Through my own experimentation, it appears that DCM starts with N=1 and increments N until it finds a unique name for the creative. In the DCM UI, the name change is indicated by a notification that says "To avoid a naming conflict with another file, we changed the name of the file you uploaded."

In our case, the campaign which contains ~1,300 placements had also been creating and updating creatives so many times that one of the backup image assets recently uploaded via API was named "30956-backup_image.png" implying that we had uploaded over 30,000 of these backup image assets. My hunch is that, as we had been creating and updating more creatives (and adding more backup image assets named "backup_image.png") the DCM server, upon recognizing a duplicate asset name, began searching for an acceptable replacement name such that the time it took to do so was growing linearly with the number of times we had attempted to upload an asset by the name of "backup_image.png". So by the time this process got to around 30,000 creative names to check for duplicate asset names, the DCM API would return 500-level errors and/or our connection would timeout.

Since all the backup image assets were the same across all of our creatives, our solution was to stop creating new backup image assets whenever we created/updated a creative and instead refer to the same backup_image.png that already exists in DCM. If that isn't an option for others, another solution would be to ensure that all images are uniquely named on upload.

I understand how prepending a unique number to avoid naming conflicts makes the API easier to use, but it would be nice to mention the performance penalty of using this feature somewhere in the documentation. Perhaps in the "assetIdentifier.name" section of the CreativeAsset overview in the API documentation.

Chris

[Lakshmi Prathipati (DCM API Team)]

Hi,

Glad that you are able resolve the issue. I forwarded your request on updating the documentation to the rest of the team.