expand/CCash
1
0
Fork 0
mirror of https://github.com/Expand-sys/CCash synced 2026-03-22 20:47:10 +11:00
Code Issues Projects Releases Packages Wiki Activity Actions

📚🚧

Browse source
This commit is contained in:
EntireTwix 2021-07-15 20:00:59 -07:00
parent c11bf24d90
commit 018e8dac83
1 changed files with 14 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

24
docs/features/implementation.md
View file

@ -1,26 +1,30 @@
[PREVIOUS PAGE](user_side.md) | [NEXT PAGE](../building.md) [PREVIOUS PAGE](user_side.md) | [NEXT PAGE](../building.md)
# Implementation Features # Implementation Features
## Multi-threading support
## Parallel Hashmap ## Parallel Hashmap
<!-- memory vs database --> <!-- memory vs database -->
<!-- and while changes arent made on the basis of speed alone it does seem to fit the problem better as we only need to save every `n` minutes/on close. -->
<!-- phmap vs std hash map --> <!-- phmap vs std hash map -->
<!-- benefits from multi-threading --> this parallel hashmap implementation is the basis of CCash, its where all the user data is stored, compared to the STD's `std::unordered_map<T>` its much faster, this, multi threading support, and more can be found in the [writeup](https://greg7mdp.github.io/parallel-hashmap/).
<!-- https://greg7mdp.github.io/parallel-hashmap/ -->
### Scalability ### Scalability
below is `GetBal()` being called where `x` axis grows with # of users reaching 10 million users, `y` axis is time in ns. The name given is random between 0 and max users at that time as to provide more accurate results below is `GetBal()` being called where `x` axis grows with # of users reaching 10 million users, `y` axis is time in ns. The name given is random between 0 and max users at that time as to provide more accurate results.
![image](GetBal().png) ![image](GetBal().png)
as the graph demonstrates, regardless of size GetBal remains consistent at around 39ns on my 3700x single threaded. as the graph demonstrates, regardless of size GetBal remains consistent at ~39ns on my 3700x single threaded.
## xxHash ## [xxHash](https://github.com/Cyan4973/xxHash)
## Base64 xxhash is used for both hashing of passwords for storage aswell as the usernames for indexing the phmap.
## Simdjson ## [Base64](https://github.com/aklomp/base64)
base64 decoding is required for Basic Auth so I used this clean and fast solution found [here](https://github.com/aklomp/base64) which uses SIMD.
## [Simdjson](https://github.com/simdjson/simdjson)
simdjson was the fastest JSON parsing I could find, I found its SIMD and OnDemand parsing attractive so its used for request parsing.
## Drogon webframework ## Drogon webframework
at the time of making this doc Drogon is the 3rd fastest web framework as per [this](https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=composite) sites metric of measuring web frameworks, it also has multi threading support.
## Intelligent saving ## Intelligent saving
### Saving on close ### Saving on close
when the program is interupted with CONTROL + C it will save before closing the webserver, **it will not however save during a crash**. when the program is interupted with CONTROL + C it will save before closing the webserver, **it will not however save during a crash**.
### Auto Saving ### Auto Saving
every `x` minutes, a configurable amount at launch, CCash will save. every `n` minutes, a configurable amount at launch, CCash will save.
### Changes ### Changes
for the above two cases, it will only save if changes have been made since last commit. for the above two cases, it will only save if changes have been made since last commit.
## Multi-threading support
## Backwards Compatible API ## Backwards Compatible API
versioning is implemented by the endpoints path, for example `/v1`. Breaking changes will ideally be sparse and backwards compatability will be maintained, for example ideally API `v3` instance can still run `v1` endpoints versioning is implemented by the endpoints path, for example `/v1`. Breaking changes will ideally be sparse and backwards compatability will be maintained, for example ideally API `v3` instance can still run `v1` endpoints.