Whitepaper: ueo.ventures - a single page static website hosted at DownToZero
Dieses Whitepaper zeigt, wie DownToZero zum Hosten einer statischen Website verwendet wird. Wir geben Einblicke, wie die Website aufgebaut wurde, und liefern einige reale Nutzungsdaten, wie sie verwendet wird und wie sich das in der DownToZero-Nutzung und damit in den Kosten widerspiegelt.
What Is ueo.ventures?
ueo.ventures ist eine statische Seite, die Zugangsdaten für externe Stellen bereitstellt. Die Seite ist sehr minimal und besteht nur aus 2 statischen Seiten. Sie umfasst:
- Startseite (index) - nennt den Namen des Unternehmens
- Impressum-Seite - enthält die rechtlichen Anforderungen für ein Privatunternehmen
How is it build?
Wie bereits erwähnt, enthält die Website nur 2 Seiten. Diese Seiten sind statische Dateien in einem GitHub-Repository. Um dies DownToZero zur Verfügung zu stellen, müssen wir diese beiden Dateien als Docker-Container verpacken.
Hier ist das vollständige Dockerfile, das verwendet wurde, um die Website zu verpacken.
FROM alpine AS runner
RUN apk add --update --no-cache lighttpd && rm -rf /var/cache/apk/*
ADD index.html /var/www/localhost/htdocs/
ADD impressum.html /var/www/localhost/htdocs/
CMD ["/usr/sbin/lighttpd", "-D", "-f", "/etc/lighttpd/lighttpd.conf"]
Und die Pipeline, die wir verwenden, um die aktuellste Version zu bauen und bereitzustellen.
name: website
on:
push:
workflow_dispatch:
schedule:
- cron: '30 5 25 * *'
jobs:
build-website:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: build website
run: |
docker build -t xb35e5d0.cr.dtz.dev/ueo-ventures .
- name: Login to xb35e5d0.cr.dtz.dev
uses: docker/login-action@v3
with:
registry: xb35e5d0.cr.dtz.dev
username: apikey
password: ${{ secrets.DTZ_API_KEY }}
- name: uploading image to xb35e5d0.cr.dtz.dev
run: |
docker push xb35e5d0.cr.dtz.dev/ueo-ventures:latest
- name: Resolve image digest
id: resolve_digest
run: |
DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' xb35e5d0.cr.dtz.dev/ueo-ventures:latest)
echo "IMAGE_URL=$DIGEST" >> $GITHUB_ENV
- name: Deploy latest image to service
uses: DownToZero-Cloud/containers-service-update@main
with:
container_image: ${{ env.IMAGE_URL }}
api_key: ${{ secrets.DTZ_API_KEY }}
service_id: service-e1d1efd8
- name: Publish image URL to summary
run: |
echo "## Deployed image" >> $GITHUB_STEP_SUMMARY
echo "" >> $GITHUB_STEP_SUMMARY
echo "${IMAGE_URL}" >> $GITHUB_STEP_SUMMARY
How much is it used?
requests
Die Anzahl der Anfragen an diese Seite ist relativ gering. Daher werden wir viele unoptimierte Cold-Starts sehen. Das tägliche Volumen liegt im Schnitt bei etwa 200 Anfragen pro Tag.
Hier ein kurzes Beispielset
| day | requests |
|---|---|
| 2025-09-12 | 147 |
| 2025-09-13 | 116 |
| 2025-09-14 | 118 |
| 2025-09-15 | 121 |
| 2025-09-16 | 200 |
| 2025-09-17 | 169 |
| 2025-09-18 | 157 |
| 2025-09-19 | 268 |
| 2025-09-20 | 524 |
| 2025-09-21 | 496 |
| 2025-09-22 | 228 |
| 2025-09-23 | 246 |
| 2025-09-24 | 123 |
| 2025-09-25 | 79 |
| 2025-09-26 | 60 |
splitting the request by cold-starts
Cold-Starts sind Starts, bei denen nichts auf dem ausführenden Host vorhanden ist. Warm-Starts sind, wenn das Image bereits auf dem ausführenden Host geladen ist, aber der Container gestartet werden muss. Hot-Starts sind, wenn der Container bereits hochgefahren und aktiv ist.
| day | cold starts | warm starts | hot starts |
|---|---|---|---|
| 2025-09-12 | 63 | 48 | 14 |
| 2025-09-13 | 70 | 3 | 21 |
| 2025-09-14 | 61 | 3 | 22 |
| 2025-09-15 | 68 | 0 | 31 |
| 2025-09-16 | 84 | 3 | 27 |
| 2025-09-17 | 53 | 3 | 25 |
| 2025-09-18 | 72 | 2 | 27 |
| 2025-09-19 | 48 | 2 | 19 |
| 2025-09-20 | 501 | 2 | 10 |
| 2025-09-21 | 474 | 3 | 1 |
| 2025-09-22 | 199 | 3 | 2 |
| 2025-09-23 | 201 | 3 | 27 |
| 2025-09-24 | 71 | 5 | 31 |
| 2025-09-25 | 51 | 3 | 20 |
response times
Während sich der Unterschied zwischen Hot- und Cold-Starts in relativen Werten signifikant zu zeigen scheint, fällt die absolute Cold-Start-Zeit nicht unter 3 ms.
Latency Percentiles in ms
| state | p50 | p90 | p95 | p99 |
|---|---|---|---|---|
| cold | 0.536 | 1.003 | 2.0888 | 3.2584 |
| hot | 0 | 0 | 0.001 | 0.001 |
Power Consumption
All dies übersetzt sich in einen bestimmten Nutzungstyp und ein Nutzungsmuster. Unsere Kennzahl zur Bestimmung des Verbrauchs ist Watt. Wir messen den Energieverbrauch für alle diese Aktivitäten und liefern detaillierte Statistiken über die Zeit.
| day | power consumption (in Wh) | | — | ———– :| | 2025-09-12 | 1.88 | | 2025-09-13 | 2.00 | | 2025-09-14 | 0.96 | | 2025-09-15 | 1.76 | | 2025-09-16 | 3.14 | | 2025-09-17 | 0.43 | | 2025-09-18 | 1.90 | | 2025-09-19 | 1.06 | | 2025-09-20 | 4.74 | | 2025-09-21 | 4.51 | | 2025-09-22 | 1.62 | | 2025-09-23 | 6.51 | | 2025-09-24 | 3.85 | | 2025-09-25 | 3.29 | | 2025-09-26 | 2.81 |
Pricing & Cost Efficiency
DownToZero berechnet Compute ausschließlich nach verbrauchter Energie. Aktuelle Tarife sind:
- Compute: 0.010 EUR pro Watt-Stunde (Wh) im Normalmodus; 0.005 EUR/Wh im ecoMode.
- Storage: Hot-Storage - 0.0013 EUR / GB / Tag; Cold-Storage - 0.0007 EUR / GB / Tag
Basierend auf der gemessenen Nutzung dieses ueo.ventures-Dienstes:
- Anfragen: ~203 Anfragen/Tag im Durchschnitt über den Stichzeitraum (Spitze 524; Minimum 60).
- Energie: ~2.40 Wh/Tag im Durchschnitt (min 0.43 Wh; max 6.51 Wh).
Geschätzte Compute-Kosten zu den aktuellen Tarifen:
- Normalmodus: ~0.024 EUR/Tag (~0.72 EUR pro 30-Tage-Monat); tägliche Spanne ≈ 0.004–0.065 EUR.
- ecoMode: ~0.012 EUR/Tag (~0.36 EUR pro 30-Tage-Monat); tägliche Spanne ≈ 0.002–0.033 EUR.
Da pro Watt bezahlt wird, besteht ein direkter Anreiz, Images schlank zu halten, unnötige Arbeit bei Cold-Starts zu vermeiden und wo praktikabel in den ecoMode zu wechseln. Im Laufe der Zeit kann dies sowohl Ausgaben als auch Energieverbrauch reduzieren.
Trade-offs: ecoMode kann andere Leistungsmerkmale mit sich bringen (z. B. Start-Latenz, Scheduling); die Kosten können bei Nutzungsspitzen variieren. Überwachen Sie den Verbrauch und passen Sie bei Bedarf an.