Best Practice for Speed?

Support requests, bug reports, etc. go here. Dedicated servers / VDS hosting only
jlangvad
Bear Rating Trainee
Bear Rating Trainee
Posts: 5
Joined: 04 Apr 2013, 17:26

Best Practice for Speed?

Postby jlangvad » 06 Apr 2013, 03:11

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/

joseph-mx
Bear Rating Disaster
Bear Rating Disaster
Posts: 68
Joined: 19 Oct 2012, 05:19
Location: http://www.mxhub.com/reader/
Contact:

Re: Best Practice for Speed?

Postby joseph-mx » 06 Apr 2013, 07:04

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.

jlangvad
Bear Rating Trainee
Bear Rating Trainee
Posts: 5
Joined: 04 Apr 2013, 17:26

Re: Best Practice for Speed?

Postby jlangvad » 07 Apr 2013, 21:17

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

jchristi
Bear Rating Trainee
Bear Rating Trainee
Posts: 17
Joined: 03 Apr 2013, 21:18

Re: Best Practice for Speed?

Postby jchristi » 07 Apr 2013, 21:51

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?

User avatar
Skibbi
Bear Rating Disaster
Bear Rating Disaster
Posts: 61
Joined: 15 Mar 2013, 14:59
Location: Poland

Re: Best Practice for Speed?

Postby Skibbi » 07 Apr 2013, 22:05

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.

User avatar
fox
^ me reading your posts ^
Posts: 6318
Joined: 27 Aug 2005, 22:53
Location: Saint-Petersburg, Russia
Contact:

Re: Best Practice for Speed?

Postby fox » 07 Apr 2013, 22:19

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.

User avatar
sleeper_service
Bear Rating Overlord
Bear Rating Overlord
Posts: 884
Joined: 30 Mar 2013, 23:50
Location: Dallas, Texas

Re: Best Practice for Speed?

Postby sleeper_service » 07 Apr 2013, 22:20

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.

User avatar
fox
^ me reading your posts ^
Posts: 6318
Joined: 27 Aug 2005, 22:53
Location: Saint-Petersburg, Russia
Contact:

Re: Best Practice for Speed?

Postby fox » 07 Apr 2013, 22:23

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.

User avatar
sleeper_service
Bear Rating Overlord
Bear Rating Overlord
Posts: 884
Joined: 30 Mar 2013, 23:50
Location: Dallas, Texas

Re: Best Practice for Speed?

Postby sleeper_service » 07 Apr 2013, 23:21

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.

mirumu
Bear Rating Trainee
Bear Rating Trainee
Posts: 1
Joined: 08 Apr 2013, 01:25

Re: Best Practice for Speed?

Postby mirumu » 08 Apr 2013, 01:50

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.

Saliency
Bear Rating Trainee
Bear Rating Trainee
Posts: 49
Joined: 27 Mar 2013, 20:05

Re: Best Practice for Speed?

Postby Saliency » 08 Apr 2013, 05:10

I run tt-rss for FREE on AWS. Easy pezzy. The micro instence is plenty fast.

jchristi
Bear Rating Trainee
Bear Rating Trainee
Posts: 17
Joined: 03 Apr 2013, 21:18

Re: Best Practice for Speed?

Postby jchristi » 08 Apr 2013, 05:34

I'm running tt-rss on OpenShift (the free version) and it does seem to be a little slow but its tolerable.

jlangvad
Bear Rating Trainee
Bear Rating Trainee
Posts: 5
Joined: 04 Apr 2013, 17:26

Re: Best Practice for Speed?

Postby jlangvad » 19 Apr 2013, 03:29

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.

azemon
Bear Rating Trainee
Bear Rating Trainee
Posts: 3
Joined: 14 May 2013, 16:17
Contact:

Re: Best Practice for Speed?

Postby azemon » 14 May 2013, 16:31

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.

User avatar
fox
^ me reading your posts ^
Posts: 6318
Joined: 27 Aug 2005, 22:53
Location: Saint-Petersburg, Russia
Contact:

Re: Best Practice for Speed?

Postby fox » 14 May 2013, 16:34

>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.


Return to “Support”

Who is online

Users browsing this forum: No registered users and 14 guests