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
• 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

• 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).

[joshua-bn]

Both v2 and v3 have issues with excessive configuration setup and a lack of caching in that. Every call requires setting up all the configs again and again.

I did some profiling with xdebug profiler. If you've never used it, it's very simple https://xdebug.org/docs/profiler. Just checkout this repo: https://github.com/joshua-bn/Cloudinary-PHP-SDK-Analysis and then run the docker commands to get the output. Run your cachegrind tool of choice and view the output.

(forgive the AI generated code. I had it do this while I was working on other things)

All the test does it output 100 images (50 urls and 50 image tags)

You see, for 100 images it is calling safeImplode() 16k times. safeFilterFunc() calls strlen() 19k times - that's 190 times per image.

I use Cloudinary to output somewhere around 60 images per page. It takes longer to generate simple strings than it does to get the 48 products I'm displaying on the page from ElasticSearch.

[dannyv-cloudinary]

Hi @joshua-bn. Thanks for flagging this. I have raised a ticket internally for us to look into this in more detail (ref SNI-8453) and we will let you know the outcome