performance of flickr call?

Since Photonic pulls information live from a source, it doesn’t come with any inbuilt cache settings.

That being said, I have never seen it take more than 0.6-0.7 seconds for a Flickr round-trip, unless it was trying to fetch a collection (Flickr’s Collection API is rather poorly written and requires multiple calls to fetch information). Can you point me to a page on your site where you are seeing slowness? The page you have linked doesn’t seem to have a Flickr gallery. Also, can you select the option Photonic → Settings → Generic Options → Advanced → Performance Logging? That will print performance statistics in HTML comments and will help me understand which call is taking time.

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.

Is it possible that the tracer you are using is buggy? I ask because the stats that Photonic prints are at the beginning and end of each call – the script literally sets a start time before making the call and a finish time once the call returns, and then calculates the difference. In very rare cases do the timings exceed 1s (you can try this out without caching too). This is also reflected in the page load time – the main time is spent in painting the content, while the time taken to fetch the data from Flickr itself is quite low.

In your case, Photonic is saying that the time taken < 1s, but the tracer is saying that Photonic has taken > 4s, which is puzzling. Do you have instances of the same call showing dramatically different times? Obviously, it is entirely possible to have the occasional call take long – this typically happens if there is a heavy load on the calling server or on the network to Flickr. But that is true with any network interface, and is more the exception rather than the norm. And, in such cases, the times shown by Photonic and the tracer should be pretty close.

If you are using a free plugin to run the trace let me know and I can try installing it at my end to see what is going on with it.

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