1. PHP tradicional con Apache (mod_php)

• Qué es: mod_php es un módulo de Apache que permite ejecutar código PHP directamente dentro del proceso del servidor web.
• Cómo funciona: Apache carga el intérprete de PHP como parte de sus procesos. Cada petición HTTP que requiere PHP es procesada dentro del mismo proceso de Apache.
• Ventajas:
  • Simplicidad: fácil de configurar.
  • Integración directa: PHP puede acceder a variables de Apache y módulos internos.
• Desventajas:
  • Cada proceso de Apache carga PHP completo, lo que aumenta el consumo de memoria.
  • No es tan eficiente en entornos con muchas conexiones concurrentes.

2. PHP-FPM (FastCGI Process Manager)

Requiere monitoreo de los pools de procesos para evitar saturación.

Qué es: PHP-FPM es un gestor de procesos FastCGI para PHP. Funciona como un servicio independiente que Apache llama para ejecutar scripts PHP.

Cómo funciona:

Apache recibe la petición HTTP.

Si es un archivo PHP, Apache lo redirige a PHP-FPM mediante FastCGI (usualmente usando mod_proxy_fcgi). En versiones de Linux Alpine se encuentra incluido en el mod_proxy.

PHP-FPM procesa el script y devuelve la respuesta a Apache.

Ventajas:

Manejo eficiente de procesos: PHP-FPM mantiene pools de procesos listos para servir solicitudes.

Mejor rendimiento en sitios con alta concurrencia.

Permite ejecutar diferentes versiones de PHP para distintos sitios.

Mejor aislamiento de procesos y control de recursos.

Desventajas:

Configuración más compleja.

3. Cómo Apache gestiona PHP con FPM

Apache ya no ejecuta PHP directamente. Usa mod_proxy_fcgi o mod_fastcgi para comunicarse con PHP-FPM:

<FilesMatch .php$>
    SetHandler "proxy:unix:/run/php/php8.1-fpm.sock|fcgi://localhost/"
</FilesMatch>

<FilesMatch .php$>
    SetHandler "proxy:unix:/run/php/php8.1-fpm.sock|fcgi://localhost/"
</FilesMatch>

• SetHandler indica que las peticiones PHP se deben enviar a PHP-FPM.
• PHP-FPM escucha en un socket Unix o puerto TCP y devuelve la salida ya procesada.
• Apache sigue manejando la conexión HTTP, logging, seguridad y otras funcionalidades, pero la ejecución de PHP queda delegada.

4. Resumen de diferencias

5. Conclusión

• mod_php es más simple y suficiente para sitios pequeños o entornos de desarrollo.
• PHP-FPM es más eficiente, flexible y escalable, ideal para producción y sitios con alta carga.
• Apache gestiona la parte HTTP y delega la ejecución de PHP a PHP-FPM, optimizando recursos y manteniendo la seguridad y control.

5. Exclusividad de PHP-FPM y orden de ejecución con Apache

Cuando usamos PHP-FPM, Apache ya no ejecuta PHP directamente. Esto implica dos cosas importantes:

1️⃣ Exclusividad de PHP-FPM

• Solo puede haber un intérprete activo por socket o puerto.
• PHP-FPM actúa como un servicio independiente, gestionando un pool de procesos que reciben solicitudes de PHP de Apache (o Nginx).
• Si tienes múltiples instancias de PHP-FPM escuchando en el mismo socket, habrá conflictos.
• Por eso se habla de “exclusividad”: cada pool de PHP-FPM se asigna a un sitio o versión de PHP y Apache lo llama a través del socket/puerto definido.

6. Ejecución del servidor

1️⃣ Arranque con mod_php (php-apache) en Alpine

En Alpine, normalmente instalas el paquete php-apache2:

# Instalar Apache + mod_php
apk add apache2 php8-apache2

# Iniciar Apache (que ya carga PHP internamente)
httpd -D

# Instalar Apache + mod_php
apk add apache2 php8-apache2

# Iniciar Apache (que ya carga PHP internamente)
httpd -D

• Nota: No hay servicio PHP externo, todo corre dentro de Apache.

2️⃣ Arranque con PHP-FPM + Apache en Alpine

Instalas PHP-FPM y Apache, y configuras Apache para usar FastCGI:

# Instalar PHP-FPM y Apache
apk add php8-fpm php8-opcache apache2

# Hablitar modulo proxy o proxy_fcgi segun se necesite
...
# Agregar configuracion proxy a FCGI
...

# Iniciar FPM 
php-fpm8 

# Iniciar Apache 
httpd -D

# Instalar PHP-FPM y Apache
apk add php8-fpm php8-opcache apache2

# Hablitar modulo proxy o proxy_fcgi segun se necesite
...
# Agregar configuracion proxy a FCGI
...

# Iniciar FPM 
php-fpm8 

# Iniciar Apache 
httpd -D

The post PHP y PHP-FPM con Apache: diferencias first appeared on RandomBitsOnFire.

SSE está soportado de forma nativa por los navegadores modernos mediante la API EventSource, lo que lo convierte en una solución sencilla y eficiente para:

• Notificaciones en tiempo real
• Actualización de dashboards
• Logs en streaming
• Sistemas de monitorización
• Chats unidireccionales

La comunicación se realiza sobre HTTP estándar con el tipo de contenido:

text/event-stream

text/event-stream

Cada evento sigue un formato simple:

event: nombreEvento
data: contenido
id: 1

event: nombreEvento
data: contenido
id: 1

Alternativas: WebSockets

La alternativa más conocida a SSE es WebSockets, una tecnología que permite comunicación bidireccional full-duplex entre cliente y servidor sobre una única conexión TCP persistente.

Diferencias conceptuales

Tabla comparativa: Ventajas y Desventajas

Implementación clásica con Spring Boot 3

En Spring Boot 3, la forma tradicional de implementar SSE es mediante SseEmitter

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

/** Service **/
public class SSEService {
        
	private Map<String, SseEmitter> emitters = new ConcurrentHashMap<>();
	public SseEmitter subscribe(String userId) {
        SseEmitter emitter = emitters
            .computeIfAbsent(userId, k -> new SseEmitter(0L));

        emitter.onCompletion(() -> {
        	log.info("Connection COMPLETED on USER: "+ userId);
        	remove(userId);});
        emitter.onTimeout(() -> {
        	log.info("Connection TIMEOUT on USER: "+ userId);
        	remove(userId);});
        emitter.onError(e -> {
        	log.info("Connection ERROR on USER: "+ userId);
        	remove(userId);});
        
        objs.computeIfAbsent(userId, k -> obj);

        return emitter;
    }
    public void remove(String userId) {
    	SseEmitter sse = emitters.get(userId);
        if (sse != null) {
        	log.info("CLEAN CONNECTION AND REMOVE FILTER on USER: "+ userId);
        	emitters.remove(userId);
        }
    }
}

/** Service **/
public class SSEService {
        
	private Map<String, SseEmitter> emitters = new ConcurrentHashMap<>();
	public SseEmitter subscribe(String userId) {
        SseEmitter emitter = emitters
            .computeIfAbsent(userId, k -> new SseEmitter(0L));

        emitter.onCompletion(() -> {
        	log.info("Connection COMPLETED on USER: "+ userId);
        	remove(userId);});
        emitter.onTimeout(() -> {
        	log.info("Connection TIMEOUT on USER: "+ userId);
        	remove(userId);});
        emitter.onError(e -> {
        	log.info("Connection ERROR on USER: "+ userId);
        	remove(userId);});
        
        objs.computeIfAbsent(userId, k -> obj);

        return emitter;
    }
    public void remove(String userId) {
    	SseEmitter sse = emitters.get(userId);
        if (sse != null) {
        	log.info("CLEAN CONNECTION AND REMOVE FILTER on USER: "+ userId);
        	emitters.remove(userId);
        }
    }
}

/* Controller */
public class Controller {
        
	@Autowired
	private SSEService sseService;
	@GetMapping(path = "/subscribe", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
	public SseEmitter subscribe(@RequestParam("userID") String userId) {
		log.debug("Call to SSE Subscribe");
		return service.subscribe(userId);
	}
}

/* Controller */
public class Controller {
        
	@Autowired
	private SSEService sseService;
	@GetMapping(path = "/subscribe", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
	public SseEmitter subscribe(@RequestParam("userID") String userId) {
		log.debug("Call to SSE Subscribe");
		return service.subscribe(userId);
	}
}

Características clave

• Spring mantiene la conexión abierta
• El navegador reconecta automáticamente si se pierde
• Se puede personalizar timeout y gestión de errores

Avanzado

Programación Reactiva

En aplicaciones modernas, especialmente con alta concurrencia, el modelo bloqueante tradicional no es óptimo. Aquí entra la programación reactiva, basada en:

• Streams asíncronos
• Backpressure
• No bloqueo de hilos

Spring ofrece soporte mediante Project Reactor, usando tipos como:

• Flux<T>
• Mono<T>

Para SSE, Flux es perfecto porque representa una secuencia de datos potencialmente infinita.

Uso con Spring WebFlux

Para entornos altamente concurrentes o arquitecturas basadas en microservicios, WebFlux es la opción recomendada.

Dependencia

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-webflux</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-webflux</artifactId>
</dependency>

Implementación con Flux

/* Service */
@Service
public class SseService {

    private final Map<String, Sinks.Many<String>> sinks = new ConcurrentHashMap<>();

    public Sinks.Many<String> createSink(String clientId) {
        return sinks.computeIfAbsent(clientId,
                id -> Sinks.many().multicast().onBackpressureBuffer());
    }

    public void publish(String clientId, String message) {
        Sinks.Many<String> sink = sinks.get(clientId);
        if (sink != null) {
            sink.tryEmitNext(message);
        }
    }

    public Flux<ServerSentEvent<String>> subscribe(String clientId) {
        Sinks.Many<String> sink = createSink(clientId);

        Flux<ServerSentEvent<String>> flux = sink.asFlux()
                .map(data -> ServerSentEvent.builder(data).build());

        // heartbeat to keep connections alive
        Flux<ServerSentEvent<String>> heartbeat = Flux.interval(Duration.ofSeconds(15))
                .map(i -> ServerSentEvent.<String>builder().comment("heartbeat").build());

        return Flux.merge(flux, heartbeat)
                .doOnCancel(() -> sinks.remove(clientId));
    }
}

/* Service */
@Service
public class SseService {

    private final Map<String, Sinks.Many<String>> sinks = new ConcurrentHashMap<>();

    public Sinks.Many<String> createSink(String clientId) {
        return sinks.computeIfAbsent(clientId,
                id -> Sinks.many().multicast().onBackpressureBuffer());
    }

    public void publish(String clientId, String message) {
        Sinks.Many<String> sink = sinks.get(clientId);
        if (sink != null) {
            sink.tryEmitNext(message);
        }
    }

    public Flux<ServerSentEvent<String>> subscribe(String clientId) {
        Sinks.Many<String> sink = createSink(clientId);

        Flux<ServerSentEvent<String>> flux = sink.asFlux()
                .map(data -> ServerSentEvent.builder(data).build());

        // heartbeat to keep connections alive
        Flux<ServerSentEvent<String>> heartbeat = Flux.interval(Duration.ofSeconds(15))
                .map(i -> ServerSentEvent.<String>builder().comment("heartbeat").build());

        return Flux.merge(flux, heartbeat)
                .doOnCancel(() -> sinks.remove(clientId));
    }
}

/* CONTROLLER */
@RestController
@RequestMapping("/sse")
public class SseController {
    @Autowire
    SseService sseService;

    @GetMapping(value = "/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    public Flux<ServerSentEvent<String>> stream(@QueryParam String userId) {
        return sseService.subscribe(userId)
    }
}

/* CONTROLLER */
@RestController
@RequestMapping("/sse")
public class SseController {
    @Autowire
    SseService sseService;

    @GetMapping(value = "/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    public Flux<ServerSentEvent<String>> stream(@QueryParam String userId) {
        return sseService.subscribe(userId)
    }
}

Esto es lo que sucede:

1. Cada cliente obtiene su propio receptor (un publicador reactivo).
2. Cuando el servidor llama a publish(clientId, message), ese mensaje se envía a todos los suscriptores.
3. Los latidos garantizan que los proxies no interrumpan la conexión.
4. Cuando un cliente se desconecta, el receptor se limpia.

Ventajas del enfoque reactivo

• No bloquea hilos
• Escala mejor con muchas conexiones abiertas
• Integración natural con bases de datos reactivas
• Soporte de backpressure

Conclusión

Los Server-Sent Events son una solución elegante y eficiente para escenarios donde el servidor necesita enviar información en tiempo real al cliente sin requerir comunicación bidireccional.

• Si necesitas simplicidad → SSE clásico con Spring MVC
• Si necesitas alta concurrencia y escalabilidad → SSE con WebFlux
• Si necesitas bidireccionalidad → WebSockets

En arquitecturas modernas basadas en microservicios y sistemas event-driven, SSE sigue siendo una herramienta extremadamente útil, especialmente cuando se combina con programación reactiva.

A lo mejor te interesa

What is HTTP Streaming and How Does it Work?

stomp-js/stompjs: Javascript and Typescript Stomp client for Web browsers and node.js apps

WebSockets – API web | MDN

Stack para Testing (Swarm + jMeter)

Real-Time Applications with Server-Sent Events (SSE) in Spring Boot | by Ishara Madusanka | Medium

The post Conexiones Real Time: Server Sent Events first appeared on RandomBitsOnFire.

Es común que cuando se diseña una arquitectura de aplicaciones no baste con el desarrollo de Tests Unitarios o Tests de Integraciones, y se pase a un nivel superior, llamando se así Pruebas de Rendimiento (Performance Testing).

Pruebas de rendimiento

Las Pruebas de Rendimiento son una técnica de testing que consiste en someter un sistema a un volumen de peticiones controlado para analizar cómo se comporta bajo condiciones reales o esperadas de uso.

No se trata solo de “ver si aguanta”, sino de entender:

• Cuándo empieza a degradarse el rendimiento
• Cómo responde el sistema cuando crece el tráfico
• Dónde están los cuellos de botella

Suelen a tender a las siguientes modalidades en base a la pregunta que se quiere contestar:

• Load testing → tráfico esperado normal
• Stress testing → llevar el sistema al límite
• Spike testing → picos bruscos de tráfico
• Soak testing → carga sostenida durante mucho tiempo

Optimización tras las pruebas

Una vez identificados los límites, el siguiente paso consiste en aplicar mejoras. Entre las más habituales encontramos:

• Aumento de memoria o CPU
• Ajustes de configuración (fine tuning)
• Pools de conexiones
• Pools de threads

En consecuencia, estas optimizaciones permiten escalar el sistema de forma controlada y eficiente.

Testing Tools

Un entorno de pruebas controlado no es un lujo, es una necesidad.

La combinación de:

• Docker Swarm (orquestación): Permite tener varias instancias de un contenedor y ver como se comporta en casos de balanceos
• Prometheus (métricas)
• Grafana (visualización)
• Spring Boot + Micrometer (instrumentación)
• jMeter

De este modo, se obtiene un ecosistema completo de observabilidad en local, muy cercano a producción y completamente reproducible.

Esto se traduce en menos errores, despliegues más seguros y sistemas más robustos.

Para ello encontré el siguiente stack que me vino de lujo para la monitorización de los diferentes micros, para ejecutar en entornos locales de prueba (y un buen maquinón xD):

https://github.com/stefanprodan/swarmprom

https://dockerswarm.rocks/swarmprom

Este stack integra Prometheus, Grafana y múltiples exporters listos para usar.

No obstante, en mi caso decidí simplificarlo ligeramente, eliminando componentes como el alerting o la integración con Slack, ya que no eran necesarios en un entorno local.

También quité Treffic y utilice accesos directo por localhost y sus respectivas apertura de puertos.

jMeter

Por otro lado, la generación de carga es una pieza clave. Para ello, utilicé Apache JMeter, una herramienta ampliamente utilizada en pruebas de rendimiento.

Sin embargo, jMeter suele venir bastante limitado de serie. Por esta razón, es recomendable ampliar sus capacidades mediante plugins.

En particular, una colección muy útil incluye:

• 3 Basic Graphs
• 5 Additional Graphs
• Composite Timeline Graph
• Custom Thread Groups
• Parallel Controller & Sampler

Gracias a estos plugins, es posible obtener una visión mucho más completa del comportamiento del sistema.

Resultados de Testing

Finalmente, el resultado es un conjunto de métricas y estadísticas que, aunque mejorables, ofrecen una base sólida para analizar la robustez de la solución planteada.

A partir de aquí, además, se pueden empezar a explotar métricas clave, detectar patrones de comportamiento y tomar decisiones informadas para mejorar el sistema.

Saludos and Happy Codding!!

The post Stack para Testing (Swarm+ jMeter) first appeared on RandomBitsOnFire.