Whitepaper: ueo.ventures - eine einseitige statische Website, gehostet bei DownToZero

Dieses Whitepaper zeigt, wie DownToZero verwendet wird, um eine statische Website zu hosten. Wir geben Einblicke, wie die Website aufgebaut wurde und liefern einige reale Nutzungsdaten, wie sie sich in der DownToZero-Nutzung und damit in den Kosten niederschlagen.

Was ist ueo.ventures?

ueo.ventures ist eine statische Seite, die Zugangsdaten an externe Stellen bereitstellt. Die Seite ist sehr minimal und besteht nur aus 2 statischen Seiten. Sie enthält:

  • index page - stating the name of the company
  • impressum page - stating the legal requirements fo a private company

Wie ist es gebaut?

Wie bereits erwähnt, enthält die Website nur 2 Seiten. Diese Seiten sind statische Dateien in einem GitHub-Repository. Um diese über DownToZero verfügbar zu machen, müssen wir diese beiden Dateien als Docker-Container paketieren.

Hier ist das vollständige Dockerfile, das verwendet wurde, um die Website zu paketieren.

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 jeweils 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

Wie oft wird es genutzt?

requests

Die Anzahl der Anfragen an diese Seite ist eher gering. Daher sehen wir viele nicht optimierte Cold-Starts. Das tägliche Volumen liegt im Schnitt bei etwa 200 Anfragen pro Tag.

Hier eine kurze Stichprobe

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

Aufschlüsselung der Anfragen nach Cold-Starts

Cold starts sind Starts, bei denen nichts auf dem ausführenden Host vorhanden ist. Warm starts sind Starts, bei denen das Image bereits auf dem ausführenden Host geladen ist, aber der Container noch gestartet werden muss. Host starts (hot starts) sind Starts, bei denen der Container bereits läuft.

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

Obwohl der relative Unterschied zwischen Hot- und Cold-Starts signifikant erscheint, liegt die absolute Cold-Start-Zeit nicht unter 3 ms.

Latenz-Percentile in ms

state p50 p90 p95 p99
cold 0.536 1.003 2.0888 3.2584
hot 0 0 0.001 0.001

Stromverbrauch

All dies übersetzt sich in ein bestimmtes Nutzungsbild und Muster. Unsere Metrik zur Bestimmung der Nutzung ist Watt. Wir messen den Energieverbrauch für all diese Aktivitäten und stellen detaillierte Statistiken über die Zeit bereit.

| 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 |

Preisgestaltung & Kosteneffizienz

DownToZero berechnet Compute ausschließlich nach dem verbrauchten Strom. Aktuelle Sätze sind:

  • Compute: 0.010 EUR per Watt-Hour (Wh) in normal mode; 0.005 EUR/Wh in ecoMode.
  • Storage: hot storage - 0.0013 EUR / GB / day; cold stoorage - 0.0007 EUR / GB / day

Basierend auf der gemessenen Nutzung dieses ueo.ventures-Dienstes:

  • Requests: ~203 Anfragen/Tag im Durchschnitt über den Stichprobenzeitraum (Spitze 524; Minimum 60).
  • Energie: ~2.40 Wh/Tag im Durchschnitt (Min 0.43 Wh; Max 6.51 Wh).

Geschätzte Compute-Kosten bei 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 nach Watt abgerechnet 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. Langfristig kann dies sowohl Ausgaben als auch Energieverbrauch reduzieren.

Trade-offs: ecoMode kann andere Leistungscharakteristika mit sich bringen (z. B. Startlatenz, Scheduling); Kosten können bei Nutzungsspitzen variieren. Überwachen Sie den Verbrauch und passen Sie bei Bedarf an.