El tráfico tumba mi frontend web hecho con nuxt.js

Hola, tengo un sitio web que está recibiendo cada vez más tráfico y estoy empezando a tener problemas con el rendimiento.

Mi sitio se compone de un frontend hecho con nuxt.js en modo Server Side Rendering. Debe ser así por el tema del SEO. Si no, habría elegido SPA mode.
Es una "web automática" con más de 50.000 páginas de producto diferentes, que actualiza cada hora los precios de los artículos en diferentes tiendas.

El frontend hace peticiones a una api hecha con laravel. La api va como un tiro y sin problemas. Aguanta todo lo que le eches.

El problema es con el front en nuxt.js
Monitoreando los procesos de ubuntu con el comando top, node (el que ejecuta nuxt.js y renderiza las vistas para mostrarlas al cliente) consume muchísima CPU y memoria.

Cuando se juntan 30 usuarios a la vez y coincide que el crawler de google me está analizando las páginas, se cae el frontend. La api sigue funcionando sin problemas en esos momentos.

Estas son las especificaciones de la máquina en Digitalocean.


Existe alguna solución? Cachear las páginas de alguna manera? Lo tengo montado todo con apache2.

¿Por qué no migras a AWS? Ellos dan recursos según uses.

Aquí un tema de Github donde hablan sobre ello: https://github.com/nuxt/nuxt.js/issues/8370

mira a ver si tienes todos los paquetes actualizados ( apache etc... ) otra opcion es usar nginx que supuestamente puede manejar mas usuarios a la vez pero de todas formas creo que si necesitaras algo mas de procesador

Sí, el server side rendering quema muchos recursos, por eso uso más generadores de páginas estáticas para evitar desde raíz ese problema.

Por cierto, ¿no estará ejecutando algún paquete de dev en producción? Al menos ese problema es bastante típico en React con Next.js y la verdad sí te aumenta mucho la carga.

Charlie Araiza dijo:

Sí, el server side rendering quema muchos recursos, por eso uso más generadores de páginas estáticas para evitar desde raíz ese problema.

Por cierto, ¿no estará ejecutando algún paquete de dev en producción? Al menos ese problema es bastante típico en React con Next.js y la verdad sí te aumenta mucho la carga.

Hacer clic para expandir...

Efectivamente, tenía paquetes de dev en producción. He hecho npm install --production. Siempre se aprende algo nuevo 😉

Pero es imperceptible. Haciendo F5 muchas veces y poniendo al lado el monitor top de linux, se puede apreciar cómo node llega al 60% hasta incluso tirar la web unos segundos. Ahora mismo soy muy vulnerable y la competencia me puede tirar la web fácilmente.

Respecto a la generación de páginas estáticas lo estudié un poco por encima y he visto que es tendencia ahora. Lo probé vagamente en mi proyecto en un servidor a parte. Me pasó que los estilos css se rompieron bastante. Y las funcionalidades con javascript en elementos interactivos como cajas de búsqueda, llamadas ajax, sliders, etc dejaron de funcionar.
Tampoco me veo generando 50.000 páginas cada hora para actualizar precios. Van a ser muchas más en el futuro.

Dinero Infinito dijo:

Efectivamente, tenía paquetes de dev en producción. He hecho npm install --production. Siempre se aprende algo nuevo 😉

Pero es imperceptible. Haciendo F5 muchas veces y poniendo al lado el monitor top de linux, se puede apreciar cómo node llega al 60% hasta incluso tirar la web unos segundos. Ahora mismo soy muy vulnerable y la competencia me puede tirar la web fácilmente.

Respecto a la generación de páginas estáticas lo estudié un poco por encima y he visto que es tendencia ahora. Lo probé vagamente en mi proyecto en un servidor a parte. Me pasó que los estilos css se rompieron bastante. Y las funcionalidades con javascript en elementos interactivos como cajas de búsqueda, llamadas ajax, sliders, etc dejaron de funcionar.
Tampoco me veo generando 50.000 páginas cada hora para actualizar precios. Van a ser muchas más en el futuro.

Hacer clic para expandir...

Y que tal mejoro la situación? quiero migrar un proyecto que tengo en laravel pasarlo a nuxt, son unas 200k visitas diarias.
Tengo una API en laravel, y es muy pesada muchas midlewares que no se usan para la API asi que la migre a LUMEN y el rendimiento mejoro mucho. Pero ahora con el nuevo cambio pasare a usar express.

m16u31 dijo:

Y que tal mejoro la situación? quiero migrar un proyecto que tengo en laravel pasarlo a nuxt, son unas 200k visitas diarias.
Tengo una API en laravel, y es muy pesada muchas midlewares que no se usan para la API asi que la migre a LUMEN y el rendimiento mejoro mucho. Pero ahora con el nuevo cambio pasare a usar express.

Hacer clic para expandir...

No sé notó nada. Estoy mirando para hacerla estática (Static Site Generation) y que pillé por ajax cosas como precios actualizados y tal. Pero me va a tomar tiempo adaptar código y no tengo tiempo ni ganas. Hay cosas que cambian de SSR a SSG.

O meterle varnish cache. Esto último me está dando dolores de cabeza puesto que varnish es difícil de usar y por defecto no cachea las páginas que usan cookies.
Lo malo de varnish cache es que aunque te cachee las páginas, el crawler de Google podría seguir tirándolas al recorrer el sitemap y crawlear a la vez cientos que no estén cacheadas.
Otra opción es subir la potencia al servidor 8gb de ram y 2 cpu. Pero es carísimo y excesivo. Como matar moscas a cañonazos.

No conozco nuxt pero algo he hecho con next, recuerdo que hay una característica que te permite que la web no renderice cada petición, que la mantiene cacheada y muestras el precio viejo, y solo mandas el precio nuevo actualizado.
Creo que este es el link, pero no recuerdo bien como funcionaba. Luego recuerdo haber encontrado swr (https://swr.vercel.app/docs/with-nextjs) que se sincronizaba bien con next y ellos se encargaban de mantener los datos generados a la par que actualizárselos en tiempo real al usuario.

Dinero Infinito dijo:

No sé notó nada. Estoy mirando para hacerla estática (Static Site Generation) y que pillé por ajax cosas como precios actualizados y tal. Pero me va a tomar tiempo adaptar código y no tengo tiempo ni ganas. Hay cosas que cambian de SSR a SSG.

O meterle varnish cache. Esto último me está dando dolores de cabeza puesto que varnish es difícil de usar y por defecto no cachea las páginas que usan cookies.
Lo malo de varnish cache es que aunque te cachee las páginas, el crawler de Google podría seguir tirándolas al recorrer el sitemap y crawlear a la vez cientos que no estén cacheadas.
Otra opción es subir la potencia al servidor 8gb de ram y 2 cpu. Pero es carísimo y excesivo. Como matar moscas a cañonazos.

Hacer clic para expandir...

estas usando redis, memcache o algo para cachear las consultas a la BD?

m16u31 dijo:

estas usando redis, memcache o algo para cachear las consultas a la BD?

Hacer clic para expandir...

No, pero he hecho pruebas con respuestas de la api puestas a piñón. No es por lentitud de la api.