logos-co
/
roadmap
mirror of https://github.com/logos-co/roadmap.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Some corretions

This commit is contained in:
fryorcraken.eth 2023-10-11 14:14:37 +11:00
parent bf6e9770c9
commit 15b44166c3
No known key found for this signature in database
GPG Key ID: A82ED75A8DFC50A4
1 changed files with 9 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
content/waku/updates/2023-10-09.md
View File

@ -13,13 +13,12 @@ draft: false
- _achieved_: /admin Rest API endpoint implemented - _achieved_: /admin Rest API endpoint implemented
- _next_: Restructure openapi descriptions and producing swagger ui like live document of all rest interfaces. Restructure Rest API schema types. - _next_: Restructure openapi descriptions and producing swagger ui like live document of all rest interfaces. Restructure Rest API schema types.
- _blocking_:
**[chore: notify user if docker-compose fails](https://github.com/waku-org/nwaku/issues/2064)** **[chore: notify user if docker-compose fails](https://github.com/waku-org/nwaku/issues/2064)** {enhancement}, {E:3.2: Basic DoS protection in production}
- _achieved_: discussed the issue with colleagues, implemented the solution and closed the issue - _achieved_: discussed the issue with colleagues, implemented the solution and closed the issue
**[feat: allowing users to choose port 0 for dynamically allocated ports](https://github.com/waku-org/nwaku/issues/2042)** **[feat: allowing users to choose port 0 for dynamically allocated ports](https://github.com/waku-org/nwaku/issues/2042)** {enhancement}
- _achieved_: analyzed code and found the different data structures affected by the dynamic port allocation. Considered the implications of different approaches to solve the issue, discussed and translated the different options into code. - _achieved_: analyzed code and found the different data structures affected by the dynamic port allocation. Considered the implications of different approaches to solve the issue, discussed and translated the different options into code.
Started the implementation of the chosen solution, with part of the solution already working. Started the implementation of the chosen solution, with part of the solution already working.
@ -31,15 +30,15 @@ Started the implementation of the chosen solution, with part of the solution alr
**[setting up static sharding fleet for Status](https://github.com/waku-org/nwaku/issues/1914)** {E:Static sharding} **[setting up static sharding fleet for Status](https://github.com/waku-org/nwaku/issues/1914)** {E:Static sharding}
- _achieved_: negotiation with infra to improve fleet definition, clarify postgresql deployment - _achieved_: fleet has been deployed, PostgreSQL setup has been tested.
- _next_: ensure fleet gets deployed as specified - _next_: Do some basic dogfooding with Status Desktop.
**[PostgreSQL](https://github.com/waku-org/nwaku/issues/1888)** {E:2.1: Production testing of existing protocols}, {E:PostgreSQL} **[PostgreSQL](https://github.com/waku-org/nwaku/issues/1888)** {E:2.1: Production testing of existing protocols}, {E:PostgreSQL}
- _achieved_: Applied performance comparison between _SQLite_ and _Postgres_ but in this case, making direct requests from a `go-waku` unittest that @richard-ramos had prepared. - _achieved_: Applied performance comparison between _SQLite_ and _Postgres_ but in this case, making direct requests from a `go-waku` unittest that @richard-ramos had prepared.
After directly comparing the _Store_ protocol, noticed that the bottle neck is within the database itself. i.e. the _SQLite_ database performs better than _Postgres_, given that we have a very simple schema and simple queries, without joins. Adding indexes to the _Postgres_ database didn't help very much. For example, given the same query, _SQLite_ takes 1ms whereas _Postgres_ takes 6ms. After directly comparing the _Store_ protocol, noticed that the bottle neck is within the database itself. i.e. the _SQLite_ database performs better than _Postgres_, given that we have a very simple schema and simple queries, without joins. Adding indexes to the _Postgres_ database didn't help very much. For example, given the same query, _SQLite_ takes 1ms whereas _Postgres_ takes 6ms.
- _next_: - _next_:
- Wrap up the _Store_ testing environment and install it into our sandbox machine, `metal-01.he-eu-hel1.wakudev.misc.statusim.net`, so that anyone can proceed from this point (two databases with the same dataset of ~2 million rows .) in case someone is keen on analyzing performance or debug in a more realistic testing scenery. - Wrap up the _Store_ testing environment and install it into our sandbox machine, `metal-01.he-eu-hel1.wakudev.misc.statusim.net`, so that anyone can proceed from this point (two databases with the same dataset of ~2 million rows .) in case someone is keen on analyzing performance or debug in a more realistic testing scenery. This will include concurrent queries from multiple nodes, where PostgreSQL is expected to perform better.
- Start extracting the database creation and indexes creation to outside the code base. - Start extracting the database creation and indexes creation to outside the code base.
**[chore: add retention policy with GB or MB limitation](https://github.com/waku-org/nwaku/issues/1885)** {enhancement}, {E:PostgreSQL} **[chore: add retention policy with GB or MB limitation](https://github.com/waku-org/nwaku/issues/1885)** {enhancement}, {E:PostgreSQL}