Better implementation

Ok, first time I post here.
I want to write down my own imageboard program, just for the heck of it, and I am in a dilemma.
The way I had thought of it, I would have a single "content" file, that would be dynamic, and all the content would be generated within it.
However when I looked into futallaby for reference, the way they do it, is that there is no main "content" page, all pages are genereted within the script but are then dumped and delivered as static  html pages.
So, I want to axe you this question:
>Which way do you think its a better implementation?

>OP is a faggot

P.S. The imageboard I want to create will depend on a database, by the way.

Databases are crap.

Why would you want to quote "Which way do you think its a better implementation?"? That doesn't make sense and you didn't even do it right.

Generating the content on the fly might be a bit harsh on your server, but it should make things more flexible, but things will go to shit more quickly. Personally, I'd go for a static approach.

>>3
as I said, it's the first time I write here, actually I did not even know this board existed up until 15' ago, when I accidentally discovered it.

>>4
Oh well. But please don't quote shit nobody has said before.

>>5
I was going for greentext, but apparently you work in different ways than the rest of 4chan, /prog/

Ok, OP here again, let me know if my stupid head got it right:

If the content is delivered dynamically, that means that the server has to execute the script and access the database for every single visit to the board. Not so much of a strain for little to no traffic sites, but will certainly be if said site has a certain amount of traffic.

If, on the other hand, the content delivery is done via static html pages, the only times when the server will have to execute the scripts and access the database is when somebody actually posts, which, again, will certainly relieve the server if the site has high traffic, but won't make much difference for small sites.

Excuse my reek of noobishness, I just try to understand. You all begun from somewhere.

>>5
Why would you assume he was quoting. His question clearly reads ``Greater than which way do you think its a better implementation?''

>>6                                       `
>implying

>>8
>impspeakingthetruth

>>9
Imps always lie. Read your Malleus Maleficarum.

>>6
``Greentext" is something only imageboard retards do.

>>8
Greater than implying?

Generate dynamically, but use memcached.

>>12
I'll look into it. Since you are not trolling, may I ask you if things are as I understand them in >>7  ?

>>13
Yeah, that's all right and good. Generating dynamically for every request is never a great idea. Generating new static pages for every post is much faster, but it seems wasteful to me.

Say you don't prune threads and eventually you have 50+ pages. The last page changes with every post, but nobody ever looks at it. For every revision of the last page anyone ever sees, you've generated maybe hundreds of them.

memcached let's you save a generated page in memory. It works like this:
* anon 1 visits page 1
* page 1 is not cached, so page 1 is generated and cached
* anon 2 visits page 1
* page 1 is cache so the cache is loaded
* anon 1 posts to thread 1
* the cache for thread 1 is cleared
* because thread 1 is on page 1, cache for page 1 is cleared
* anon 1 is redirected to thread 1
* thread 1 is not in the cache, so thread 1 is generated and cached
* anon 2 visit thread 1
* thread 1 is cached so cache is loaded
* anon 1 goes back to page 1
* page 1 is not cached so it's generated and cached

And so on. The more visitors you have the less cache misses.

Static files can be cached easily and serving them requires not much more than bandwidth. Dynamically generating the content on each request requires CPU resources and possibly database queries.

Now ask yourself what an imageboard will receive more of, GETs or POSTs.

The choice is obvious.

>>14

the idea is simple enough, but an elegant and general implementation would be nice to see. When a new post is made, the page cacher will need to know which of the cached dynamic pages are invalidated, and to mark them as dirty. This relationship is dependent on the structure of the website, so it will either need to be well described or inferable. A pattern based rule system would probably suffice.

OP I have thought about this before. What you might want to do is use Redis as your data store, and dump 404 threads as static HTML to an archive dir.

>implying http://54.245.123.189/190chan/ isn't the perfect implementation
just add some binary blob columns and html form file uploads and it's an imageboard too
your board is never going to get enough traffic to warrant redis or some other hipster ``performant'' shite