Noticeably reduced performance with version 2

[dwightwatson]

Bug report for Cloudinary PHP SDK

Before proceeding, please update to latest version and test if the issue persists

Describe the bug in a sentence or two.

After upgrading to the new PHP SDK (from 1.x to 2.x) I noticed our 50th percentile drop considerably. I isolated the change and reverted back to 1.x and saw my response times go back to where they were previously. Unfortunately New Relic wasn't running correctly so I didn't manage to capture any better metrics.

I've opened this issue to see if anyone else has noticed similar issues. I would not have expected simply upgrading Cloudinary to have an a noticeable impact on response time. Additionally - we only use the PHP SDK for URL generation, not for uploading assets or anything, so it should be pretty negligible.

Issue Type (Can be multiple)

• [ ] Build - Can’t install or import the SDK
• [x] Performance - Performance issues
• [ ] Behaviour - Functions aren’t working as expected (such as generate URL)
• [ ] Documentation - Inconsistency between the docs and behaviour
• [ ] Other (Specify)

Operating System

• [x] Linux
• [ ] Windows
• [ ] macOS
• [ ] All

Environment and Frameworks (fill in the version numbers)

• PHP Cloudinary SDK version - 2.0.2
• PHP Version - 8.0.2
• Framework (Laravel, Symphony, etc) - 8.27.0

[const-cloudinary]

@dwightwatson thank you for reporting the issue!

We did run some performance checks on the new version, for example we took this transformation: https://cloudinary.com/documentation/php1_image_manipulation#adding_text_and_image_overlays

And ran it 10000 times in a loop.

On my computer it took: v1 : 2.422s v2: 2.657s

You can see some performance decrease of around 10% for just generating the transformations.

Is that the difference you are experiencing?

If you could provide more details, maybe send a few typical transformations that you use, we could investigate it further.

[dwightwatson]

I'm not entirely sure - I'm waiting on New Relic to get back up and running so I can crunch the numbers there, otherwise I'll see if I can replicate locally. I thought it was worth opening an issue just in case it was a more widespread problem. My use-case is literally just generating signed URLs so I'm surprised there would be any performance change.

[grubersjoe]

We also face this issue. In some payloads we generate lots of image URLs (like several hundreds) and v2 seems to worsen performance considerably. We're also a bit confused why supposedly simple string transformation takes so much time...

[atdcloud]

@grubersjoe Just checking if you can share a code snippet so that we can test it on our end.

[dwightwatson]

I ended up biting the bullet and moving to v2 regardless because of the deprecation warnings from v1. Also realised that using signed vs non-signed URLs was a performance drain (makes sense in hindsight but disappointing nonetheless).