Programacion

17 February 2026 12:25

vale, ahora va todo echando ostias, ya se me hacía raro que una aplicación en local, fuera con esa lentitud

Programacion

17 February 2026 12:04

estaba cargando todo ... y claro, en employee, tengo company (relación bidireccional), una lista de equipos si es manager, TeamMember, TeamObserver (lista), department

Programacion

17 February 2026 12:02

con esto voy interiorizando que es correcto, lento y tal xd

Programacion

17 February 2026 12:01

ahora ya estoy en 43ms

Programacion

17 February 2026 11:59

TIME findAll: 145
TIME toDTO: 1

Programacion

17 February 2026 11:49

tengo un retraso bastante heavy desde spring —> bbdd

Programacion

17 February 2026 11:45

en la bbdd, obtener todo son 53mili segundos, desde pgadmin

Programacion

17 February 2026 11:43

TIME findAll: 697
TIME toDTO: 1

milisegundos

Programacion

17 February 2026 11:29

Porque la caché la tienes que crear, pero también ponerle un TTL, invalidarla en determinados casos...

No es cachear una vez y ya está 😂

Programacion

17 February 2026 10:24

os lo enseñaría, pero ahí ya hay información verdaddera

Programacion

17 February 2026 10:23

haré un caso de uso más o menos real, meteré 400 empleados (mi empresa tiene 400 aprox), a ver cuánto tarda.

Programacion

17 February 2026 08:56

yo lo pondría en un json con sincronización por tiempo, una vez hice eso porque los datos eran muchos, tuve que sacrificar la sincronización "in time" para actualizar el JSON cada hora, fue un asco y espero no hacerlo nuevamente pero funcionaba de maravilla

Programacion

17 February 2026 08:39

Bueno estaba buscando el nombre exacto y seria "revalidación bajo demanda" usando Cache Tags por ejemplo

Programacion

17 February 2026 08:37

Justo ahora me he escuchado un vídeo que mencionaba la caché, tiene su parte buena entiendo , pero si hay cambios en la BBDD depende como, no sé verán

Programacion

17 February 2026 08:36

Eso puede agilizar mucho

Programacion

17 February 2026 12:04

y claro, dentro de una consulta, pues como que habría unas cuantas más y todo lo que tenga que hacer para montar la entidad

Programacion

17 February 2026 12:03

cambiar en las relaciones entre tablas como obtener los datos, el fetchtype, eso de Lazy, Eager ... cargar una parte, cargarlo todo ...

Programacion

17 February 2026 12:01

TIME findAll: 31
TIME toDTO: 0

Programacion

17 February 2026 12:00

claro, las relaciones predeterminadamente son muchas EAGER y se está trayendo la biblia en la consulta

Programacion

17 February 2026 11:56

lo del retraso ya no se dice así, hay que tratar con más respeto a las personas

Programacion

17 February 2026 11:48

con psql, 0.7ms, ni un ms xD

Programacion

17 February 2026 11:43

    public List<EmployeeTableDTO> getEmployeListDTO() {
        // return employeeRepository.findAll()
        // .stream()
        // .map(EmployeeEntity::toTableDto)
        // .toList();

        long start = System.currentTimeMillis();

        List<EmployeeEntity> list = employeeRepository.findAll();

        long end = System.currentTimeMillis();
        System.out.println("TIME findAll: " + (end - start));

        start = System.currentTimeMillis();
        List<EmployeeTableDTO> listDTO = list
                .stream()
                .map(EmployeeEntity::toTableDto)
                .toList();
        end = System.currentTimeMillis();
        System.out.println("TIME toDTO: " + (end - start));
        return listDTO;
    }

Programacion

17 February 2026 11:34

De todas formas, si la consulta es lenta, el cacheo es no es una solución, es un parche al estilo "si no la miras no está"

La mayoría de las veces, son consultas muy mal escritas

Hay mucha gente que cree que con crear un índice, la base de datos lo usará, y eso no es así. Dependiendo de la query, a lo mejor ese índice no servirá de nada

Usar un ORDER BY en un conjunto muy grande de datos penaliza muchísimo el rendimiento, porque la base de datos tendrá que ordenar a base de chunks, usando disco. Y crear un índice para el ORDER BY, dependiendo de cómo esté escrita la consulta, tampoco significa que se vaya a usar

¿Solución que funciona? Reescribir la consulta de forma que use índices y obtenga los datos de manera más eficiente

Programacion

17 February 2026 10:45

si no lo decias no lo sabriamos

Programacion

17 February 2026 10:23

pero vamos, que mi web tarda 1 seg, la que usan actualmente .... no sé cómo será su bbdd pero yo para cargar información de 10 operarios, me muero esperando

Programacion

17 February 2026 10:22

no voy a hacer eso xD

Programacion

17 February 2026 08:41

me lo voy a apuntar todo, seguro que son cosas interesantes de aplicar aunque sea para prener

Programacion

17 February 2026 08:37

Supongo que habrá alguna forma de discriminación

Programacion

17 February 2026 08:36

Profiling, brotli/compresión, ISR

Programacion

17 February 2026 08:36

Cachear todo a menos que se mute la colección de empleados