search

akrennmair / newsbeuter

Newsbeuter is an open-source RSS/Atom feed reader for text terminals.
http://www.newsbeuter.org/
MIT License
781 stars 100 forks source link

ownCloud News used with nextCloud takes 1.6 sec to mark article read #567

Open Minoru opened 7 years ago

Minoru commented 7 years ago

Reported by @protist.

Newsbeuter version (copy from newsbeuter -v): 2.10-d1c1

Steps to reproduce the issue:

  1. Configure Newsbeuter to use ownCloud News:
urls-source "ocnews"
ocnews-login "protist"
ocnews-passwordeval "python -m keyring get owncloud protist"
ocnews-url "https://protist.dynu.com/nextcloud"
  1. Try marking a bunch of articles read. It averaged to 1.6 seconds per article.

Other info you think is relevant:

The instance is not ownCloud but nextCloud. They have the same API.

protist commented 7 years ago

Just to check, does the "mark article read" function connect to the server every time? Just because it's almost instantaneous when syncing with tt-rss, so I guessed that it was just a local command.

Minoru commented 7 years ago

They both connect to server every time. TT-RSS does it through Newsbeuter's utility function utils::retrieve_url, while OwnCloud News rolls their own implementation, but as far as I can see it's all the same in the end.

protist commented 7 years ago

I'm not sure if relevant, but I thought I might try testing the following:

  1. Run newsbeuter (connected to network)
  2. Mark read
  3. Disconnect from the network
  4. Mark read

In the case of tt-rss, it was instantaneous for both 2 and 4. However, with ownCloud/Nextcloud, 2 was slow as mentioned above, but oddly enough, 4 was instantaneous…?

Minoru commented 7 years ago

I have no explanation for that :(

Minoru commented 7 years ago

I was reading our TT-RSS API code just now and found that "mark article read" is handled separately: a thread is spawned and retrieve_url is called there. This is why it's so fast in TT-RSS.

As for ownCloud being instantaneous in scenario No 4, that's probably because the DNS lookup failed and the request just never happened.

protist commented 7 years ago

As for ownCloud being instantaneous in scenario No 4, that's probably because the DNS lookup failed and the request just never happened.

Interesting. So if I understand correctly, you are saying probably what is happening in No 2 is that the first step is DNS lookup, then … some other kind of newsbeuter processing that is very slow.

I'm clarifying because I just ran the test again on my home network, where /etc/hosts points the tt-rss domain name directly to my server's internal IP address instead. This time No 2 was still slow. Hence, it's not DNS lookup itself that is slow, but presumably something that occurs after this. (I'm 90% sure that's what you meant, but just wanted to be explicit.)

Minoru commented 7 years ago

you are saying probably what is happening in No 2 is that the first step is DNS lookup, then … some other kind of newsbeuter processing that is very slow.

It's not Newsbeuter processing per se, it's a request to TT-RSS. First we do a DNS lookup to convert hostname (e.g. example.com) into an IP address (e.g. 192.0.2.1). Then a TCP connection to that IP is established. Then we do an HTTP request and get a response.

If any of the steps fail, the whole operation is aborted. That's what I meant: the operation without network is fast because it fails early and aborts.

protist commented 7 years ago

Ah right. Sorry, I should have been clearer. I was referring to the differences in No 2 and No 4, which only occurs when I use Nextcloud, not tt-rss. However, you answered my question anyway. Nextcloud is instantaneous with No 4 because the operation is aborted. Cheers.