Libro blanco: ueo.ventures - un sitio web estático de una sola página alojado en DownToZero

Este libro blanco ilustrará cómo se utiliza 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 tanto, en el coste.

¿Qué es 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 de una empresa privada

¿Cómo se construyó?

Como se indicó 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.

Here is the full Dockerfile used to package the website.

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

And the pipeline we use to build and deploy the most up-to-date version.

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

¿Cuánto se usa?

solicitudes

El número de solicitudes a esta página es bastante bajo. Por lo tanto, veremos muchos cold-starts no optimizados. El volumen total por día promedia alrededor de 200 solicitudes por día.

A continuación un breve conjunto de muestra

día solicitudes
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

división de las solicitudes por arranques

Cold starts are starts where nothing is present on the executing host. Warm starts are when the image is already loaded on the executing host, but the container needs to be started. Host starts are when the container is already up and running.

día arranques en frío arranques cálidos arranques calientes
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

tiempos de respuesta

Aunque la diferencia entre hot y cold-starts parece significativa en valores relativos, el tiempo absoluto de cold-start no baja de 3 ms.

Percentiles de latencia en ms

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

Consumo de energía

Todo esto se traduce en un cierto tipo y patrón de uso. Nuestra métrica para determinar el uso es el vatio. Medimos el consumo de energía de toda esa actividad y proporcionamos estadísticas detalladas a lo largo del tiempo.

| día | consumo de energía (en 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 |

Precios y eficiencia de costos

DownToZero factura la computación únicamente por la energía consumida. Las tarifas actuales son:

  • Computación: 0.010 EUR por vatio-hora (Wh) en modo normal; 0.005 EUR/Wh en ecoMode.
  • Almacenamiento: hot storage - 0.0013 EUR / GB / día; cold storage - 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 periodo de muestra (pico 524; mínimo 60).
  • Energía: ~2.40 Wh/día en promedio (min 0.43 Wh; max 6.51 Wh).

Costo estimado de cómputo con las 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.

Dado que se paga por vatio, existe 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 uso de energía.

Compensaciones: ecoMode puede implicar diferentes características de rendimiento (por ejemplo, latencia de arranque, programación); los costes pueden variar con picos de uso. Supervise el consumo y ajuste según sea necesario.