Whitepaper: ueo.ventures - un sito statico a pagina singola ospitato su DownToZero
Questo whitepaper illustrerà come DownToZero viene utilizzato per ospitare un sito statico. Forniremo approfondimenti su come il sito è stato costruito e mostreremo alcuni dati reali sull’utilizzo e su come questo si rifletta nell’utilizzo di DownToZero e quindi nei costi.
What Is ueo.ventures?
ueo.ventures è un sito statico che fornisce credenziali a entità esterne. Il sito è molto minimale e consiste solamente di 2 pagine statiche. Include:
- pagina index - che indica il nome della società
- pagina impressum - che indica i requisiti legali per una società privata
How is it build?
Come detto in precedenza, il sito contiene solo 2 pagine. Quelle pagine sono file statici in un repository github. Per rendere questo disponibile a DownToZero, dobbiamo impacchettare quei due file come container docker.
Ecco il Dockerfile completo usato per impacchettare il sito.
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"]
E la pipeline che utilizziamo per buildare e distribuire la versione più aggiornata.
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
Il numero di richieste verso questa pagina è piuttosto basso. Quindi vedremo molti cold-start non ottimizzati. Il volume complessivo per giorno si attesta in media intorno a 200 richieste al giorno.
Di seguito un breve campione
| 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
I cold start sono avvii in cui non è presente nulla sull’host che esegue. I warm start sono quando l’immagine è già caricata sull’host che esegue, ma il container deve essere avviato. I hot start sono quando il container è già avviato e in esecuzione.
| 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
Sebbene la differenza tra hot e cold-start sembri significativa in valori relativi, il tempo complessivo di cold-start non scende sotto i 3ms.
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
Tutto questo si traduce in un certo tipo e schema di utilizzo. La nostra metrica per determinare l’utilizzo è il Watt. Misuriamo il consumo energetico per tutta questa attività e forniamo statistiche dettagliate nel tempo.
| 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 fattura il calcolo esclusivamente in base all’energia consumata. Le tariffe correnti sono:
- Compute: 0.010 EUR per Watt-Hour (Wh) in modalità normale; 0.005 EUR/Wh in ecoMode.
- Storage: hot storage - 0.0013 EUR / GB / giorno; cold stoorage - 0.0007 EUR / GB / giorno
Basandosi sull’utilizzo misurato di questo servizio ueo.ventures:
- Richieste: ~203 richieste/giorno in media nel periodo campione (picco 524; minimo 60).
- Energia: ~2.40 Wh/giorno in media (min 0.43 Wh; max 6.51 Wh).
Costo stimato del compute alle tariffe correnti:
- Modalità normale: ~0.024 EUR/giorno (~0.72 EUR per mese di 30 giorni); range giornaliero ≈ 0.004–0.065 EUR.
- ecoMode: ~0.012 EUR/giorno (~0.36 EUR per mese di 30 giorni); range giornaliero ≈ 0.002–0.033 EUR.
Poiché si paga per watt, c’è un incentivo diretto a mantenere le immagini leggere, evitare lavoro inutile durante i cold start e attivare ecoMode quando praticabile. Nel tempo questo può ridurre sia la spesa sia l’uso di energia.
Compromessi: ecoMode può comportare differenti caratteristiche di performance (ad es. latenza di avvio, scheduling); i costi possono variare con picchi di utilizzo. Monitora il consumo e adatta le impostazioni secondo necessità.