Skip to content

Future of Infinity Next...? #245

Closed
milezzz opened this Issue · 5 comments

4 participants

@milezzz

I've been following this project closely since mid 2015 and was sadface.jpg to see it implode this year. I've worked more than most with the codebase and found it to be pretty good overall, but as with most PHP applications, it suffers from high CPU usage when under load. I know this because I'm one of the few people who actually bothered load testing it, and had been suggesting others do so as far back as Oct 2015.

That said, I'd honestly hate to see all this good work go to the dust bin. I think Josh did a lot of innovative things with Next and it deserves to live on in some form. Like him or hate him, he was dedicated to the project and other than being an asshole occasionally and calling Freddy a hobgoblin, he seemed to really want this to succeed.

We ran some tests again last night in #8chan-dev and came away with the same conclusions:

  • 8 cores/4GB - freeBSD + pgsql + php7-fpm + redis w/ 8 php-fpm workers: http://pastebin.com/hk7eQRPm

  • OdiliTime: The memory footprint is acceptable at around 50mb / worker. Next handles the DB side well but the fragment caching is where it fails.

  • We maxxed out at 10 request per second per core. We need to hit around 25 r/s. We tried to pull the latest commits that fix the captcha issue but composer update breaks (again). We'd love to run these tests with Josh's latest code and his chosen platform (come find milez or odilitime in #8chan-dev Josh or we can do it privately).

  • It seems obvious Next needs another cache layer aside from the current Laravel cache. I think this would save Next. Josh seemed to implement Varnish on some parts of Next but this seems to have been scrapped...?

  • The community and donators deserves some type of update on where this software is going.

  • MIT license or GTFO.

@jaw-sh
@interjection

I will enforce my licensing.

I don't understand this bit. Is it implying that the act of having a users browser fetch from their softserve endpoint, which is proprietary on the backend, constitutes a violation of the AGPL? Or just that you will want their changes to the codebase itself public?
It shouldn't be too hard to build an abstraction for advertisements so admins wouldn't even have to modify widgets/ads/* and you could even have multiple ad provider options, all of this stored in the database and cached of course. Perhaps I don't really understand what they're worried about.

You are right to be pissed off about the burnt bridge. But, on the other hand, the application is a bit hard to cache with the choices made and Laravel's sessions. The simplest way forward I see is caching anonymous and forcing mods over an additional /cp/ endpoint, no?

@odilitime

@milezteg brought up the future of next, and @jaw-sh you focused on 8chan. Are you saying there is no future of Next without 8ch? Because there are plenty of other chans interested in the software. Let's please focus on the technical issues and keep the drama of the past out of this.

I agree with @interjection's technical assessment of the caching the anonymous. It's a great place to start until the session crap can be finely tuned and handled more carefully.

@interjection

@odilitime https://github.com/HaiFangHui/sessionmonster looks promising as well, although it might need updated for Laravel 5

@jaw-sh

Okay. It's time to keep going.
@interjection I'm interested in seeing your work. Keep in touch mate.

@jaw-sh jaw-sh closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.