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.