 Mera, Fernando, es un informático de vocación e de profesión formadora ocasión e, como sempre, regina de comer e de ver. Esta última cada nota de alguns. Llega do 1996 montando proyectos en internet e os últimos de azoanis traando grandes proyectos internacionales para medios de comunicación online e empresas de comercio electrónico. Se necesitas algún consejo sobre rendimiento e doepros, no dures em pedirlo que sempre te descubrirá algo. En estos momentos, trabaja como consultor enterprise en sideground, consultor de desarrollo de negocio en gris e es el CEO de CTO, de las plataformas exprimeriajes e doormir de chovo e enseña doeprosa periodista en a fundación COPE. Tenéis un auténtico crack, así que a disfrutarlo. Gracias, Juanca. Gracias a la organización de Work and Barcelona por seleccionar mi charla. Gracias a todos por asistir a este track e teniendo al outro lado un persona como daría una charla tan increíble. Hoy vení a hablaros, como decía Juanca, de niveles escalados para WordPress. Lo primero, poco más que añadir a lo que ha dicho Juanca, me llamo Fernando Puente, me podéis encontrar en Twitter en ese puente online e estoy especializado en sitios de alto rendimiento. Llego aproximadamente 22 años en esto do mundo de las tecnologías de la información e unos 12 años relacionado con os mundos de los cemeses, sobre todo con WordPress. Trabajo, como decía Juanca, en diferentes sitios. Hoy consultor enterprise en sideground, desarrollo de negocio en gris. Soy CTE de veras plataformas prime viajes e dormir de chollo, soy amas formador, consultor freelance para todo lo que necesiteis. E como os decía en el título, vengo a hablaros hoy un poco de lo que es, niveles de escalado. Así que antes me gustaría dejar claro un poco lo que es escalado, que significa escalable. Un software realmente es escalado cuando el mismo se adapta en función del número de coticiones o número de recursos que vaya necesitando. Es decir, partiendo de esa premisa, lo primero que voy a decir es que WordPress no es escalable. Lo lamento aquellos que habéis presado que sí, pues no, realmente WordPress no es escalable. E voy a intentar explicarle en esta charla. Literalmente WordPress como tal no es escalable. Una solución escalable es aquella que está basada normalmente en microservicios, es aquella que está basada normalmente en módulos que pueden estar separados e podemos desplegar en cualquier tipo de infraestructura, pequeña o grande. E como bien sabéis, WordPress es un software, por así decirlo, monolítico. Va todo en el mismo paquete. Ojalá pudiéramos tener la verificación de usuarios en una máquina, el pintado del tema en otra, el tema de los recursos de la biblioteca en otra máquina. Eso sí haría que realmente WordPress fuera escalable. A día de hoy WordPress no es escalable. E también dejar claro que escalar no significa velocidad, que es un término que normalmente lo juntamos. Realmente, escalar significa que vamos a disponer de má recursos en nuestra infraestructura para estar preparados ante un pico o ante un número maior de solicitud de las que podemos atender. A veces, lo mezclamos con velocidad. Es decir, como eu pongo má recursos, mi máquina va a ir má rápido. No tiene por qué. Realmente tu máquina va a ir má desahogada. A lo mejor sí va má rápido, pero no es una consecuencia directa. Si tomamos como ejemplo cualquier proyecto web que seguro de desarrollar vosotros en un Google normal, tiene máso menos esta estructura. Un cliente, normalmente en dispositivo móvil, a través de internet, llega hasta nuestra infraestructura, nuestro paquete. Normalmente se compone de un Apache, se compone de sesogón de WordPress e se compone de nuestra base de datos. Este sería el proyecto web estándar, que es muy fácil de escalar. Realmente, escalar un proyecto es muy sencillo. Ahora lo vais a ver en un diagrama e seguro que vosotros mismo lo habéis hecho, aunque no tenéis esa conciencia de escalar. Pero este web se pode escalar facilísimamente. Rátidamente, sin tocar nada. Simplemente, colocando un ACD en intermedia, que pode ser Clauser, Max CDN, es decir, algo que nos permite despachar al usuario recursos estáticos del ACDN, es decir, llegan menos peticiones a nuestro servidor, podemos colocar la base de datos Maya SQL en vez de nuestro servidor en un servidor secundario, simplemente cambiando la dirección IP donde accedemos a la base de datos e podemos utilizar un ACD en externa para os recursos, por exemplo, como son las imágenes, como pode ser el caso de fotón. Con esta arquitectura, realmente, estaleamos escalando el proyecto. Disponemos de má recursos para nuestro proyecto e realmente, no hemos tocado nada. Realmente, lo que eu os quiera hablar es de escalar os sistemas, porque sa que veíamos al principio, al final, tiene un coelho de botella, que é o servidor de WordPress. E é onde quiera incidir para que podáis escalar ante proyectos enterprise, caídas, es decir, hacer que vuestros recursos sean má grandes predellendo pues eso, que necesiteis má o menos peticiones. Vamos a hacer en lo que seria unha ruta por los diferentes tipos de escalado. Desde lo que seria o que utilizábamos hace años, seguro que alguno vosotros empezasteis con este tipo de infraestructuras que era simplemente, en vosha instalaciones, colocar una máquina dedicada a un servidor. Normalmente, porque as empresas de hosting eran caras, el acceso era má complicado e, al final, o que teníamos é, dentro de nesta infraestructura un servidor, con un linos, un apache, un maio secuelo e demás. Esto realmente se ha quedado soleto e prácticamente nada utiliza este tipo de infraestructuras. Primeiro, porque peligra que se te vaya a la luz, peligra que se te vaya a internet, pero unha serie de cosas que nos garantiza o proveedor de hoste. Entonces, este seria o nivel má-bajo de escalado que ya prácticamente nos utiliza. A partir de aquí íamos a lo que se llaman los hosting compartidos, que hay de dos tipos. El má-bajo seria aquel, en el que compartís con cientos e incluso miles de webs, unha máquina física, lo que tenísis un espacio virtual dedicado a vosotros e en los que menos rendimento darían son aquellos que tienen la base de datos centralizada. Muy cercanos a éso, pois tamén serían aquellos hosting compartidos que tiene la base de datos en el mismo servidor. La diferencia un pouco de rendimento, como podeis pensar, es que se la base de datos está en outra máquina, hay un tiempo de latencia de red entre que comunique o WordPress con el servidor de base de datos, a diferencia de que se tenéis WordPress en la misma máquina. O siguiente nivel de escalado seria tener-lo el servidor disponible para mi. Pasaríamos de una infraestructura de hosting compartido a una infraestructura de servidor propio. El primer paso natural viniendo del hosting compartido seria lo que llamamos UDPS, o que serían también los servidores cloud. Donde tenemos una máquina dedicada para nosotros? Normalmente una máquina virtual, es decir, sobre una máquina grande tenemos una imagen. Dentro también de los servidores propios, el siguiente paso seria un servidor dedicado, donde la máquina físicamente está disponible para nosotros. Eso un nivel un poquito superior de potencia que el acceso a los recursos físicos de la máquina, memoria e disco, lo tenéis garantizado por vosotros. Es decir, está garantizado para vuestra máquina, a diferencia de los servicios cloud, donde competísen águnos recursos con el resto de webs que hay en esa máquina. A partir de aquí pasaríamos a los siguientes niveles que serían los que se llaman infraestructura. Llamaremos infraestructura a todo aquello que tienes dentro de tu sistema al menos dos máquinas. E a partir de ahí crecer. Lo primero seria tener una infraestructura dedicada, el típico ejemplo de tengo una máquina para el frontend e una máquina para el vaquen, en la máquina de frontend tendría la parte de servidor web e la parte de Wordpress e en la máquina de vaquen tendría ao má e secuel. Esto evidentemente es muchísimo más potente que la solución anterior. Seguiríamos en la ruta yendo una infraestructura cloud, que es un poquito más potente e incluso pode escalar muchísimo más que se tuviéramos una infraestructura dedicada porque al final lo que pudes previsionar má máquinas. Un pouco la diferencia entre dedicado e típico cloud es que o cloud es escalable, pode añadir má recurso fácilmente e o dedicado está limitado. E o último paso sería tener infraestructuras replicadas. Ésto sobre todo se utiliza en andres proyectos. Pensar que hay proyectos a nivel internacional donde lo que se hace en diferentes SCPDs es replicar las infraestructuras. Nos tenemos proyectos donde por ejemplo podemos dar servicio a Europa e lo tenemos en un SCPD colocado en Manchester, en Binago o que sea e esa misma infraestructura está replicada en Chicago. Que es o que se hace? Enrutar a cada uno dos usuarios a cada SCPD. Escalamos infraestructuras completas. Éste seria máso menos como podéis ver os ejemplos que veríamos e un pouco por extinguirlos tendríamos en la parte de la izquierda lo que se llaman los escalados por recursos. É decir pode añadir má memoria ran pode añadir má gigas má scores a mi procesador pode añadir má gigas a mi disco duro e a la derecha entendemos lo que se llama e vamos a ver ahora el escalado por tapas. É decir como escala los de la izquierda pues añadindo má recursos. Sería el concepto de escalado vertical. Se tengo dos gigas de memoria paso 4, paso 8 pero tiene una limitación. Mientras que el escalado por tapas podemos hacer así que sea realmente tendente al infinito e marcar sobre todo o que para mí es má importante disponer de sistemas que se llaman elásticos que en cualquier momento nos permitan subir o bajar la cantidad de recursos que tenemos a nuestra disposición bien se acorreglas de negocio o manualmente. Vamos a ver ese concepto de escalado por tapas o final donde os quiero llegar para crear proyectos WordPress escalables. O primeiro agente o tenéis clarísimo o primer escalado por tapas o escalado por servicios teria un má sencillo separar la parte de WordPress de la parte de base de datos. E a partir de ahí por escalado vertical que significa ampliar recursos en la misma máquina podemos seguir creciendo. Normalmente en una instalación estándar empezaríamos en una instalación WordPress empezaríamos sobre todo todos os usos en la parte de base de datos e menos en la parte de server web porque normalmente solemos necesitar má recursos se tenemos nuestro WordPress optimizado con sistemas de cache es decir damos de má inteligencia na parte de server web e ireamos cambiando un poquito o peso de cada uno de ellos. Siguiente nivel de escalado colocar por delante un proxy inverso o un balanceador es decir lo que hacemos en este nivel es que lleguen menos peticiones a nuestro server web en este caso a nuestro WordPress muchas de las peticiones en las que daría el seguidor proxy. Esto normalmente se utiliza que se viva gradíso escuchado con software tipo warnings tipo nx plus ese tipo de software colocamos. Lo que estamos haciendo es añadir capa de servicio e a partir de aí como digo abajo todo esto es compatible con cada capa vertical. Que infraestructura tendríamos en este caso? Tres máquinas virtuales que cada una de ellas poderia crecer en fonte de lo que necesitamos. A partir de aquí o siguiente nivel de escalado se llama el escalado de fontal es cuando ya unha sola máquina se nos queda pequeña bien porque el sistema que tenemos clout está limitado a un número de cores o número de memoria o bien porque estamos utilizando una infraestructura dedicada e no podemos crecer más lo que queríamos sería diversificar las peticiones entre diferentes server web. E se este aspecto que tenemos aquí que es o que se llama escalado vertical. Tengo alguien que balancea las peticiones por delante e distribuiría la información en función de las cargas en los diferentes server lo va distribuyendo a uno o outro. Asilismo estos vuelven a ser no solo vuelven a tener no solo un escalado horizontal sino que cada uno de ellas también puede escalar verticalmente con lo cual vamos generando muchísima máis capacidad a nuestro sistema. Outra capa que podéis hacer es la capa de la memoria virtual. Se trabajáis con cache de objetos trabajáis con redis trabajáis con bencache también lo podéis sacar a un sistema externo es decir, a unha máquina que os lleve esa gestión. En vez de tener vuestra gestión propia lo podéis sacar a una externa. Como veis al final o objetivo es todo e cada uno de los posibles servicios irlos atomizando irlos separando e acer que nuestra infraestructura sea cada vez máis grande a base de escalar esas capas. Siguiente nivel de escalado se nos ha quedado a parte de base de datos este es algo muy utilizado un sistema sobre todo de comercio electrónico porque hay muchas peticiones de escritura lo que hacemos es en la parte de daquén separarla en dos base de datos esto o que se denomina es una infraestructura maestros clavo en la parte de la derecha donde todas las peticiones de escritura irían a unha de base de datos e las peticiones de lectura para que no sean bloqueantes iría a outra de base de datos. Novamente estas infraestructuras se utilizan como decía cuando tenemos mucha transaccionalidad. Seguimos ireciendo igual que hemos hecho antes un escalado horizontal en la parte web podriamos hacer también en la parte de base de datos. Sería como tener unha pequeña granja de servidores de base de datos si normalmente vamos necesitando má recursos transaccionales. E en final lo que llegamos quando queremos hacer crecer muchísimo una infraestructura es algo que se conoce con el concepto de autoscalado que seguramente lo habéis escuchado tal veces. Que es o que hemos hecho a nivel de diseño de esa arquitectura separarla a una de las capas y a no que hacemos es que esas capas las separamos en contenedores que se autoscalan e por reglas de negocio le damos diciendo al sistema cuándo queremos que escale. Imaginaros pues oye quando una máquina llegue al 80% de moria instanza me otra o quando llegue al 50% haz que crezca un 10% máis vale en función de las reglas de negocio podemos ir haciendo que escala da diferentes capas. Qual es realmente la necesidad que tiene WordPress y es la que os pongo ahí con esa parte de almacenamiento compartido. WordPress se os acordáis ao principio de la charla o decía que es monolítico o era decir WordPress necesita acceder aos archivos. Se nós tenemos esa infraestructura esa escalada que teníamos a horizontal se os acordáis teníamos diferentes archivos se eu subo un archivo como os pedís imaginar un archivo físico una imagen un CSS o que sea a uno de los servidores como se entera o outro servidor bueno, pues o truco está en utilizar almacenamientos compartidos en todos e cada uno de ellos es decir todas as máquinas ven físicamente los mismos archivos de esa maneira en todos os vuestros WordPress en todas as vuestras instancias web tendríais la misma versión de documentos la misma versión de código la misma versión de plugins vale ese es un pouco el truco vale para que todos os WordPress tengan lo mismo ponési no os empiecerían a descoordenar pues como es lógico esto seria lo que hemos visto a nivel de de diagramas de arquitectura a nivel de dos diferentes pasos e si me gustaría dejaros claro algo que no dejava al principio que dejava la duda o proyecto realmente con WordPress no tiene el límite descalado el límite descalado o que va a poner la arquitectura de sistemas que vais a probar vale cada proyecto distinto es decir aquí hemos visto soluciones a nivel de diagrama que tendréis que identificar en función de vuestro proyecto no todo las soluciones funcionan igual ao mejor no las soluciones de próximo inverso no funcionan en vuestro sistema porque es de tipo gomelce electrónico pero sí interesa muchísimo más las soluciones relacionadas con crecer la parte de base de datos o al revés crecer la base de datos se tenéis un medio de comunicación no os interesa vía no que os interesan só dos sistemas de cacher es decir que este la parte de carga en en no más escalada posible la parte frontal vale es decir cada solución que tengáis é distinta así que aunque yo en lo diga e lo he dicho al principio que adiós volvó a decir que WordPress no escala porque como os he identificado en esta charla de hoy WordPress sí escala porque gracias a los sistemas podemos hacer que escale casi a estar infinito muchísimas gracias por accederando y ahora se ha vinto alguna pregunta se podéis ir levantando las manos non me como a nadie podéis preguntar sé que es duro esto a la arde de la mañana hola Fernando nano jonfron nos isto tenemos una infraestrutura parecida entre comidas a la que ponías pero vivimos muchas problemas para el nacionamento contactivo planos como un EFS estamos en alzo y nos sigan muy lento respuesta tienes alguna idea luego probamos outra solución es la que tenemos que la selección que mejor me ha funcionado a mi el problema es que con esa solución en el almacenamento compartido tienes los servidores por así decirlo en la nube e el almacenamento compartido en la nube es decir realmente va a través de internet por así decirlo para ver la mejor solución que a mi ha funcionado es que la infraestrutura físicamente normalmente en proyecto de tipo enterprise las típicas cabinas de discos e utilizamos GFS que es un acceso a nivel de red que es muchísimo má rápido e puedes provisionar de muchísimo má recursos al final lo que tienes es como una gran red de discos donde provisionas volúmenes e todos e cada uno de los recursos pueden acceder a eso lo que tienes que intentar buscar es que no haya latencia o que la latencia sea mínima entre donde está el servidor web e donde tienes el acceso a datos porque si no como bien dice seguro que os ha pasado se desynchroniza pensar que e no solo en los recursos de WordPress pensar incluso en el manejo de la sesión de PHP se tienes configurado un manejo de exigión de PHP contra disco es muy rápido que se desynchronicen e sin balanzador no está bien configurado te envía algo que no es es alta que el usuario no está logando en ese tipo de solución es el mejor para dar las sesiones de usuario a nivel de Mencache o a nivel de Redis e queda centralizado ese tipo de infraestructura e por exemplo nos temos dos TPs en ese caso en solución para lo que desfrase de la proximidad de los discos como darías igual que se tienen los TPs complicadas no se puede hacer replicación activa activa a nivel de de datos a nivel de en los dos pero claro replicación activa al final o que está haciendo es continuamente enviar tráfico de oye te has cambiado sí pues cambete tú también oye que me he cambiado se vas a tener mucho tráfico de red se ese tráfico de red está en la misma infraestructura va ir muy rápido se están infraestructuras separadas pues la verdad es que la verdad es que no complicada complicada por la latencia que tiene la red esa es muy difícil de saltársela que caras me ponéis por dios senón de conta juanca es bueno pues escalable sí hola hemos visto en los ejemplos de bueno máximos de escalamiento es decir todo por separado e igual de más en cada uno de los grupos ya un escalado horizontal e vertical e aí algun caso especialmente complicado por el que hayas pasado de escalamiento es que estás al final a limitación como vos decían a charla está la tienes un pouco en los recursos los mayores problemas igual que pregunto antes en el otro compañero estar en la parte esa de compartir ficheros si es un sitio con muchísima actividad necesitas que todos los ficheros estén estén disponibles entonces es un poco donde está el cuello de botella en esa sincronización de los archivos a nivel de Wordpress en todo e más son realmente infraestructuras que son estandadez e montar un un escalado horizontal de avalanciadores es una solución que existe montar un escalado horizontal de mayosequeles existe montar un sistema elástico que sea horizontal más vertical eso también existe con reglas de negocio la única diferencia es que como hay muy pocos casos que utilizan este tipo de infraestructuras de Wordpress en escalado horizontal realmente no hai soluciones estandard entonces es un pouco lo que tienes que montar a medida tú no vas a un Amazon a un proveedor de ese servicio e sale a un nación que Wordpress es escalado horizontal más vertical elástico ojalá la hubiera eso realmente se llama Wordpress BIP Wordpress BIP tiene ese tipo de infraestructuras conocéis Wordpress BIP? Wordpress BIP es una infraestructura que da automático una infraestructura de hosting que tiene este tipo de infraestructuras dentro tiene escalados horizontales e verticales nos tiene repartidas polidentes FPS pero se han hecho asimismo un desarrollo para mi o cuyo de botelha en este tipo de infraestructuras estaría en esa parte de los datos quales son los tucos? pues tener por ejemplo una infraestructura en producción e una infraestructura en preproducción hago los cambios en preproducción e cambio o avanciador a la infraestructura para que o usuario nos entere nos entere es decir te tienes que idear con tu ingenio diferentes soluciónes para dar solución a lo que realmente no tiene Wordpress a mi Wordpress me encantaria isto hubiera basado como lecia antes en infraestructura de microservicios que tú en vez de descargar un paquete te descargarás pequeños porque a veces necesitas crecer en una solución muy concreta no sé en la parte de gestión de usuarios o en la parte de entradas o en la parte de base de datos e que esa solución por sí misma fuera escalable e todas hablaran entre sí pero eso lo único que tenemos a día de hoy es la resapi que seria un escalado mínimo para separar la parte de pintado del tema de la parte de Wordpress liberamos a Wordpress del pintado pero es la única el único de esa coble que iremos hacer a día de hoy en Wordpress porque está construida sí es monolítico a no ser que mañana no perdón ayer en el contributo nos hubiéramos puesto todo de acuerdo y hubiéramos partido o core en instancias decireso vamos a dejarnos isto de Gutenberg e vamos a hacer un sistema realmente escalable no es tampoco es una necesidad real de la comunidad cuántos de aquí haces escalado horizontal en Wordpress muy, muy poquito no es realmente se puede hacer sí realmente no es no es la necesidad básica de Wordpress sí que el cierto que cada vez hay más proyectos grandes con Wordpress alguno de los de las infraestructuras nos enseñamos son proyectos incluso en España que tenemos hay proyectos grandes en España con cien torres de millones de páginas vistas al mes con Wordpress o sea que ya sí hay grandes grandes proyectos o sea que no digan tan pouco que no grandes proyectos con Wordpress mentira por aí no sé que nada por aí Allí bueno hola te que te voy a preguntar se no sé si tendrías como una especie de chaturista cien general como para probar una lugar qual sería la solución de escalado que necesitaríanos no como algo que te tienes que preguntar a ver normalmente la tipología de proyecto ya me indica cosas vale se un medio imagináos un blog un medio de comunicación normalmente en los recursos que va a consumir van a ser muchísimo máis estáticos entonces iríamos se tú te imaginas un pirámide cuando eu me imagino un proyecto de un medio de comunicación le doe la volta a la pirámide es decir un gran número de servidores de Word donde hago servicios de cache e sobretudo como cocedenes por delante es decir acerco los servicios al usuario e menos cargan la base de datos porque lo que quiero es que haya el menor número de peticiones posibles a la base de datos cuando son proyectos relacionados con comercio electrónico gestión de usuarios gestión de base de datos hago un pirámide muy poquitos recursos estáticos porque normalmente hay pocas solicitudes de imágenes de recursos e demás inclusive os cache en la cn pero hay mucha necesidad de base de datos o sa que la tipología de proyecto me va diciendo un pouco lo que voy necesitando lo que mejor te va servir como xenlis es monitorizar tus recursos tu propio sistema cuando ya esti optimizado o primeiro que te vas a hacer es antes de empezar a escalar como locos o primeiro a optimizar porque a lo mejor nos hace falta escalar eu me encuentro con proyectos moi moi moi grandes porque han puesto 32 cores 512 gb de mora e está a máquina al 1% e se jode por se acaso viene por se acaso viene quién se aunque vallamos todos a lla la uja a intentate lo pirar o al revés vale antes de optimizar tiene a máquina al 80% al 85% o primeiro que hay que hacer es optimizar ese corpres ese sistema que a veces para que os que habéis estado en la charla anterior de Pablo es simplemente hacer un recorrido por todas as boas prácticas que se tiene que hacer en cuanto a mejora del rendimiento e a partir de aí cuando hemos llegado al límite de optimización escalar para hacer pues eso que nuestro sistema pueda ascender bairro número de solicitudes el primer escalado sencillo ademas de ir haciendo la ruta seria o vertical pues e con 4 cores 4 gigas pues dois servicio a 500 usuarios no es no es exponencial o se perdón no es arismético con 8 cores 9 a 1000 pero más o menos podes ir haciendo ese tipo de cosas e se os invito a que utilicéis eso que denomino infraestructuras elásticas que tú le pueda decir al provedor vale lo más importante es que nos quedéis sin servicio vale que es lo que normalmente pasa la gente llama porque le sale un 503 tengo un 503 no hazlo previamente optimiza contourle a renegocio para que cuando a máquina este a 90% suba un 10% no dejegas en servicio porque eso es o peor peor de todo perdéis ventas perdéis credibilidad google os mira mal pasa de todo juanca como mámos el tiempo esta gente tiene cara de café alguna cosa rara alguien allí el amigo e van me guarás ganando entreponín personal a la hora de inventar una infraestructura elástica con que sistema e perdezora de utilización te quedas pero os udo me guare o me da o sea podes ser un sistema que te hagas incluso tú mismo que te hagas un contenedor sabes un basado en una distribución de linus te montes un container e realmente non le doe tanta importancia se da te lo te digo a eso pero supongo que el poder de hosting me lo va me lo va a solucionar en caso nuestro saiground es una implementación de linus containers pero aí pues ya sabes tipo wmware aí hay un montón hay un montón de ellos en si te si te digo quando hago la previsión me gusta más el escalado horizontal e voy a explicar qual que que el vertical cuando unha máquina sabes que hay grande poder de infraestructura que casi no tiene limitación podreais con decirle en función de a tarjeta de crédito que pulgáis cuando se saca el saldo decirle que escale cuando unha máquina empieza realmente a escalar a lo loco empieza a consumir consumir consumir má recursos normalmente es un error de código si escalo horizontalmente solo se me cae unha se escalo verticalmente se me cae todo el sistema me entiendes? es decir me gusta más el concepto de escalado horizontal que es más difícil también de implementar con las limitaciones que veíamos antes los alxivos tienen que estar compartidos en un solo punto e demas pero a mi me da mucha má seguridad ese tipo de escalado e me ha pasado en proyectos cuando unha máquina empieza a requerir recursos e cada 10 pode ser unha campaña en televisión pero si no tienes previsto no debería de pasarte pero normalmente es algo que os pode pasar en instalaciones grandes esos típicos plugins que normalmente tenéis de entradas recomendadas como seaman últimas entradas o entradas recomendadas para ti imaginámos en un sistema con alguno que tengo por aí 600.000 posts siriendo 100.000 páginas 100 minutos por dia imaginámos la cantidad de consultas que hacía ese plugin me tiraba la máquina la máquina podia estar alocando cada vez más recursos e afinal era un problema de programación non acababa nunca o proceso el problema es que non acababa nunca el proceso también me pasó en un medio de comunicación deportiva que hacíamos los minutos a minutos de los partidos pensar la gran cantidad de información que manejámos todos partidos de liga todos partidos de segunda todos partidos tal en tiempo real poner un sistema de caché cito de un plugin de caché pues nos tiraba también la máquina porque o plugin de caché estaba recalculando cada segundo un ajón que accedían 100.000 usuarios entonces o plugin de caché non acababa se yo hubiera activado un escalado vertical en esa máquina que estaría arruinado bueno no se me habría acabado antes el saldo de la tarjeta seguramente non me hubiera arruinado non sé si te respondo non te respondo a la pregunta e senora nos tomamos un cáce e discutimos lo que haza falta muchas gracias Fernando darle otra aplausión gracias