Page 1 of 2

Best Practice for Speed?

Posted: 06 Apr 2013, 03:11
by jlangvad
What's your best advice to speed up Tiny Tiny RSS? I'm transitioning from Google Reader and I've noticed some latency on most actions. Definitely a drawback from Google Reader.

I'm hosting Tiny Tiny RSS on a server (Dreamhost) under my own subdomain. I've enabled Google Page Speed on the subdomain. Beyond this, what can I do to improve the speed all around?

Thanks,

Jacob Langvad Nilsson
http://jacoblangvad.com/

Re: Best Practice for Speed?

Posted: 06 Apr 2013, 07:04
by joseph-mx
do you mean speed up initial startup for your tt-rss?

for my setup, the initial startup take awhile and after that, everything is a breeze.

Re: Best Practice for Speed?

Posted: 07 Apr 2013, 21:17
by jlangvad
I was referring to regular day-to-day usage, not limited to initial setup. For instance, when switching between categories/folders, there's a latency of approximately 5 seconds. In Google Reader there was next to nothing.

Another issue I have is when I read through a combined feed, after a little while the feed starts over from the beginning meaning it's showing me the posts that I've already passed through and marked as read. Is this normal?

/Jacob

Re: Best Practice for Speed?

Posted: 07 Apr 2013, 21:51
by jchristi
jlangvad wrote:I was referring to regular day-to-day usage, not limited to initial setup. For instance, when switching between categories/folders, there's a latency of approximately 5 seconds. In Google Reader there was next to nothing.

The easiest thing you can do to give you a small boost is to enable gzip compression if you haven't already. There are definitely some ways to make the front-end faster but will require a lot of extra development.

jlangvad wrote:Another issue I have is when I read through a combined feed, after a little while the feed starts over from the beginning meaning it's showing me the posts that I've already passed through and marked as read. Is this normal?

I haven't noticed this but that doesn't mean it isn't a bug. Steps to reproduce?

Re: Best Practice for Speed?

Posted: 07 Apr 2013, 22:05
by Skibbi
I'm suffering similar speed issues. In my opinion most of them are related to complex SQL operations which are killing my old computer with only 512MB RAM. Unfortunately I'm not an SQL guru so I don't have any idea if it's possible to speed this up.

Re: Best Practice for Speed?

Posted: 07 Apr 2013, 22:19
by fox
Why is this in the KB? Moved.

Edit: to answer the actual question, as a best practice for speed, I would suggest not using ancient shit hardware or a gimped shitty free hosting service. That should do wonders for the performance.

Re: Best Practice for Speed?

Posted: 07 Apr 2013, 22:20
by sleeper_service
jlangvad wrote:I was referring to regular day-to-day usage, not limited to initial setup. For instance, when switching between categories/folders, there's a latency of approximately 5 seconds. In Google Reader there was next to nothing.
/Jacob


I'm sure if you throw a few billion dollars worth of servers into the back end of your tt-rss installation, it'll be just as fast as google.

speaking for myself, with my pokey little twin dual core opteron server with 16g of memory, it's snappy.

maybe two seconds from clicking on the bookmark for ttrss till it's loaded and I've got the first page, and subsecond (sometimes barely noticable) switching between categories. it may take a second for a full refresh of the 'fresh articles' special category.

check your sever load during those long waits, see if that's where your problem is.

Re: Best Practice for Speed?

Posted: 07 Apr 2013, 22:23
by fox
Personally I run tt-rss on an entry level DL160G6 w/ E5620. Works quite well.

>I'm sure if you throw a few billion dollars worth of servers into the back end of your tt-rss installation, it'll be just as fast as google.

No you see it's the unnecessarily complex SQL that is the problem. I'm sure the genius over there can simplify it, let's give him half an hour to work his magic.

Re: Best Practice for Speed?

Posted: 07 Apr 2013, 23:21
by sleeper_service
fox wrote:Personally I run tt-rss on an entry level DL160G6 w/ E5620. Works quite well.

>I'm sure if you throw a few billion dollars worth of servers into the back end of your tt-rss installation, it'll be just as fast as google.

No you see it's the unnecessarily complex SQL that is the problem. I'm sure the genius over there can simplify it, let's give him half an hour to work his magic.


how dare we run a database application, and a database, on a server... what were we thinking?

in my experience, it's often the 'unnecessarily complex' SQL that *solves* the problem... and the 'simple' (but stupid) SQL that caused the problem in the first place.

Re: Best Practice for Speed?

Posted: 08 Apr 2013, 01:50
by mirumu
tt-rss definitely doesn't need physical hardware to be fast. I run it on a virtual machine (via VPS hosting). Changing categories usually feels instant, although a big feed with lots of articles might take up to a second. the VPS has 1GB of RAM, but the server is also running quite a few other things like Postfix and Bind so ttrss won't be getting too much of that. I'm using Nginx for the web server, and PostgreSQL as the database.

Re: Best Practice for Speed?

Posted: 08 Apr 2013, 05:10
by Saliency
I run tt-rss for FREE on AWS. Easy pezzy. The micro instence is plenty fast.

Re: Best Practice for Speed?

Posted: 08 Apr 2013, 05:34
by jchristi
I'm running tt-rss on OpenShift (the free version) and it does seem to be a little slow but its tolerable.

Re: Best Practice for Speed?

Posted: 19 Apr 2013, 03:29
by jlangvad
jchristi wrote:The easiest thing you can do to give you a small boost is to enable gzip compression if you haven't already. There are definitely some ways to make the front-end faster but will require a lot of extra development.


Thanks for the tip - I've enabled gzip compression now. Haven't experienced any improvement yet, but worth a try.

My principal browser is Chrome (on a 2011 MB Air). I've actually noticed that tt-rss runs much faster in Firefox. Any idea why?

I'm using a subdomain and server on a DreamHost account.

Re: Best Practice for Speed?

Posted: 14 May 2013, 16:31
by azemon
Folks,

I am also seeing long delays (15-20 seconds) when initially loading my tt-rss page. I did a little bit of investigating to find the reason. You can do this yourself by firing up Chrome's developer tools, switching to the Network tab, and then loading your tt-rss page.

By far and away the biggest chunk of time used when loading the initial tt-rss page is loading graphics. Tt-rss loads (for me) 181 graphic images. Most of those are the icons for my feeds. All of the images are cached locally by the browser, so none of them consume any significant time but the aggregate, just to query the web server for each and get a 3xx response back, is a lot of time.

IOW, the slowness is entirely self-induced. It's not tt-rss nor is it my server. There are a couple of easy ways to "fix" it: 1) I could use the stop displaying an icon for each feed, or 2) I could subscribe to fewer feeds.

There are some harder fixes. Best would be load the icons via AJAX calls after the tt-rss page has been displayed. I just installed tt-rss on Sunday so I'm just diving into this world. I'll look at the code in a bit and see if I can figure out this change easily.

Personally, I'll live with the start-up delay.

-- Art Z.

Re: Best Practice for Speed?

Posted: 14 May 2013, 16:34
by fox
>IOW, the slowness is entirely self-induced. It's not tt-rss nor is it my server. There are a couple of easy ways to "fix" it: 1) I could use the stop displaying an icon for each feed, or 2) I could subscribe to fewer feeds.

You could also set up your server correctly to set expires header for feed icons.

>Best would be load the icons via AJAX calls after the tt-rss page has been displayed.

Oh boy.