Moodlers:
¿Cómo puedo optimizar el uso del CPU (en servidor remoto). ¿Pueden señalar cómo otimizo los scripts de moodle?
Saludos.
José de Jessús.
Paz y Bien.
Moodlers:
Saludos.
José de Jessús.
Moodlers:
Saludos.
José de Jessús.
En mi opinión la mejor opción es usar sistemas de cache para servidor (squid, apc, etc...) combinados con aceleradores php (eaccelerator, xcache, etc..)
Aquí tienes la definición exacta de lo que es un acelerador php y enlaces a listas comparativas de los aceleradores más populares: http://en.wikipedia.org/wiki/List_of_PHP_accelerators. Según menciona el artículo, la mejora puede reducir la carga del servidor e incrementar la velocidad de ejecución del código PHP entre 2 y 10 veces, dependiendo de múltiples factores como el tiempo de ejecución de la aplicación PHP y la cantidad de código ejecutado en cada petición.ç
Yo no tengo mucha experiencia con aceleradores, pero en cuanto a sistemas de caché, Moodle, por la forma en que está diseñado, es ideal para usar sistemas de caché. En una Moodlemoot en la que estuve el año pasado, hubo un taller sobre el tema de sistemas de caché, y aunque las pruebas que hicieron no reflejaban un escenario real, solo por la cantidad de peticiones a base de datos que se ahorran entre el sistema de cache y una buena configuración de la caché de la base de datos, te puedes ahorrar un buen montón de recursos y tiempo de respuesta.
En cualquier caso, personalmente creo que para afrontar procesos de optimización es imprescindible contar con buenas estadísticas de uso (tráfico, peticiones a bd, uso de disco, etc..) sino simplemente estarás haciendo los ajustes a ciegas. Además, la configuración que puede valer en un periodo determinado, puede ser perjudicial en otro momento. Mi consejo es que recojas estadísticas monitorizando el uso del servidor en distintos periodos, y a partir de ahí decidas qué partes del sistema (MySQL, PHP, servidor, cliente, etc...) se podrían mejorar y cuales no. A veces es solo cuestión de afinar un poco la configuración del servidor http.
Aquí tienes la definición exacta de lo que es un acelerador php y enlaces a listas comparativas de los aceleradores más populares: http://en.wikipedia.org/wiki/List_of_PHP_accelerators. Según menciona el artículo, la mejora puede reducir la carga del servidor e incrementar la velocidad de ejecución del código PHP entre 2 y 10 veces, dependiendo de múltiples factores como el tiempo de ejecución de la aplicación PHP y la cantidad de código ejecutado en cada petición.ç
Yo no tengo mucha experiencia con aceleradores, pero en cuanto a sistemas de caché, Moodle, por la forma en que está diseñado, es ideal para usar sistemas de caché. En una Moodlemoot en la que estuve el año pasado, hubo un taller sobre el tema de sistemas de caché, y aunque las pruebas que hicieron no reflejaban un escenario real, solo por la cantidad de peticiones a base de datos que se ahorran entre el sistema de cache y una buena configuración de la caché de la base de datos, te puedes ahorrar un buen montón de recursos y tiempo de respuesta.
En cualquier caso, personalmente creo que para afrontar procesos de optimización es imprescindible contar con buenas estadísticas de uso (tráfico, peticiones a bd, uso de disco, etc..) sino simplemente estarás haciendo los ajustes a ciegas. Además, la configuración que puede valer en un periodo determinado, puede ser perjudicial en otro momento. Mi consejo es que recojas estadísticas monitorizando el uso del servidor en distintos periodos, y a partir de ahí decidas qué partes del sistema (MySQL, PHP, servidor, cliente, etc...) se podrían mejorar y cuales no. A veces es solo cuestión de afinar un poco la configuración del servidor http.
Paz y Bien.
Xavier:
Mil gracias.
Saludos.
José de Jesús
Xavier:
Eso es precisamente lo que estamos realizando los dos administradores, revisar las estadisticas, el uso de recursos del disco, usuarios, páginas.
También, descubrímos qué curso está utilizando más recursos y porqué.
En cuanto a lo primero que comentas desconozco el procedimeinto, ya está en un servidor remoto y ya cuentas con el optimizerphp, sin embargo, le enviaré un ticket al provedor para conocer sobre el sistema caché del servidor.
Se cierra el post.
También, descubrímos qué curso está utilizando más recursos y porqué.
En cuanto a lo primero que comentas desconozco el procedimeinto, ya está en un servidor remoto y ya cuentas con el optimizerphp, sin embargo, le enviaré un ticket al provedor para conocer sobre el sistema caché del servidor.
Se cierra el post.
Mil gracias.
Saludos.
José de Jesús
Paz y Bien.
Moodlers:
Saludos.
José de Jesús
Moodlers:
Había cerrado este post, pero como hemos descubirto otras cosas, lo reabro, les expongo qué sucedió y cómo lo mejoramos.
A de partir de la última semana de marzo al 22 de abril de este año, se inició un registro inusual en la bitácora de accesos, pero cuando estábamos revisándola, recibimos un mensaje del provedor de host, por el uso excesivo de CPU.
Bueno, después de varios días de desvelo, encontramos en los registros, el uso de foros, cuestionarios era eleavado, entonces:
Configuramos la actividad de Foro para que no subieran archivos. En cuanto a los cuestionarios, también se actualizaron, de modo que utilizaran menos recursos, porque los grupos son numerosos.
Encontramos, las direcciones de varias IP's que entraban a la platafoma (considerando las diferencias de horarios) eran diferentes a las registradas en los Informes de Moodle; bueno, hasta la fecha, estamos revisando últimos accesos.
Mucas gracias por Xavier por tus sugerencias.
A de partir de la última semana de marzo al 22 de abril de este año, se inició un registro inusual en la bitácora de accesos, pero cuando estábamos revisándola, recibimos un mensaje del provedor de host, por el uso excesivo de CPU.
Bueno, después de varios días de desvelo, encontramos en los registros, el uso de foros, cuestionarios era eleavado, entonces:
Configuramos la actividad de Foro para que no subieran archivos. En cuanto a los cuestionarios, también se actualizaron, de modo que utilizaran menos recursos, porque los grupos son numerosos.
Encontramos, las direcciones de varias IP's que entraban a la platafoma (considerando las diferencias de horarios) eran diferentes a las registradas en los Informes de Moodle; bueno, hasta la fecha, estamos revisando últimos accesos.
Mucas gracias por Xavier por tus sugerencias.
Saludos.
José de Jesús
Unas medidas muy adecuadas pero me queda una duda ¿a qué te refieres exactamente con que actualizasteis los cuestionarios? ¿podrías dar más detalles de ese aspecto?
Paz y Bien.
Xavier:
Con la actualización de los cuestionarios quiero decir, la edición de la configuración. Había 10 cuestionarios activos, todos estaban en modo adaptativo, los intentos estaban sin límite, y estaban activas las casillas de "Revisar opciones", imaginate, son 5 grupos con un promedio de 30 estudiantes, 5580 Hits, 3.04%, 242900 Kb, 12.59% en menos de un mes.
Te comento que usar el tema en el sitio fue aardvark_beta generó un flujo bastante alto de hits, descarga de los iconos, las imágenes, los menús, etcétera, por esa razón, se quito el tema y se configuró otro más simple.
Ha sido un mes muy difícil, pero hemos salido adelante. Seguimos aprendiendo.
Muchas gracias por tus sugerencias.
Saludos.
José de Jesús.
Xavier:
Con la actualización de los cuestionarios quiero decir, la edición de la configuración. Había 10 cuestionarios activos, todos estaban en modo adaptativo, los intentos estaban sin límite, y estaban activas las casillas de "Revisar opciones", imaginate, son 5 grupos con un promedio de 30 estudiantes, 5580 Hits, 3.04%, 242900 Kb, 12.59% en menos de un mes.
Te comento que usar el tema en el sitio fue aardvark_beta generó un flujo bastante alto de hits, descarga de los iconos, las imágenes, los menús, etcétera, por esa razón, se quito el tema y se configuró otro más simple.
Ha sido un mes muy difícil, pero hemos salido adelante. Seguimos aprendiendo.
Muchas gracias por tus sugerencias.
Saludos.
José de Jesús.
Ahora lo entiendo. Si, la verdad es que eso puede llegar a generar un volumen considerable de peticiones, sobre todo porque son consultas poco habituales, de recopilación de información (SELECT con join) y eso en general suele ser costoso.
En cuanto al aspecto del tema de apariencia, es un ejemplo claro de una situación donde podría funcionar perfectamente el sistema de caché.
Los gráficos e imágenes del tema son elementos requeridos muy habitualmente, de hecho casi siempre hay alguno presente en pantalla, por tanto serían candidatos ideales a estar almacenados en el sistema de caché.
Cada vez que alguien pasara de una página a otra, el sistema usaría la versión del elemento alojada en caché en vez de realizar una nueva petición al servidor HTTP, con el consiguiente ahorro de recursos y ancho de banda.
En este caso funciona pues son elementos estáticos, que no se generan al vuelo con cada petición, por tanto yo consideraría seriamente el uso del sistema de caché para este tipo de situaciones.
En cuanto al aspecto del tema de apariencia, es un ejemplo claro de una situación donde podría funcionar perfectamente el sistema de caché.
Los gráficos e imágenes del tema son elementos requeridos muy habitualmente, de hecho casi siempre hay alguno presente en pantalla, por tanto serían candidatos ideales a estar almacenados en el sistema de caché.
Cada vez que alguien pasara de una página a otra, el sistema usaría la versión del elemento alojada en caché en vez de realizar una nueva petición al servidor HTTP, con el consiguiente ahorro de recursos y ancho de banda.
En este caso funciona pues son elementos estáticos, que no se generan al vuelo con cada petición, por tanto yo consideraría seriamente el uso del sistema de caché para este tipo de situaciones.
hola
relacionado con los cuestionarios hay lo siguiente. si las preguntas tienen imágenes, la pregunta se demora un poco más en cargar. la pregunta es: ¿qué tan útil seria subir las imágenes al servicio de picasa de google, y hacer el respectivo enlace?, ¿será que disminuye la carga del servidor y/o las preguntas se cargan más rápido?
chao
relacionado con los cuestionarios hay lo siguiente. si las preguntas tienen imágenes, la pregunta se demora un poco más en cargar. la pregunta es: ¿qué tan útil seria subir las imágenes al servicio de picasa de google, y hacer el respectivo enlace?, ¿será que disminuye la carga del servidor y/o las preguntas se cargan más rápido?
chao
Paz y Bien.
Marlon:
Esa fue unas de las actualizaciones que se hicieron, ya que sí contenían imágenes, llamadas desde el servidor, la sugerencia fue esa exactamente, la que mensionas, llamarlas desde un banco de imágenes.
Si ha bajado de manera considerable el flujo.
Saludos.
José de Jesús.
Marlon:
Esa fue unas de las actualizaciones que se hicieron, ya que sí contenían imágenes, llamadas desde el servidor, la sugerencia fue esa exactamente, la que mensionas, llamarlas desde un banco de imágenes.
Si ha bajado de manera considerable el flujo.
Saludos.
Como bien dices y responde José de Jesús, la carga del servidor se reduce ya que cuando procesa el página que contiene dichas imágenes, la petición la resuelve otro servidor, por tanto no se dedican recursos a ello, simplemente se espera la respuesta del otro servidor.
Por otro lado, la velocidad de carga de la página dependerá del tiempo de respuesta del servidor que aloja las imágenes, pero en general suele ser una solución muy recomendable.
Por otro lado, la velocidad de carga de la página dependerá del tiempo de respuesta del servidor que aloja las imágenes, pero en general suele ser una solución muy recomendable.