Best Practice for Speed?

Support requests, bug reports, etc. go here. Dedicated servers / VDS hosting only
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:47

fox wrote:>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.


fox,

Setting a large expires header for feed icons would help with the performance but it implies that I, as tt-rss admin, know more about each icon's lifetime than the feeds' owners. Philosophically, I have a problem with that.

I can't tell if your "Oh boy" is snarky or a legit comment that this would be hard to do in your code (and I haven't look at your code, yet.) I was trying to help identify why so many people are complaining about the same problem. Specifically, why so many people are seeing performance which is much worse then they got with Google Reader. If you would like a hand with this, I'm glad to help out. If not, I'll stay out of your way.

Cheers,
-- 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, 17:03

Poster of the week material right there. Let's quickly run through your argument here:

1. You have no idea how to setup http servers properly for performance while rationalizing your ignorance with a completely retarded "philosophical" argument because you don't understand how expiration over http actually works
2. You don't realize that "loading icons over AJAX" is a terrible idea
3. You blindly assume that "so many people are seeing performance which is much worse" is something that actually happens and is a problem with tt-rss, not people running tt-rss on unsupported configurations and/or with software configured by largely incompetent people like yourself

And finally the best part:

4. You assume I'm the one who needs help here and offer it in a hilarously smug fashion

I don't know about you, but usually I prefer getting help A) after I asked for it, and B) from people who actually know shit. You, unfortunately, don't seem to fall into that category. So, thanks, but no thanks.

Continue posting though, if only for the entertainment value alone.

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, 17:25

fox wrote:I don't know about you, but usually I prefer getting help A) after I asked for it, and B) from people who actually know shit. You, unfortunately, don't seem to fall into that category. So, thanks, but no thanks.


fox,

Personally, I appreciate it when people offer constructive suggestions and offer to help. I get that you don't and that's OK with me. I'll bow out.

I'm sorry that you, knowing nothing about me or what I know or what I can do, consider that I don't "actually know shit." I am startled to get such a heated response to my offer but... well... whatever.

Cheers,
-- 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, 18:27

> I appreciate it when people offer constructive suggestions and offer to help.

Me too. If only you actually had anything constructive to say.

gitawego
Bear Rating Trainee
Bear Rating Trainee
Posts: 9
Joined: 08 May 2013, 00:35

Re: Best Practice for Speed?

Postby gitawego » 14 May 2013, 19:56

to speed up boot time, you can compress dojo/dijit to one file if you wish: http://dojotoolkit.org/reference-guide/ ... uild-index
better use with NodeJs, use closure as compress method, shrinksafe is less powerful.
my tt-rss is slow as well, but that's because I have thousands of feeds, and my site is built on NAS (lol). try to remove all the useless feeds :)

PS: I noticed the files are compressed, but the modules are not consumed by require, it's a bug.
@see:http://tt-rss.org/forum/viewtopic.php?f=1&t=2017

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 » 15 May 2013, 03:18

azemon wrote:
fox wrote:I don't know about you, but usually I prefer getting help A) after I asked for it, and B) from people who actually know shit. You, unfortunately, don't seem to fall into that category. So, thanks, but no thanks.


I'm sorry that you, knowing nothing about me or what I know or what I can do, consider that I don't "actually know shit." I am startled to get such a heated response to my offer but... well... whatever.

Cheers,
-- Art Z.


the thing to ask yourself is, "why is *my* setup very slow, when *most* peoples setups are fast. it only takes a couple of seconds from when I hit enter till I've got the page.

if most people were having problems, there'd be a *lot* of posts about slowness, but there aren't, there's a few. for *most* people, it works very well. what's different with yours?

Sidicas
Bear Rating Trainee
Bear Rating Trainee
Posts: 12
Joined: 15 May 2013, 14:24

Re: Best Practice for Speed?

Postby Sidicas » 15 May 2013, 14:31

Skibbi wrote: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.


Submitting complex SQL queries to the SQL server is *ALWAYS* better than a barrage of simplified queries.. Trust me.. I spent many years doing SQL query optimizations on client software because we had an SQL backend that was 10+ years old and couldn't be upgraded without massive amounts of time consuming documentation work for the government.

SQL Servers are specifically designed to optimize complex queries. The more information you cram into the query, the more likely the SQL server will find a nice optimization solution for it.

If your SQL performance is suffering, it's probably because your SQL server is misconfigured.. By default, regular Linux PCs don't have enough shared memory to keep an SQL server happy, and as a result, SQL servers get deployed with too little shared memory as their default setting.. You just bump the shared memory in /etc/sysctl.conf and in your SQL configuration and your SQL server will fly like a bird after that.

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 » 15 May 2013, 22:16

I started using tt-rss with MySQL, but number of disk I/O operations was way to big. So I switched to postgres, tweaked shared memory and there is a huge improvement. But still greader is faser ;)

graymattr
Bear Rating Trainee
Bear Rating Trainee
Posts: 24
Joined: 29 Apr 2013, 02:46

Re: Best Practice for Speed?

Postby graymattr » 02 Aug 2013, 22:18

I wanted to quickly add that I recently switched from MySQL to Postgres and am seeing a massive improvement in the performance of my instance. It feels a lot more responsive, and menus/views load much more quickly. For others who might be frustrated with slowness, I'd suggest making the switch to Postgres.

durval
Bear Rating Trainee
Bear Rating Trainee
Posts: 26
Joined: 27 Jul 2013, 13:35

Re: Best Practice for Speed?

Postby durval » 03 Aug 2013, 00:51

Hello folks,

graymattr wrote:I wanted to quickly add that I recently switched from MySQL to Postgres and am seeing a massive improvement in the performance of my instance. It feels a lot more responsive, and menus/views load much more quickly. For others who might be frustrated with slowness, I'd suggest making the switch to Postgres.


I can second that: I've used PostgreSQL for the best part of 12 years on a lot of projects, and it has never let me down, either in performance or in stability or in integrity of data. Although not personally bitten by MySQL, I've seen more than a few people being hit by all those problems and them some.

True to this, I've installed my TT-RSS instance running PostgreSQL 8.4 on EL6, and I could not be happier with it: very fast (less than 2 seconds from entering credentials at login screen to main screen with about 130 feeds), and no issues at all.

Why people insist on using MySQL is beyond me... :-)

Cheers,
--
Durval.


Return to “Support”

Who is online

Users browsing this forum: No registered users and 8 guests