BIG DICK CACHING SYSTEM

So, check out the caching system I have been iterating upon for a year or so now:1: master process starts. This master process does 2 things that matter for this subject: first it listens on a unix socket, second it starts worker processes.2: worker processes serve http requests. These processes check if they have the page on their own cache. They won't have at this point, since we just booted everything. So they ask for the master process for it, through the unix socket.3-1: master process doesn't have it either at this point, so they return with a 404 to the worker process.4: worker process notices the master process didn't had it either. It notices also this is the first check, so it builds the page and send it back through the unix socket to the master process to cache it instead of serving a 404. Then serves it to the user, in the meanwhile it also stores in it's own cache the content being served.5-1: this is a subsequent request on the same worker process. The worker process checks if it contains the page on it's own cache. It does. So it checks against the master process if this cache changed through the unix socket. Let's say it didn't, so all that's returned is a response 304 to the worker, without the actual content, naturally.6: worker process then proceeds to either serve a code 200 and return the data or just serve a code 304 if the user have already seen it.5-2: In this scenario, the cache did change in the master process. So it serves the content being returned and caches it again. Step 6 happens as usual.3-2: In this scenario, the master did had the cache. So the worker return either a 304 or a 200, skip step 4 and go to step 6, caching it itself if it's a code 200 with the content.Source: https://gitgud.io/LynxChan/LynxChan/blob/master/src/be/engine/cacheHandler.js

Submitted August 20, 2019 at 03:18AM by RobertCougar