Lemmy Project Priorities Observations

5 readers

1 users here now

I've raised my voice loudly on meta communities, github, and created new [email protected] and [email protected] communities.

I feel like the performance problems are being ignored for over 30 days when there are a half-dozen solutions that could be coded in 5 to 10 hours of labor by one person.

I've been developing client/server messaging apps professionally since 1984, and I firmly believe that Lemmy is currently suffering from a lack of testing by the developers and lack of concern for data loss. A basic e-mail MTA in 1993 would send a "did not deliver" message back to message sender, but Lemmy just drops delivery and there is no mention of this in the release notes//introduction on GitHub. I also find that the Lemmy developers do not like to "eat their own dog food" and actually use Lemmy's communities to discuss the ongoing development and priorities of Lemmy coding. They are not testing the code and sampling the data very much, and I am posting here, using Lemmy code, as part of my personal testing! I spent over 100 hours in June 2023 testing Lemmy technical problems, especially with performance and lost data delivery.

I'll toss it into this echo chamber.

founded 1 year ago

MODERATORS

[email protected]

2023-08-22 (bulletintree.com)

submitted 1 year ago by [email protected] to c/[email protected]

2 comments fedilink hide all child comments

Unbelievable today the push-back on filtering by what is in-essence, the entire key to lemmy - published date

top 2 comments

sorted by: hot top controversial new old

[–] [email protected] 1 points 1 year ago

I presented a per-computed post_aggregates.inclusion column design as a temporary measure… I did all the leg work…

Aging out the data is essential. There seems to not be a realization that Lemmy works OK with 25,000 posts in it, but you have to tell PostgreSQL that you only really want what is fresh meat for end-users to read! published date is fundamental to the entire Lemmy experience, NEW posts start with 1 vote, and popularity starts with FRESH postings. Why do I have to keep saying this out loud when the PostgreSQL design of Lemmy ignores it!

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

And caching, from MAY 17, 2010 Reddit: "Everything on Reddit is a listing: the front page, in box, comment pages. All are precomputed and dumped into the cache. When you get a listing it’s taken from the cache. Every link and every comment is probably stored in a 100 different versions. For example, a link with 2 votes that’s 30 seconds old is rendered and cached separately. When it hits 30 seconds it’s rendered again. And so on. Every little piece of HTML comes from cache so the CPU isn't wasted on rendering. When things get slow just add more cache."

The avoidance of caching and pre-generated is beyond unbelievable in Lemmy Servers crashing constantly, servers not able to cope with what I consider a small number of users... and the constant avoiding of caching and per-generating. Even for 30 seconds!! You can have front-end machines per-generating those pages, a post-production layer to front the API.