Whitepaper: ueo.ventures - eine einseitige statische Website gehostet bei DownToZero
Dieses Whitepaper veranschaulicht, wie DownToZero zum Hosting einer statischen Website verwendet wird. Wir geben Einblicke, wie die Website aufgebaut wurde, und präsentieren reale Daten zur Nutzung sowie deren Auswirkungen auf die DownToZero-Nutzung und damit die Kosten.
What Is ueo.ventures?
ueo.ventures ist eine statische Seite, die externen Stellen Zugangsdaten bereitstellt. Die Seite ist sehr minimalistisch und besteht nur aus 2 statischen Seiten. Sie beinhaltet:
- Startseite – mit dem Namen des Unternehmens
- Impressum-Seite – mit den rechtlichen Angaben für ein privates Unternehmen
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 diese DownToZero zur Verfügung zu stellen, müssen wir diese zwei Dateien als Docker-Container verpacken.
Hier das komplette Dockerfile, das für das Verpacken der Website verwendet wird.
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, mit der wir die jeweils aktuellste Version bauen und bereitstellen.
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 Zugriffe auf diese Seite ist relativ gering. Daher sehen wir viele nicht optimierte Cold-Starts. Das Gesamtvolumen pro Tag liegt im Durchschnitt bei etwa 200 Anfragen.
Hier ein kurzer Beispieldatensatz
| 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 Starts, bei denen das Image bereits auf dem ausführenden Host geladen ist, der Container aber noch gestartet werden muss. 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
Während der Unterschied zwischen Hot- und Cold-Starts in relativen Werten deutlich erscheint, unterschreitet die gesamte Cold-Start-Zeit nicht 3 ms.
Latenz-Perzentile 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 spiegelt sich in einem bestimmten Nutzungs-Typ und -Muster wider. Unsere Metrik zur Bestimmung der Nutzung ist Watt. Wir messen den Energieverbrauch für alle 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 verrechnet Compute ausschließlich nach verbrauchter Energie. Die aktuellen 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 dem gemessenen Verbrauch des ueo.ventures-Dienstes:
- Requests: ~203 Anfragen/Tag im Durchschnitt über den Beobachtungszeitraum (Spitze 524; Minimum 60).
- Energie: ~2,40 Wh/Tag im Durchschnitt (Minimum 0,43 Wh; Maximum 6,51 Wh).
Geschätzte Compute-Kosten bei aktuellen Tarifen:
- Normalmodus: ~0,024 EUR/Tag (~0,72 EUR pro 30-Tage-Monat); Tagesbereich ca. 0,004–0,065 EUR.
- EcoMode: ~0,012 EUR/Tag (~0,36 EUR pro 30-Tage-Monat); Tagesbereich ca. 0,002–0,033 EUR.
Da pro Watt abgerechnet wird, besteht ein direkter Anreiz, Images schlank zu halten, unnötige Arbeit bei Cold-Starts zu vermeiden und EcoMode zu nutzen, wo praktikabel. Im Laufe der Zeit kann dies sowohl Ausgaben als auch Energieverbrauch reduzieren.
Trade-offs: EcoMode kann andere Performance-Charakteristika mit sich bringen (z.B. Startlatenz, Scheduling); Kosten können bei Nutzungsspitzen schwanken. Verbrauch überwachen und bei Bedarf anpassen.