runar-rkmedia / gabyoall

Opiniated stress-tester for servers

Hi 👋, I'm Runar

An enthusiastic developer, focusing on backend, DX, typography and frontend.

• 🔭 I’m currently working on A translation managaement-solution written in Go and Svelte and a mathematical puzzle-game

• 🌱 I’m currently learning Time-Series Databases, .Net, Zig and a bit of Blackhat

• 💬 Ask me about web dev, Go, JavaScript, React, and Svelte

• 📫 How to reach me [email protected]

• Currently employed at Sikri

• Currently taking a bachelor in CyberSecurity at Noroff at Noroff

• A fan of getting stuff done fast and correctly while reducing complexities.

Languages and Tools:

gabyoall's Issues

[BUG]: With large amounts of requests, the timescale loses most of the time-values

Version: v0.3

Reproduction-steps:

1. Use a GET-schedule to localhost/ping with a high amount of requests (100000), concurrency set to (5)
2. Run the schedule with forced time-start (now) and watch the graph in the stats-panel as it advances through the requests.

---

When watching the live-update of the graph, it first starts out ok and working as expecting. However, at some random point, it seems to simply go a bit mental, and loses all information about the timings.

I have not yet investigated the issue any further, but there are a few subjects:

• When marshalling the response to the client, the timescale-date is grouped so that no more that 2000 datapoints are returned to the user. This is to reduce the data that is sent to the clients, in case there are a huge number of requests.
• Timescale-data is inserted at non-incrementing data. This could perhaps make the offset-calculation a bit off, and therefore all points after that could be wrong. It is a requiredment of the gorilla-compaction-algorithm for all the timescale data to be inserted in the correct order.

The last one seems to most likely, as the data only sometimes gets messed up. If it were the first, I would expect it to get messed up every time at the same datapoint-index, but it doesn't. a milliion request does not always result in this behaviour.

IDEA: Json/toml/yml-storage

It would be kind of practical to enable a storage which is basically json/toml/yml-files on disk.

This would mainly be used by the cli, but the api could use it as well. This should of course just implement the storage-interface.

This storage is probably fast enough for developer-usage. The pros are that they are very easily readable and editable by a user, if that would be needed.

This could also have a nice additional effect, like for instance one could have the whole storage in the users browser-local storage. The api would then use that as configuration and it would be completely seperate from other users (although the http-requests made would not be, e.g. they could easily starve eachother). This will probably not be implemented, though.

ScheduleEntity: Reliance on SchedulePayload

The type relied on the schedule-payload, which is a bad pattern.

From goswagger: WARNING: Can't figure out object type for embedded named type

I have not investigated the issue yet, but I believe the warning comes from goswagger, which does not know about some of my custom-types.

This has implications for the generated swagger-code.

Codesplitting and plotly

Plotly was chosen because of its ease of use, and that it works great. However, it is HUGE!

So lets code-split, right?

I had a slash at that now with Svelte and it seems to work. However, now it flickers a lot when the chart-component is receiving props. Probably because it recreates the whole import, in addition to the async-importer. Now, this could probably be solved.

However, it is apparant that Plotly at the moment does not tree-shake. I have not checked yet if they support tree-shaking at all, but I guess its should work if we make the import-paths more specific.

Also, the code-module with yaml-support is a bit big. Maybe we should go for a different yaml-library? Or why bother, we already have toml and json, so yaml is kind of redundant.

Clean up the UI

There are a few places where the buttons are not using the correct component and variant. Also, the Code-component seems a bit splattered around, like seasoning.