Plan caching to minimize server load (SSR, etc.) #422

New issue

Open

opened 2018-04-24 22:18:59 +02:00 by bones7242 · 5 comments

bones7242 commented

2018-04-24 22:18:59 +02:00

(Migrated from github.com)

Currently spee.ch is not doing any caching (other than what express.js does natively out of the box. Spee.ch should cach rendered versions of pages so it doesn't have to do SSR tasks, MYSQL lookups, etc. repeatedly.

Currently spee.ch is not doing any caching (other than what `express.js` does natively out of the box. Spee.ch should cach rendered versions of pages so it doesn't have to do SSR tasks, MYSQL lookups, etc. repeatedly.

bones7242 commented

2018-05-24 19:26:52 +02:00

(Migrated from github.com)

One option for caching, using redis: https://www.npmjs.com/package/express-redis-cache

bones7242 commented

2018-05-24 19:30:26 +02:00

(Migrated from github.com)

@lyoshenka also mentioned https://varnish-cache.org/ which sits in front of the web server

bones7242 commented

2018-05-24 19:32:27 +02:00

(Migrated from github.com)

one issue for caching, raised by @skhameneh, is that SSR of page may need user session data.
This is currently solved by serving the site without a logged in guest, and having the client make an api call to update the redux state with any logged in user data.

one issue for caching, raised by @skhameneh, is that SSR of page may need user session data. This is currently solved by serving the site without a logged in guest, and having the client make an api call to update the redux state with any logged in user data.

bones7242 commented

2018-05-24 23:10:26 +02:00

(Migrated from github.com)

another issue with caching is that the same url (e.g. https://spee.ch/xyx/doitlive.jpg) could be one of two types of request: (a) a request from a user that wants to view the asset in a web browser, or (b) a direct request for the asset from a page in which the asset is embeded.
@lyoshenka suggested redirecting embed requests to a slightly different url (e.g. `https://spee.ch/embed/xyz/doitlive.jpg')

another issue with caching is that the same url (e.g. `https://spee.ch/xyx/doitlive.jpg`) could be one of two types of request: (a) a request from a user that wants to view the asset in a web browser, or (b) a direct request for the asset from a page in which the asset is embeded. @lyoshenka suggested redirecting embed requests to a slightly different url (e.g. `https://spee.ch/embed/xyz/doitlive.jpg')

skhameneh commented

2018-05-29 06:59:48 +02:00

(Migrated from github.com)

@billbitt cached responses should honor limited header data.
Ideally the cache, by default, should only store calls that don't contain session information.

Caches can exist at (some examples):

Thread level
Machine-level (VM/server, separate thread or same-machine redis/memcache)
Cluster level (external Redis, Memcache, etc)
Client-side

@billbitt cached responses should honor limited header data. Ideally the cache, by default, should only store calls that don't contain session information. Caches can exist at (some examples): 1. Thread level 2. Machine-level (VM/server, separate thread or same-machine redis/memcache) 3. Cluster level (external Redis, Memcache, etc) 4. Client-side

This discussion has been locked. Commenting is limited to contributors.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: LBRYCommunity/spee.ch#422

No description provided.

Rows
Columns