Whitepaper: ueo.ventures - un sitio web estático de una sola página alojado en DownToZero
Este whitepaper ilustrará cómo se usa DownToZero para alojar un sitio web estático. Proporcionaremos información sobre cómo se construyó el sitio web, así como algunos datos del mundo real sobre cómo se utiliza y cómo eso se refleja en el uso de DownToZero y, por lo tanto, en el costo.
What Is ueo.ventures?
ueo.ventures es un sitio estático que proporciona credenciales a entidades externas. El sitio es muy minimalista y solo consta de 2 páginas estáticas. Incluye:
- página index - indicando el nombre de la empresa
- página impressum - indicando los requisitos legales para una empresa privada
How is it build?
Como se mencionó anteriormente, el sitio web solo contiene 2 páginas. Esas páginas son archivos estáticos en un repositorio de github. Para poner esto disponible en DownToZero, necesitamos empaquetar esos dos archivos como un contenedor docker.
Aquí está el Dockerfile completo usado para empaquetar el sitio web.
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"]
Y la pipeline que usamos para construir y desplegar la versión más actualizada.
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
El número de solicitudes que recibe esta página es bastante bajo. Por lo tanto, veremos muchos arranques en frío no optimizados. El volumen total por día promedia alrededor de 200 solicitudes diarias.
Aquí un breve conjunto de muestra
| 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
Los arranques en frío son aquellos donde no hay nada presente en el host ejecutor. Los arranques en caliente son cuando la imagen ya está cargada en el host ejecutor, pero el contenedor necesita iniciarse. Los arranques en caliente en ejecución (hot starts) son cuando el contenedor ya está activo y corriendo.
| 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
Aunque la diferencia entre arranques en caliente y en frío parece significativa en valores relativos, el tiempo total de un arranque en frío no baja de 3ms.
Percentiles de latencia en ms
| state | p50 | p90 | p95 | p99 |
|---|---|---|---|---|
| cold | 0.536 | 1.003 | 2.0888 | 3.2584 |
| hot | 0 | 0 | 0.001 | 0.001 |
Power Consumption
Todo esto se traduce en un cierto tipo y patrón de uso. Nuestra métrica para determinar el uso es el Watt. Medimos el consumo energético para toda esa actividad y proporcionamos estadísticas detalladas a lo largo del tiempo.
| 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 factura el cómputo puramente por la energía consumida. Las tarifas actuales son:
- Cómputo: 0,010 EUR por Watt-Hora (Wh) en modo normal; 0,005 EUR/Wh en ecoMode.
- Almacenamiento: almacenamiento caliente - 0,0013 EUR / GB / día; almacenamiento frío - 0,0007 EUR / GB / día
Basado en el uso medido de este servicio ueo.ventures:
- Solicitudes: ~203 solicitudes/día en promedio durante el período de muestra (pico 524; mínimo 60).
- Energía: ~2,40 Wh/día en promedio (mín 0,43 Wh; máx 6,51 Wh).
Costo estimado de cómputo a tarifas actuales:
- Modo normal: ~0,024 EUR/día (~0,72 EUR por mes de 30 días); rango diario ≈ 0,004–0,065 EUR.
- ecoMode: ~0,012 EUR/día (~0,36 EUR por mes de 30 días); rango diario ≈ 0,002–0,033 EUR.
Porque se paga por watt, hay un incentivo directo para mantener las imágenes ligeras, evitar trabajo innecesario en los arranques en frío y optar por ecoMode cuando sea práctico. Con el tiempo esto puede reducir tanto el gasto como el consumo energético.
Compromisos: ecoMode puede implicar diferentes características de rendimiento (p. ej., latencia de inicio, planificación); los costos pueden variar con picos de uso. Monitorear el consumo y ajustar según sea necesario.