Pomax / node-flickrapi

A node.js (and client-library) implementation of the Flickr API with oauth API key authentication and API method proxying
177 stars 52 forks source link

Flickr API slow #74

Closed tedcurrent closed 8 years ago

tedcurrent commented 8 years ago

Hey,

I don't know if this is an issue on Flickr's side, but for some reason I get very weird behaviour with this. Here's a stub from my code:

flickr.tokenOnly(flickrOptions, function(err, flickr) {
    if (err) { throw new Error(err); }
    console.log("search pictures");
    flickr.photos.search({
        text: searchParam,
        page: 1,
        per_page: 50,
        sort: "relevance",
        media: "photos",
        extras: "original_format, owner_name",
        min_upload_date: 1274745600 // 25.5.2010
    }, function(err, result) {
        console.log("got pictures");
        var photos = result.photos;
    });
});

Sometimes I get response times of around 600ms, but sometimes it's around 7000ms. I've narrowed it down to certainly be between printing "search pictures" and "got pictures". I have a callback that returns the result photos, but I have removed it as it is not relevant. First I thought maybe something is left hanging, but no. Even the first search can be slow. The searchParam is some simple text like "hammer" or "nature".

Any ideas how to get this faster?

Cheers!

/tedcurrent

Pomax commented 8 years ago

flickr will rate limit you if you do lots of calls, so that could be part of it. Are you running searches one after another?

tedcurrent commented 8 years ago

I could be running approx. 5 calls within 10 seconds. So nothing too hardcore, I assume? Of course if this is nothing you haven't encountered, I start to wonder what could be wrong with my call. Any suggestion would help.

Pomax commented 8 years ago

According to https://www.flickr.com/services/developer/api/ the rate limit is 3600 per hour, so 5 calls in 10 seconds shouldn't hit that. One thing that might be affecting it is the date filtering - but that's about it. The code looks pretty normal to me otherwise.

tedcurrent commented 8 years ago

Alright. Thanks for the reply. The date filter didn't seem to hurt the performance.

Would you happen to know if fetching from client or server affects performance? I'm fetching from server.

EDIT: Tested in browser like this:

var flickr = new Flickr({
 api_key: "XXXX"
});

flickr.photos.search({
 text: "hammer"
}, function(err, result) {
 if(err) { throw new Error(err); }
console.log(result);
});

It's just as slow. Sometimes fast, sometimes super slow.

EDIT2: So if I happen to hit a slow fetch, I can immediately throw in one or two new fetches and they might be fast and kind of replace the first call. Not ideal, but curious behaviour. I basically have a search button on a page that fetches pictures from Flickr and if I spam the button, I can skip the slow calls kind of..

Pomax commented 8 years ago

no, server vs. client should matter all that much. oauth vs api-key-only might, but again I kind of doubt it. It could be Flickr simply deciding to actually perform soft rate limiting anyway... does the browser console's profiling reveal anything?

tedcurrent commented 8 years ago
screen shot 2016-02-12 at 19 11 12

This is what I get. So most of the time is spent in waiting.. It might be some soft limiting though. I did 5 fast fetches (first fetches today) and on the sixth it jumped to 8 secs.

Simply using https://api.flickr.com/services/rest/?api_key=XXXXXX&format=json&method=flickr.photos.search&text=hammer gives odd response times. A few good ones, a few bad ones.

Pomax commented 8 years ago

I'm going to blame this on Flickr, then. Server access might be more reliable, but it sounds like Flickr doing some kind of response limiting =(

tedcurrent commented 8 years ago

Yeah it's a hundred percent them at this point. Thanks a lot for helping!

Pomax commented 8 years ago

and thanks for digging into it!