You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
Emil Abbasov 693e633164
Removed all the PNMs from the testbenchs
7 months ago
.devcontainer chore: Move apps 3 years ago
.github/workflows feature: added SJF scheduler and Regression based prediction (#385) 8 months ago
.vscode feature: added SJF scheduler and Regression based prediction (#385) 8 months ago
applications feature: added SJF scheduler and Regression based prediction (#385) 8 months ago
awsm@272fcf42b6 Removed all the PNMs from the testbenchs 7 months ago
docs docs: Document WASI support level 3 years ago
libsledge Fix: Change the TLS-model for the libsledge to init-exec (#370) 2 years ago
runtime feature: added SJF scheduler and Regression based prediction (#385) 8 months ago
tests Removed all the PNMs from the testbenchs 7 months ago
.clang-format feature: added SJF scheduler and Regression based prediction (#385) 8 months ago
.editorconfig WIP: WASI Support (#267) 3 years ago
.env refactor: assorted bash cleanup 4 years ago
.gitignore Remove wasm_apps submodule from Sledge repo (#368) 2 years ago
.gitmodules Remove wasm_apps submodule from Sledge repo (#368) 2 years ago
Dockerfile.aarch64 WIP: WASI Support (#267) 3 years ago
Dockerfile.x86_64 feature: added SJF scheduler and Regression based prediction (#385) 8 months ago
LICENSE chore: first rename pass 5 years ago
Makefile Remove wasm_apps submodule from Sledge repo (#368) 2 years ago
README.md updated README to reflect latest changes 2 years ago
devenv.sh chore: docker fixes 3 years ago
fix_root.sh chore: improve fix_root script 4 years ago
format.sh feature: added SJF scheduler and Regression based prediction (#385) 8 months ago
install_deb.sh feature: added SJF scheduler and Regression based prediction (#385) 8 months ago
install_llvm.sh feature: added SJF scheduler and Regression based prediction (#385) 8 months ago
install_perf.sh refactor: assorted bash cleanup 4 years ago
test.mk fix: Update gocr tests to send PNGs instead of PNMs 7 months ago
uninstall_llvm.sh feature: added SJF scheduler and Regression based prediction (#385) 8 months ago

README.md

SLEdge

SLEdge is a lightweight serverless solution suitable for edge computing. It builds on WebAssembly sandboxing provided by the aWsm compiler.

Setting up a development environment

Native on Debian Host

git clone https://github.com/gwsystems/sledge-serverless-framework.git
cd sledge-serverless-framework
./install_deb.sh
source ~/.bashrc
make install
make test

Docker

Note: These steps require Docker. Make sure you've got it installed!

Docker Installation Instructions

We provide a Docker build environment configured with the dependencies and toolchain needed to build the SLEdge runtime and serverless functions.

To setup this environment, run:

./devenv.sh setup

Using the Docker container to compile your serverless functions

To enter the docker environment, run:

./devenv.sh run

The first time you enter this environment, run the following to copy the sledgert binary to /sledge/runtime/bin.

cd /sledge/runtime
make clean all

There are a set of benchmarking applications in the /sledge/applications directory. Run the following to compile all benchmarks runtime tests using the aWsm compiler and then copy all resulting <application>.wasm.so files to /sledge/runtime/bin.

cd /sledge/applications/
make clean all

You now have everything that you need to execute your first serverless function on SLEdge

To exit the container:

exit

To stop the Docker container:

./devenv.sh stop

Deleting Docker Build Containers

If you are finished working with the SLEdge runtime and wish to remove it, run the following command to delete our Docker build and runtime images.

./devenv.sh rma

And then simply delete this repository.

Running your first serverless function

An SLEdge serverless function consists of a shared library (*.so) and a JSON configuration file that determines how the runtime should execute the serverless function. As an example, here is the configuration file for our sample fibonacci function:

[
	{
		"name": "GWU",
		"port": 10010,
		"routes": [
			{
				"route": "/fib",
				"path": "fibonacci.wasm.so",
				"expected-execution-us": 6000,
				"relative-deadline-us": 20000,
				"http-resp-content-type": "text/plain"
			}
		]
	}
]

The port and route fields are used to determine the path where our serverless function will be served served.

In our case, we are running the SLEdge runtime on localhost, so our function is available at localhost:10010/fib.

Our fibonacci function will parse a single argument from the HTTP POST body that we send. The expected Content-Type is "text/plain".

Now that we understand roughly how the SLEdge runtime interacts with serverless function, let's run Fibonacci!

The fastest way to check it out is just to click on the following URL on your Web browser: http://localhost:10010/fib?10

From the root project directory of the host environment (not the Docker container!), navigate to the binary directory

cd runtime/bin/

Now run the sledgert binary, passing the JSON file of the serverless function we want to serve. Because serverless functions are loaded by SLEdge as shared libraries, we want to add the applications/ directory to LD_LIBRARY_PATH.

LD_LIBRARY_PATH="$(pwd):$LD_LIBRARY_PATH" ./sledgert ../../tests/fibonacci/bimodal/spec.json

While you don't see any output to the console, the runtime is running in the foreground.

Let's now invoke our serverless function to compute the 10th fibonacci number. We'll use cURL and HTTPie to send a HTTP GET and POST requests with the parameter we want to pass to my serverless function. Feel free to use whatever other network client you prefer!

Open a new terminal session and execute the following

# HTTP GET method:
http localhost:10010/fib?10
curl localhost:10010/fib?10

# HTTP POST method:
echo "10" | http POST localhost:10010/fib
curl -i -d 10 localhost:10010/fib

You should receive the following in response. The serverless function says that the 10th fibonacci number is 55, which seems to be correct!

HTTP/1.1 200 OK
Server: SLEdge
Connection: close
Content-Type: text/plain
Content-Length: 3

55

When done, terminal the SLEdge runtime with Ctrl+c

Running Test Workloads

Various synthetic and real-world tests can be found in runtime/tests. Generally, each experiment can be run by Make rules in the top level test.mk.

make -f test.mk all

Problems or Feedback?

If you encountered bugs or have feedback, please let us know in our issue tracker.