core: Probabilistic and Logarithmic update of view counts

0 votes

Vote

Raised 0% of 12 credits
(12 credits = 2 hours or $85.08)

Composr maintains various view counts (topic view counts, banner view counts, etc).

Writing to these each view has a performance impact. It should be a very small impact - but on InnoDB they have to do ACID redo logging in ib_logfile0 and ib_logfile1, multiplying the work needed. On a busy site with a s…

Suggested by Chris Graham on Wed

core: Re-review all indexes

0 votes

Vote

Raised 0% of 18 credits
(18 credits = 3 hours or $127.90)

Review all indexes in the system...

1) Is each necessary? Document why with a code comment. If not, remove (as indexes use disk space and slow writes).
2) Is *sorting* covered on a single index. For example, ideally an index on a category ID will also have a secondary index column on the timestamp, so…

Suggested by Chris Graham on Tue

core: Cache warm up via Cron

0 votes

Vote

Raised 0% of 180 credits
(180 credits = 30 hours or $1,278.97)

Initial installs may seem slow because initial caches are not populated.
Additionally, future use may seem slow if some resource is accessed but the cache is expired.

These caches could easily be populated in the background (in this priority order):
- Language file cache
- Template cache
- Comcod…

Suggested by Chris Graham on Tue

core: Opportunistic scheduler

0 votes

Vote

Raised 0% of 24 credits
(24 credits = 4 hours or $170.53)

Some background Cron hooks are not very time critical, but may have a performance impact. Ideally we would run these hooks only when the server is under low load.

Code in a detector function to find if the server is under 'low load', based on I/O load, CPU usage (uptime command on Linux), and memory usa…

Suggested by Chris Graham on Tue

core: Support for descending indexes

0 votes

Vote

Raised 0% of 30 credits
(30 credits = 5 hours or $213.16)

MySQL 8 adds support for descending indexes.

This is particularly relevant for indexes where we sort by descending timestamps (e.g. viewing in a forum).

It improves index performance by about 15%, avoiding the 'Backward index scan'. I'm not sure exactly why a backward index scan is slower, because a…

Suggested by Chris Graham on Mon

installer: Graceful handling if PHP is not installed

0 votes

Vote

Raised 0% of 6 credits
(6 credits = 1 hour or $42.63)

If PHP is not installed, launching install.php creates a redirect loop, due to <meta> redirects in the code.

At minimum stop this by obfuscating the embedded HTML a bit.

Ideally though, there'd be some kind of message saying PHP should be installed.

Suggested by Chris Graham on Mon

core: AJAX session generation / httponly session ID

1 vote

Vote

Raised 0% of 30 credits
(30 credits = 5 hours or $213.16)

This issue is to solve a few distinct issues:

1) We cannot have the session ID as httponly as it is used as an ad-hoc CSRF token (getCsrfToken function).
2) CSRF tokens may expire which is poor user experience (for example, a form is opened, a user goes to sleep, and submits it the next day - but the t…

Suggested by Chris Graham on 15th November 2019

core: Option to bypass SMTP relay server

0 votes

Vote

Raised 0% of 96 credits
(96 credits = 16 hours or $682.12)

E-mail is implemented in a complicated way, more complicated and error prone than it needs to be for our situation.

A mail client connects to an SMTP relay server (smarthost), and the message goes into that server's queue - and that server then connects to the recipient's SMTP server (or another relay,…

Suggested by Chris Graham on 7th November 2019

core_webstandards: Proper regexp parsing

0 votes

Vote

Raised 0% of 6 credits
(6 credits = 1 hour or $42.63)

We parse regexp's with the assumption that any '/' that is not escaped closes the regexp.

This seems like a reasonable assumption, but is not true within character class definitions (square brackets).

Currently we just enforce that even within character classes, slashes must be escaped.

Ideally th…

Suggested by Chris Graham on 29th October 2019

core_webstandards: Further JS validation

0 votes

Vote

Raised 0% of 24 credits
(24 credits = 4 hours or $170.53)

I think currently for Composr internal validation we are not doing API checks, otherwise it'd be failing because there are a lot of JS core functions available since the JS validation code was written.

Ideally we'd rebase the JS API to what is in our minimum IE/Edge version, and re-enable.

Suggested by Chris Graham on 29th October 2019