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.