Skip to content
This repository has been archived by the owner on Aug 2, 2021. It is now read-only.

Upload speed for different file sizes #1091

Closed
adamschmideg opened this issue Jan 7, 2019 · 4 comments
Closed

Upload speed for different file sizes #1091

adamschmideg opened this issue Jan 7, 2019 · 4 comments
Assignees
Labels

Comments

@adamschmideg
Copy link

adamschmideg commented Jan 7, 2019

We have a Grafana dashboard where we can see the upload time to the 1st node we are connected to.

Create CRON jobs on our Kubernetes cluster which runs uploads, basically feeding the dashboard.

Decide: Are we satisfied with the current upload time?

root issue: #1035

@frncmx
Copy link
Contributor

frncmx commented Jan 10, 2019

@nonsense Do we have anything similar already?

We are talking here about a Kubernetes CronJob Controller, aren't we? Where should the cronjob.yml live?

Regarding the file generation and uploads: I guess we need a Docker image containing the swarm CLI and head or dd. So the job should just start a script (binary?) which generates some files and uploads to Swarm with the CLI.

Where should the script live? I think it would be easy to write it in Bash, but not to test it. But it's test code anyway and hopefully not something complex. So, Python or Go or just remain with Bash and let go of automated testing?

  • How many files do we want to upload?
  • How big those files should be?
  • Do we want to upload in parallel? If yes, what level?

@frncmx
Copy link
Contributor

frncmx commented Jan 14, 2019

Note: #1033 can be used as example

@nonsense
Copy link
Contributor

@frncmx yes, we have something similar.

Currently two cronjobs live at https://github.com/ethersphere/release-staging

We use swarm-smoke to generate the random file and upload it.

I'd rather we write code in Go, rather in Bash - it is easier to test and make sure that it works and compiles.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants