querido líder, ponte las pilas!!!
- Autor del tema BILU
- Fecha de inicio
시켈 !
Lonchafinista.
- Desde
- 18 Feb 2010
- Mensajes
- 94.818
- Reputación
- 140.763
: ¿Pero cuánto se ha gastado este hombre en "cayenne" que por eso no ha podido tener mejor servidor?::ouch:Cayenne Pepper
Pimienta roja - Wikipedia, la enciclopedia libre
Joer, hay un hilo oficial para esto:
http://www.burbuja.info/inmobiliaria/guarderia/231766-entra-pon-una-foto-de-querido líder-arreglando-el-servidor-y-te-piras-4.html o
http://www.burbuja.info/inmobiliaria/guarderia/231766-entra-pon-una-foto-de-querido líder-arreglando-el-servidor-y-te-piras-4.html o
Por cierto, el server es un pepinón:
http://www.burbuja.info/inmobiliaria/burbuja-info/229627-en-breves-dias-nuevo-servidor-para-la-web.html
http://www.burbuja.info/inmobiliaria/burbuja-info/229627-en-breves-dias-nuevo-servidor-para-la-web.html
Cui Bono
So far, so good
- Desde
- 19 Jul 2007
- Mensajes
- 29.855
- Reputación
- 51.553
Da igual el maquinón si el problema es una realimentación de peticiones. En la máquina corren dos procesos:
- El servidor web.
- La base de datos
Nosotros solo interactuamos con el servidor web, que a su vez, internamente solicita los datos a la base de datos.
Los cuellos de botella son:
- El máximo número de peticiones atendibles por el servidor web. Aquí importa el numero de usuarios, la máquina y la velocidad de internete del usuario.
- El máximo número de peticiones a la base de datos y su spool (cola). Importa mucho la máquina, claro, pero también la gran variedad de configuraciones distintas para cacheado, tratamiento de colas, etc..
Llega un momento en que el sistema se realimenta. Nos tarda en servir la página y volvemos a pedirla, la base de datos colapsa después porque tiene menos peticiones que el server web, pero el servidor web debe cortar la conexión anterior o bien se la cortamos desde casa voluntariamente o automáticamente (nuestro navegador decide que no habrá respuesta y eso origina nuevas peticiones).
Es algo así:
- Pido la página al server web.
- El server pide información estructurada, dentro de la misma máquina, a la base de datos.
- La base de datos se la devuelve y el server la formatea y devuelve al usuario.
querido líder necesita un experto y no mucha más máquina.
Quizás habría que cachear las imágenes. En vez de que se nos entregue una página html que tiene enlaces a imágenes (y que origina nuevas peticiones al server web) se puede devolver la imagen directamentamente, codificada en base64. Esto es muy común.
El funcionamiento ahora sería:
- Pido la página al server web.
- El server pide información estructurada, dentro de la misma máquina, a la base de datos.
- La base de datos se la devuelve y el server la formatea.
- El server comprueba los enlaces de las imágenes, substituye los iconos más comunes directamente y el resto de imágenes las pide a OTRA máquina en la que corre otro servidor de bases de datos.
- Si este segundo servidor de datos no tiene la imagen formateada a base64, el server web devuelve el enlace pero le pide a esta segunda máquina que lo formatee y almacene, para tenerla para una posterior petición. Este procesado de la imagen se haría con mucha menos prioridad en la segunda máquina.
- Por último, el server devuelve la página, con gran parte de los tags IMG como base64 y no como enlaces de vuelta a burbuja.info.
Ventajas:
-Menos peticiones, muchas menos. Ya no hay petición para los iconos, para los avatares, firmas, etc.. Lógicamente me refiero a imágenes del server, no las que se pidan a imageshack, gravatar y otras webs.
- Mucho más rápida la contestación entre la maquina principal y el server de imágenes cacheadas que entre la máquina principal y los usuarios pidiendo imágenes.
- En caso de sobrecarga en tiempo de respuesta de la máquina principal, es la segunda máquina la sacrificada, con la pérdida planificada de las imágenes (al menos tendríamos el texto). Esto quizás se pueda hacer.
- Si la página no ha cambiado (misma firma en respuesta de la base de datos) no hacen falta las peticiones de imágenes a la segunda máquina, se devuelve un HTML cacheado.
- Se puede hacer lo mismo con los scr_ipts que no sean muy largos, devolverlos en el mismo documento, teniendo aún menos peticiones web al server.
- Se evita la realimentación del F5. Todos los tiempos perdidos de máquina debido a las rpeticiones de petición de máquina pueden compensar el hecho de que las páginas pesen más.
Inconvenientes:
- Más peso de la página a devolver, pues contendría las imágenes también. Se compensa con el hecho de que el navegador del usuario no pedirá las imágenes después.
- Se desperdiciaría la capacidad de las máquinas de los usuarios para cachear las imágenes, que serían devueltas una y otra vez.
Esta solución parte de la suposición de que parte del problema es el usuario y el F5, que dobla las peticiones cuando se impacienta, y que el cuello de botella es Apache y no tanto MySQL.
Me hace pensar eso el hecho de que es mucho más frecuente el cuelgue que el mensaje de error de la base de datos.
- El servidor web.
- La base de datos
Nosotros solo interactuamos con el servidor web, que a su vez, internamente solicita los datos a la base de datos.
Los cuellos de botella son:
- El máximo número de peticiones atendibles por el servidor web. Aquí importa el numero de usuarios, la máquina y la velocidad de internete del usuario.
- El máximo número de peticiones a la base de datos y su spool (cola). Importa mucho la máquina, claro, pero también la gran variedad de configuraciones distintas para cacheado, tratamiento de colas, etc..
Llega un momento en que el sistema se realimenta. Nos tarda en servir la página y volvemos a pedirla, la base de datos colapsa después porque tiene menos peticiones que el server web, pero el servidor web debe cortar la conexión anterior o bien se la cortamos desde casa voluntariamente o automáticamente (nuestro navegador decide que no habrá respuesta y eso origina nuevas peticiones).
Es algo así:
- Pido la página al server web.
- El server pide información estructurada, dentro de la misma máquina, a la base de datos.
- La base de datos se la devuelve y el server la formatea y devuelve al usuario.
querido líder necesita un experto y no mucha más máquina.
Quizás habría que cachear las imágenes. En vez de que se nos entregue una página html que tiene enlaces a imágenes (y que origina nuevas peticiones al server web) se puede devolver la imagen directamentamente, codificada en base64. Esto es muy común.
El funcionamiento ahora sería:
- Pido la página al server web.
- El server pide información estructurada, dentro de la misma máquina, a la base de datos.
- La base de datos se la devuelve y el server la formatea.
- El server comprueba los enlaces de las imágenes, substituye los iconos más comunes directamente y el resto de imágenes las pide a OTRA máquina en la que corre otro servidor de bases de datos.
- Si este segundo servidor de datos no tiene la imagen formateada a base64, el server web devuelve el enlace pero le pide a esta segunda máquina que lo formatee y almacene, para tenerla para una posterior petición. Este procesado de la imagen se haría con mucha menos prioridad en la segunda máquina.
- Por último, el server devuelve la página, con gran parte de los tags IMG como base64 y no como enlaces de vuelta a burbuja.info.
Ventajas:
-Menos peticiones, muchas menos. Ya no hay petición para los iconos, para los avatares, firmas, etc.. Lógicamente me refiero a imágenes del server, no las que se pidan a imageshack, gravatar y otras webs.
- Mucho más rápida la contestación entre la maquina principal y el server de imágenes cacheadas que entre la máquina principal y los usuarios pidiendo imágenes.
- En caso de sobrecarga en tiempo de respuesta de la máquina principal, es la segunda máquina la sacrificada, con la pérdida planificada de las imágenes (al menos tendríamos el texto). Esto quizás se pueda hacer.
- Si la página no ha cambiado (misma firma en respuesta de la base de datos) no hacen falta las peticiones de imágenes a la segunda máquina, se devuelve un HTML cacheado.
- Se puede hacer lo mismo con los scr_ipts que no sean muy largos, devolverlos en el mismo documento, teniendo aún menos peticiones web al server.
- Se evita la realimentación del F5. Todos los tiempos perdidos de máquina debido a las rpeticiones de petición de máquina pueden compensar el hecho de que las páginas pesen más.
Inconvenientes:
- Más peso de la página a devolver, pues contendría las imágenes también. Se compensa con el hecho de que el navegador del usuario no pedirá las imágenes después.
- Se desperdiciaría la capacidad de las máquinas de los usuarios para cachear las imágenes, que serían devueltas una y otra vez.
Esta solución parte de la suposición de que parte del problema es el usuario y el F5, que dobla las peticiones cuando se impacienta, y que el cuello de botella es Apache y no tanto MySQL.
Me hace pensar eso el hecho de que es mucho más frecuente el cuelgue que el mensaje de error de la base de datos.
ronald29780
Mercutio
- Desde
- 11 Sep 2007
- Mensajes
- 33.592
- Reputación
- 15.006
Cui Bono
So far, so good
- Desde
- 19 Jul 2007
- Mensajes
- 29.855
- Reputación
- 51.553
Lo tiene a huevo, hay un módulo de Apache para eso:
Apache mod_pagespeed settings < System | The Art of Web
Por lo menos lo de las imágenes inline o los scri_pts inline se pueden incluir con ese mod_ e ir probando otras cosas con él, con cuidado.
Lo que no puede ser es que cada avatar y cada iconito genere peticiones cuando puestas inline esas imágenes se quedan en el documento original incrementando sólo unos kbytes a él y evitando nuevas peticiones al mismo server y más retrasos y recursos.
Apache mod_pagespeed settings < System | The Art of Web
Por lo menos lo de las imágenes inline o los scri_pts inline se pueden incluir con ese mod_ e ir probando otras cosas con él, con cuidado.
Lo que no puede ser es que cada avatar y cada iconito genere peticiones cuando puestas inline esas imágenes se quedan en el documento original incrementando sólo unos kbytes a él y evitando nuevas peticiones al mismo server y más retrasos y recursos.
Leí hace tiempo en webhostingtalk.com de un servidor web llamado litespeed, es compatible con la config de apache y decían que era buenísimo, aunque caro, pero que evitaba el tener que cambiar las máquinas de lo rápido que era.
willbeend
Madmaxista
A no ser que el problema este claramente en el diseño de la aplicacion, se podria dedicar una maquina a cada uno de los servicios.
Es lo mas corriente, un servidor para la web y un servidor para la base de datos.
Ademas, por cuestion de seguridad, la gente no estaria conectada al servidor que lleva los datos.
fayser
Será en Octubre
- Desde
- 7 Feb 2008
- Mensajes
- 28.572
- Reputación
- 76.474
Primera regla de la optimización: no elucubres, mide.
Similar threads
