cjyabraham

Just to add… this trace is being triggered by a custom block I wrote that has a server-side callback to render the output for the block. So each page load runs this callback function.

In the callback function I call get_the_post_thumbnail for each SVG logo in our sponsors section of the page. So that is why it causes this on front-end of the site. Is there a way to get the url for the image without having to trigger the costly svg_dimensions function call?

Daryll,
Thanks for taking a look at this. Here is the stack trace caused when loading a page on the front-end of the site. Does that help?

Chris

Hi Daryll,
Any updates on improving the speed of svg_dimensions. For our page here, because we have so many svgs, it’s often increasing load time by 4s or more.

Thanks,
Chris

The tracer we are using is New Relic. It is totally possible that it is inaccurate, so that’s worth considering.

In the timings I included above, there is one getInfo call which took 2.3s, so maybe there are some which do go to 4s, though I haven’t been able to produce one manually.

Hmm, I’ll keep an eye on it during the next few days and see if I can glean anything new.

Thanks,
Chris

Ok, great. I’ll keep an eye out for updates to the plugin. Thanks!

Thanks for the quick response. The Photonic gallery is set to pull “Photos from an Album/Photoset”. Here is a breakdown of the timing of the page load. And here is part of the trace. For some reason it is taking over 4s to return the REST call.

I turned on the performance logging and most of the time I get numbers like this:

Stats for Provider: flickr, Gallery: 1
	Event: Get gallery images, Start: 1590550782.4517, End: 1590550782.9277, Time: 0.47599601745605
		Event: Nested call flickr.photos.getInfo, Start: 1590550782.4518, End: 1590550782.727, Time: 0.27523398399353
			Event: Make call (flickr.photosets.getInfo), Start: 1590550782.4518, End: 1590550782.7267, Time: 0.27493906021118
			Event: Process response, Start: 1590550782.7268, End: 1590550782.727, Time: 0.00023913383483887
		Event: Nested call flickr.photos.getInfo, Start: 1590550782.727, End: 1590550782.9277, Time: 0.20071196556091
			Event: Make call (flickr.photosets.getPhotos), Start: 1590550782.7271, End: 1590550782.9266, Time: 0.19955897331238
			Event: Process response, Start: 1590550782.9267, End: 1590550782.9276, Time: 0.00091195106506348
				Event: Generate level 1 gallery, Start: 1590550782.9271, End: 1590550782.9276, Time: 0.00053906440734863

However, I do occasionally seem to get higher numbers like this:

Stats for Provider: flickr, Gallery: 1
	Event: Get gallery images, Start: 1590550680.8086, End: 1590550683.3214, Time: 2.512806892395
		Event: Nested call flickr.photos.getInfo, Start: 1590550680.8087, End: 1590550683.1227, Time: 2.3140649795532
			Event: Make call (flickr.photosets.getInfo), Start: 1590550680.8087, End: 1590550683.1225, Time: 2.3138358592987
			Event: Process response, Start: 1590550683.1225, End: 1590550683.1227, Time: 0.00017595291137695
		Event: Nested call flickr.photos.getInfo, Start: 1590550683.1227, End: 1590550683.3214, Time: 0.19868302345276
			Event: Make call (flickr.photosets.getPhotos), Start: 1590550683.1227, End: 1590550683.3204, Time: 0.19769883155823
			Event: Process response, Start: 1590550683.3205, End: 1590550683.3214, Time: 0.00093221664428711
				Event: Generate level 1 gallery, Start: 1590550683.3208, End: 1590550683.3214, Time: 0.00057291984558105

You can see the stats on this page, however, it’s behind a cache so they likely won’t update when you refresh.

I think the trick is you have to keep the IDs the same of the users so that they can corresponding with the correct image directory. Try exporting/importing the users while keeping the same IDs.

Hi Alvaro,
Just a note, my workaround for now was to use markdown notation for links and then to use a preg_replace:
https://github.com/LF-Engineering/lfevents/pull/525/files#diff-3992ce031aa5b37085c3742aa4da0b1fR830

It works great so just wanted to leave that here in case anyone else needed it.

Chris

Great. Thanks for the help with this.

Thanks again Sybre for taking the time to figure this out for me.
Chris

Thanks for the update. I’ll look out for the release.

It worked. Thanks for helping me get to the bottom of this.

So Pantheon recommends using this code to exclude specific REST API paths from the cache: https://pantheon.io/docs/mu-plugin#wp-rest-api-code-classlanguage-textwp-jsoncode-endpoints-cache

Do you know offhand which API calls I need to exclude for Post Meta Controls?
Maybe this regex?
#^/wp-json/post-meta-controls/v1/?#

• This reply was modified 4 years, 9 months ago by cjyabraham.
• This reply was modified 4 years, 9 months ago by cjyabraham.
• This reply was modified 4 years, 9 months ago by cjyabraham.

Hold on. I just deleted the Pantheon MU plugin from the above instance and now the test works fine. The meta values appear as they should. So something in the Pantheon MU plugin is causing this issue. I will investigate further.

I just replicated your test. I setup a brand new sandbox Pantheon site with only three plugins:
– Post Meta Controls v 1.3.1
– LFEvents MU plugin
– Pantheon MU plugin

I performed the steps and the test did not work. That is, when I entered meta values into a new Event, navigated to the Events listing and then back to the new Event, the meta values did not show up. They only show up when I do a hard-refresh of the browser.

Can you confirm that this was the test you performed?

Here is a video showing the instance: https://drive.google.com/open?id=1AlBRFiYuaw541-MLvxlQBMq1NXcFJi9v

Not sure if it matters but I’m using Chrome v 80.0.3987.106