Stack Overflow has solved a similar problem using WebSockets -- most of their pages will automatically update (e.g, to display the presence of edits, new answers, and added comments) immediately using a socket.
i would think the answer is fairly obvious. 4chan needs an official API that allows for http connects to remain open. this way extension and 3rd party application developers have something to write software around that doesn't impede the ability to serve standard page GET requests to web users.
The main problem seems to be revenue. With 4chan, you could probably do a unique form of advertising -- companies pay ~$100/cpm to NOT have their products or brand featured on any 4chan pages. :)
I'd imagine that kind of adult product would perform pretty badly on 4chan. The audience is definitely not in buying mode when they're there, and it's not like most people are going there explicitly for porn, so they don't have the kind of "motivation" that drives that kind of purchase. Probably things like cool / novelty items would do better there, things that appeal to teenagers with not too much money.
I've not seen an ad on the Internet since 2006. Apparently I'm evil and I'm bringing down the economy. If that means fewer jobs in advertising I count that as a win.
Thats interesting. And 4chan had only one guy (moot) managing all of this makes it even more impressive.
By the way, some of the posters commenting on 4chan degrading morality. This is an anon forum and its just a reflection of our society! The Guardian summarized 4chan as "lunatic, juvenile... brilliant, ridiculous and alarming". Perhaps the best description for 4chan.
And remember 4chan gave us LolCats, Memes, Rage faces etc.
P.S. By the way, why did mods kill the other thread?
There's no accounting for an inconsiderate user base. This has always been a big problem for 4chan. I remember several instances where the site was effectively taken offline for days by a JavaScript virus embedded in PNG images that required the user to follow directions in the image in order to spread.
That wasn't /b/tards being inconsiderate, just mind-numbingly retarded. There's been a few JS worms like that, and it's almost always complete morons spreading them.
The point being that if 4chan users are (on the whole, anyway) too stupid to not spread JS viruses, asking them to not poll the servers so much is certainly a lost cause.
Getting the extension authors on board is probably the best option, because there's only a few of them, and they are not stupid. Stupid users don't have the skills to write broken extensions for themselves.
The only alternative would be (as others have said) to add auto-refresh JS to every page and thus bypass the need for extensions entirely. If the number of people who currently use these extensions is small enough, however, this could just as easily drive their traffic up because now every user on the site gets the same functionality without doing anything.
Image preloading and autogif are fantastic features, so getting rid of them would be a net negative. Instead, why not have them be controlled by some client side js, so that images/gifs are only preloaded for the next 20 or so posts from what the user is currently reading? If the user stops scrolling, stop preloading. Preload the final 5 or so images to cover skip-to-bottom, but the vast majority of the preloaded images will not be viewed, and so should not be loaded.
Most users' arguments to that are they open a thread, click preload images/expand images, walk away, and so when the thread is dead/they come back, they have all the posts, and the full resolution images (not thumbnails).
And the image expanding is done through userscripts/client side.
Meh, I'm always super unimpressed when simple text based websites have trouble scaling. Everything that's highly requested should be available in memory, and it should be trivial to spit it out instantly.
I'm not a scaling wizard, but I'd guess 99/100 times the reason CRUD apps have problems scaling is because they are over-engineered, and there is a tendency to solve scaling issues by adding another layer of complexity instead of optimizing the root application.
4chan is an image board. None of the content is there long enough to be considered "Highly requested.". And like half the posts have jpeg's and png's attached.
Besides, how does caching solve the "My bandwidth bills are killing my wallet!" issue?
Here's how I would scale 4chan. All static items served from s3/cloudfront. Posted images pushed to s3/cloudfront. (Or wherever filehosting is cheapest). These are all the high bandwidth items, all thats left is the text/html, which isn't that much work.
I'd argue that all of the text could be served from 1 nice box if you wanted to(multiple boxes make it more complicated but not that much more). Send the post to each box, add it to a table/indexes in memory and write the post to disk and backups for recovery purposes. Then either update and cache every page the new post affects, or mark the pages dirty and update and cache them the next time they are requested.
Done, all pages served out of memory super fast, what am I missing?
As far as bandwidth bills, most browsers observe cache settings and won't re-download what it has already downloaded. His complaint is about getting hit too hard serving the html/text not the images.
> All static items served from s3/cloudfront. Posted images pushed to s3/cloudfront. (Or wherever filehosting is cheapest).
Congratulations, you just massively blew out your bandwidth bill. The cheapest option is to host your static content yourself, especially if you're serving over a petabyte of it per month.
It really doesn't matter where you host the static/image files, as long as it's completely separate from the application server and doesn't eat into it's resources.
Yea, I see that now. He's complaining about both. Still, asking 4chan add-on developers to be courteous seems pretty silly. Gotta detect/ban/rate-limit them on the back-end.
> Notice that I say proxied and not cached. CloudFlare does not cache HTML—every connection/request for HTML is passed on to our servers, and our server must send a response.
CloudFlare is not caching his html, thus the performance problems, because his backend is probably dog-slow.
