Recomendaciones sobre desempeño

De MoodleDocs
Desempeño

Nota: Esta es una traducción de una página de la documentación en idioma Inglés (Docs), que se considera particularmente importante, y que en su versión original se actualiza frecuentemente. Por ello, se le recomienda que revise la página original en idioma inglés: Performance recommendations.

Esta página necesita actualizarse con la información existente en la documentación vigente/moderna/actualizada en el idioma inglés original para Moodle. Se le sugiere al lector que consulte la página original en idioma inglés cuyo enlace está al fondo de esta página. y que, por favor, actualice esta información y quite la plantilla {{Actualizar}} cuando haya terminado.     (otras páginas pendientes de actualizar)


Puede lograrse que Moodle se desempeñe muy bien, en pequeña escala o escalándolo a varios miles de usuarios. Los factores involucrados en el desempeño son básicamente los mismos para todos los sistemas construídos con BasedeDatos y basados en PHP. Al tratar de optimizar su servidor, trate de enfocarse en los factores que harán las diferencias más notables para el usuario. Por ejemplo, si su sitio tiene relativamente más usuarios ojeando en lugar de accediendo a la base de datos, busque mejorar el desempeño del servidor web.


Obtenga un punto de referencia inicial

Antes de intentar ninguna optimización, Usted debería de obtener un punto de referencia inicial del componente del sistema que está intentando mejorar. Para Linux intente LBS y para Windows use el Monitor de Rendimiento. Una vez que tenga datos cuantitativos acerca de cómo se está desempeñando actualmente su sistema, podrá determinar si es que el cambio que ha realizado ha tenido algún impacto real.

El objetivo general de los ajustes para mejorar el desempeño es usar RAM (caché) y reducir la actividad basada en disco. Ésto es especialmente importante al tratar de eliminar el uso del archivo de intercambio tanto cómo se pueda. Si su sistema empieza a intercambiar memoria virtual por disco, éste es un signo de que necesita más RAM.

La preferencia del órden de optimización es usualmente: almacenamiento primario (más RAM), almacenamiento secundario (discos duros más veloces/mejora de configuración del disco duro), procesador (más y más veloces).

Pudiera ser interesante el instalar y utilizar el plugin Benchmark para encontrar los cuellos de botella de su sistema que afectan específicamente a Moodle.

Escalabilidad

El diseño de Moodle (con una clara separación de las capas de aplicaciones) permite configuraciones fuertemente escalables. (Por favor revise la lista de Instalaciones Grandes de Moodle].)

Los sitios grandes usualmente separan al servidor web y la BasedeDatos en servidores separados, aunque para instalaciones más pequeñas, ésto típicamente no es necesario.

Es posible balancear la carga de una unstalación Moodle, por ejemplo, al usar más de un servidor web. Los servidores web separados deberían de consultar la misma BasedeDatos y referirse a la misma área de almacenamiento de archivos, pero en otros aspectos, la separación de las capas de aplicación es lo suficientemente completa para hacer éste tipo de clustering posible. En forma similar, la BasedeDatos podría ser un cluster de servidores (por ejemplo, un cluster' de MySQL), pero ésta no es una tarea sencilla y Usted debería de pedir apoyo de expertos (por ejemplo, de un socio Moodle).

En sistemas muy grandes, conbalanceo de carga, el desempeño de los componentes compartidos se vuelve crítico. Es importante que sus áreas de archivos compartidos estén optimizadas apropiadamente y que Usted use un caché efectivo (Redis está altamente recomendado). debería de considerarse como requisito mínimo el tener una buena comprensión de estas áreas de la administración del sistema.

Cluster de servidores

Discusiones (en inglés) en el foro acerca del uso de Moodle:

Configuración del hardware

Nota: El cambio más rápido y más efectivo que Usted puede hacer para mejorar el desempeño es aumentar la cantidad de RAM en su servidor web - obtenga tanta RAM como le sea posible (por ejemplo, 4GB o más). Al aumentar la memoria primaria se reducirá la necesidad para que el procesador intercambie a disco y le permitirá a su servidor manejar a más usuarios.

  • Se obtiene mejor desempeño al obtener la mejor capacidad de procesador que pueda; por ejemplo, procesador dual o dual core. Un BIOS moderno debería de permitirle habilitar hyperthreading, pero revise si es que ésto hace alguna diferencia sobre el desempeño general de los procesadores al usar una herramienta para medir la potencia del CPU.
  • Si los puede pagar, use discos duros SCSI en lugar de los SATA. Los discos SATA aumentarán la utilización del CPU, mientras que los discos SCSI tienen su propio precesador integrado y se manejan solos cuando tenga discos múltiples. Si necesariamente debe usar discos SATA drives, revise que su tablero madre (motherboard) y los discos mismos soportan NCQ (Native Command Queuing).
  • Compre discos duros con un tiempo de búsqueda bajo (low seek time). Ésto mejorará la velocidad general de su sistema, especialmente al accesar los reportes de Moodle.
  • Elija apropiadamente el tamaño de su archivo de intercambio (swap file). El consejo general es configurarlo a 4 veces el tamaño de su RAM física.
  • Use un sistema de discos RAID. Aunque hay muchas configuraciones de RAID que Usted puede crear, las siguientes generalmente funcionan mejor:
    • instale un controlador RAID basado en hardware (si puede)
    • elsistema operativo y drive para intercambio (swap) en un conjunto de discos configurado como RAID-1.
    • Moodle, el servidor Web y el servidor de la BasedeDatos en otro conjunto de discos configurado como RAID-5.
  • Si su área de 'moodledata' va a estar en un almacenamiento relativamente lento (por ejemplo, NFS montado a un dispositivo NAS Network Area Storage = Almacenamiento en Área en Red) Usted tendrá problemas con el desempeño con la configuración por defecto del caché (que escribe en este almacenamiento. Vea la página sobre Cacheando y use una alternativa. Radis está recomendado. El usar GlusterFS / OCFS2 / GFS2 en un dispositivo SAN y Fiber Channel (canal de fibra) podría mejorar el desempeño (Vea más información en el hilo del foro this forum thread).
  • Use gigabit ethernet para mejorar la latencia y procesamiento. Ésto es especialmente importante cuando tenga a su servidor web y su servidor de BasedeDatos separados en hosts diferentes.
  • Revise las configuraciones de su tarjeta de red. Puede obtener una mejoría en el desempeño al aumentarle el uso de buffers y descriptores para transmitir/*recibir (transmit/receive descriptors) (debe balancear ésto contra el overhead en procesador y memoria) y descargar el cálculo del checksum de TCP a la tarjeta en lugar del Sistema Operativo.
  • Lea ésto Case Study acerca de una prueba de stress en servidor con 300 usuarios.
  • Vea ésto accompanying report acerca del tráfico de red y cargas del servidor.
  • Vea también esta presentación de SFSU en Educause (usando VMWare): [1]

Sistema Operativo

  • Usted puede usar un Sistema Operativo Linux(recomendado), basado-en-Unix, Windows o Mac OS X para el sistema operativo del servidor. Los sistemas operativos *nix generalmente requieren menos memoria que los servidores Mac OS X o Windows para hacer la misma tarea debido a que el servidor está configurado con sólamente una interfase cascarón (shell). Adicionalmente, Linux no tiene cuotas de licenciamiento anexas, pero puede tener una curva de aprendizaje bastante empinada si Usted está acostumbrado a otro sistema operativo. Si Usted tiene un gran número de procesadores corriendo SMP, Usted podría también considerar el usar un Sistema Operativo altamente afinado, como Solaris.
  • Revise su propio Sistema Operativo y las instrucciones específicas del vendedor para los pasos de optimización.
    • Para Linux vea el sitio del Linux Performance Team.
    • Para Linux investigue el comando hdparm, por ejemplo, hdparm -m16 -d1 puede usarse para habilitar lectura/escritura en sectores múltiples y DMA (Direct Memory Access). Monte los discos con las opciones async y noatime.
    • Para Windows configure el servidor a ser optimizado para aplicaciones de red (Control Panel, Network Connections, LAN connection, Properties, File & Printer Sharing for Microsoft Networks, Properties, Optimization). Usted tambiénpuede buscar el Microsoft TechNet site para documentos acerca de optimización.

Desempeño del servidor web

El instalar Firefox y la extensión firebug le permitirá observar el tiempo que toma cada componente de página en cargar. También, la extensión Yslow evaluará su página contra la de Yahoo 14 reglas, texto completo Best Practices for Speeding Up Your Web Site, (video) para sitios web que carguen rápido.

Desempeño de PHP

  • PHP contiene un acelerador incorporado. Asegúrese de que esté habilitado.
  • Se puede mejorar el desempeño en leer/escribir al poner las páginas PHPP cacheadas en un sistema de archivos TMPFS filesystem - pero recuerde que Usted perderá los contenidos de la caché cuando ocurra una falla eléctrica (apagón) o que se reinicie el servidor.
  • El desempeño de PHP es mejor cuando está instalado sobre un módulo de Apache/IIS6 ISAPI (en lugar de un CGI). Los usuarios de IIS 7.0/7.5 (Windows Server 2008/R2) deberían de elegir una instalación FastCGI para el mejor desempeño.
  • También revise el memory_limit en php.ini, En algunos sitios, podría ser necesario que sea más grande, especialmente para algunas operaciones de respaldo.
  • Vea también Configuración de PHP
  • Use PHP-FPM (con apache).

Guías acerca de cómo instalar

APC

eAccelerator

MemCached

Memcached server (daemon)

Memcached PHP 7.1 extension

Desempeño de Apache

  • Si estás usando un servidor Apache en Windows, construyelo desde Apache Lounge el cual está referenciado con mejoras de estabilidad y desempeño comparadas con la descarga oficial de Apache. Es importante notar que esta es un lanzamiento no oficial, por lo que no se mantendrán al día como las versiones oficiales.
  • Define la directiva MaxClients apropiadamente. Utiliza esta formula para ayudarte (que utiliza el 80% de la memoria disponible para dejar espacio para adicional disponible):
MaxClients = Total de memoria disponible * 80% / Uso máximo de memoria por los procesos de Apache
El uso de memoria de los procesos de apache es por lo general de 10MB, sin embargo, Moodle peude fácilmente llegar a los 100MB por proceso, lo que significa que como regla general a primera vista se divide tu memoria disponible en megabytes entre 100 para obtener un ajuste conservador para MaxClients. Es muy probable que tengas que bajar el valor de MaxClients y colocarlo de forma predeterminada en 150 en un servidor Moodle. To get a more accurate estimate read the value from the shell command:
#ps -ylC httpd --sort:rss
Si necesita incrementar el valor de MaxRequestWorkers por encima de 256, también necesitarás ajustar la directiva ServerLimit.
Advertencia: No situé el valor de MaxClients por encima de su memoria disponible o su servidor consumirá más RAM de la disponible para comenzar a usar la memoria compartida swap.
  • Considera reducir el número de modulos que Apache carga en el archivo httpd.conf al mínimo necesario para reducir la memoria consumida.
  • Utiliza la última version de Apache - Apache 2 tiene mejoras en el modelo de consumo de memoria que reduce el consumo de memoria en el futuro.
  • Para sistemas Unix/Linux, considera bajar MaxRequestsPerChild en httpd.conf al valor más bajo entre 20-30 (si ajustas esto a cualquier valor por debajo de la sobre el comienzo de las bifurcaciones comenzarás a obvervar los beneficios).
  • Para servidores cargados de procesos, considera ajustar KeepAlive Off (haz eso solo si tus páginas de Moodle no contienen enlaces a recursos como subir imagenes) bajando KeepAliveTimeout entre 2 y 5. De forma predeterminada es 15 (segundos) - cuanto mayor sea el valor, más procesos del servidor se mantendrán esperando conexiones posiblemente inactivas. Un valor más exacto para KeepAliveTimeout se obtiene al observar cuánto tiempo le toma a los usuarios descargar una página. Después de modificar cualquiera de las variables KeepAlive, monitorea el uso de tu CPU, ya que puede generar una sobrecarga adicional para iniciar más procesos/subprocesos.
  • Como alternativa a usar el valor KeepAlive Off, considera ajustar el Reverse Proxy server enfrente del servidor de Moodle para almacenar en caché los archivos HTML con imágenes. A continuación, puede volver a utilizar Apache keep-alive en el servidor Moodle.
  • Si no está usando un archivo .htaccess, ajuste la variable AllowOverride a AllowOverride None para evitar que busque el archivo .htaccess.
  • Ajuste DirectoryIndex apropiadamente a fin de evitar content-negotiation. He aquí un ejemplo de un servidor de producción:
DirectoryIndex index.php index.html index.htm
  • A menos que esté haciendo trabajos en un servidor de desarrollo, configura ExtendedStatus Off y deshabilite mod_info así como mod_status.
  • Deje HostnameLookups Off (como está predeterminado) para reducir la latencia DNS.
  • Considera reducir el valor de TimeOut a entre 30 y 60 (segundos).
  • Para Options directive, evite Options Multiviews ya que escanea el directorio completo. Para reducir las peticiones de E/S use
Options -Indexes FollowSymLinks
  • La compresión reduce los tiempos de respuesta mediante la reducción del tamaño de la respuesta HTTP
  1. Instale y habilite mod_deflate - consulte la documentación o las páginas de manuales
  1. Agregue este código al archivo de configuración del servidor virtual dentro de la sección <directory> en el directorio raíz (o en el archivo .htaccess si AllowOverrides está en On.):
<ifModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml text/x-js text/javascript text/css application/javascript
</ifmodule>
  • Use Apache event MPM (en lugar del predeterminado Prefork o Worker)

Desempeño de IIS

Todo lo que necesita es alterar esta ubicación en el registro: 

HKLM\SYSTEM\CurrentControlSet\Services\Inetinfo\Parameters\
  • El equivalente a KeepAliveTimeout es ListenBackLog (IIS - la ubicación en el registro es HKLM\ SYSTEM\ CurrentControlSet\ Services\ Inetinfo\ Parameters). Ajusta esto entre 2 y 5.
  • Cambiar el valor de MemCacheSize y ajustarlo a la cantidad de memoria (Mb) que IIS usará para el archivo cache (50% de la memoria disponible por defecto).
  • Cambia el valor de MaxCachedFileSize para ajustar el tamaño máximo de un archivo almacenado en caché en la caché de archivos en bytes. El valor predeterminado es 262,144 (256K).
  • Crea un nuevo DWORD llamado ObjectCacheTTL para cambiar la cantidad de tiempo (en milisegundos) que los objetos de la caché se guardan en la memoria. El valor predeterminado es 30.000 milisegundos (30 segundos).

Desempeño de Lighttpd, NginX y Cherokee

Puedes incrementar el desempeño del servidor usando un servidor web light-weight como lighttpd, nginx o cherokee en combinación con PHP en modo FastCGI-mode. Lighttpd fue creado originalmente como un proof-of-concept[2] para solucionar el problema C10k y principalmente recomendado para servidores con memoria limitada, se desarrollo desde 0 con un modelo asincrono E/S haciendolo más conveniente [3] como alternativa de servidor HTTP para sitios web con alta demanda de aplicaciones, incluyendo Moodle. Vea la página de MoodleDocs Lighttpd para información adicional, configuración y enlaces de ejemplo.

Otras alternativas son lighttpd y nginx tienen la capacidad de crear balances de carga y/o servidor proxy invertido para aliviar la carga en el servidor back-end [4], proporcionando beneficios sin necesidad de un cambio real del software en los servidores existentes.

Ten en cuenta que estos son probablemente los entornos de servidores menos probados, especialmente si estás usando características avanzadas tales como servicios web y/o Redes Moodle. Son probablemente los más recomendados para sitios Moodle muy usados con configuraciones relativamente sencillas.


X-Sendfile

Los módulos de X-Sendfile mejoran el desempeño al enviar archivos grandes desde Moodle. Se recomienda configurar su servidor web y Moodle para que usen esta característica si estuviera disponible.

Configure el servidor web :

Habilite el soporte en config.php (vea config-dist.php): // $CFG->xsendfile = 'X-Sendfile'; // Apache {@see https://tn123.org/mod_xsendfile/} // $CFG->xsendfile = 'X-LIGHTTPD-send-file'; // Lighttpd {@see http://redmine.lighttpd.net/projects/lighttpd/wiki/X-LIGHTTPD-send-file} // $CFG->xsendfile = 'X-Accel-Redirect'; // Nginx {@see http://wiki.nginx.org/XSendfile}

Configure los prefijos de localización de archivos (file location prefixes) si la implementación en su servidor lo requiere: // $CFG->xsendfilealiases = array( // '/dataroot/' => $CFG->dataroot, // '/cachedir/' => '/var/www/moodle/cache', // for custom $CFG->cachedir locations // '/localcachedir/' => '/var/local/cache', // for custom $CFG->localcachedir locations // '/tempdir/' => '/var/www/moodle/temp', // for custom $CFG->tempdir locations // '/filedir' => '/var/www/moodle/filedir', // for custom $CFG->filedir locations // );

Desempeño de Cron

Cron es una parte muy importante del desempeño global de Moodle, porque muchos procesos asincrónicoa son descargados hacia cron, por lo que cron necesita estarse ejecutando y tener suficiente potencia para manejar el trabajo que se le da desde el lado frontal.

Vea Cron_with_Unix_or_Linux#High_performance_cron_tasks

Desempeño de la BasedeDatos

Desempeño de MySQL

Lo más importante que Usted puede hacer para mejorar el desempeño de MySQL es leer, comprender e implementar las recomendaciones en el artículo en idiom ainglés Innodb Buffer Pool article.

El ajuste de buffer pool size puede cambiarse con seguridad mientras su servidor está trabajando, siempre y cuando su servidor tenga suficiente memoria (RAM) para acomodar el valor que le configure. En una máquina dedicada a MySQL, usted puede configurar con seguridad este valor al 80% de la memoria disponible.

Considere ajustar innodb_buffer_pool_instances al número de núcleos de sus procesadores, vCPUs, o chips que tenga disponibles. Ajuste este valor de acuerdo con las recomendaciones en idioma inglés en MySQL documentation.

Los siguientes son ajustes específicos para MySQL, que se pueden configurar para un mejor rendimiento en su my.cnf (my.ini en Windows). El archivo contiene una lista de parámetros y sus valores. Para ver los valores actuales de uso de estos comandos 

SHOW STATUS;
SHOW VARIABLES;

Importante: Debes hacer copias de seguridad de su base de datos antes de intentar cambiar cualquier configuración del servidor MySQL. Después de cualquier cambio en el my.cnf, reinicie mysqld. Si puede hacerlo, la herramienta de MySQLTuner puede correrse contra su servidor MySQL y calculará valores de configuración apropiados para la mayoría de las configuraciones siguientes, basándose en su carga actual, estatus y varibles de forma automática.

  • Habilite la query cache con
query_cache_type = 1.

Para la mayoría de las instalaciones de Moodle, configure lo siguiente: 

query_cache_size = 36M 
query_cache_min_res_unit = 2K.

La 'query cache' mejorará su desempeño si Usted está haciendo pocas actualizaciones en la BasedeDatos.

  • Configure la table cache correctamente. Para Moodle 1.6 configure
table_cache = 256 #(table_open_cache in MySQL > 5.1.2)

(min), y para Moodle 1.7 configure 

table_cache = 512 #(table_open_cache en MySQL > 5.1.2)

(min). La caché de la tabla es usada por todos los hilos (threads) o conexiones, por lo que debe monitorear el valor de opened_tables para continuar ajustándolo - si opened_tables fuera > 3 * table_cache(table_open_cache in MySQL > 5.1.2) , entonces incremente table_cache hasta llegar al límite de su Sistema Operativo. También tome nota de que los números para table_cache también cambiarán dependiendo del número de módulos y plugins que Usted tenga instalados. Encuentre el número apropiado para su servidor al ejecutar la instrucción MYSQL inferior. Observe el número que produce y configure table_cache a este valor. 

mysql>SELECT COUNT(table_name) DE information_schema.tables EN DONDE table_schema='nombredesuBDdeMoodle';
  • Configure el thread cache correctamente. Ajuste el valor de forma tal que su utilización del caché de hilos (thread cache utilization) esté lo más cercanamente posible al 100% por esta fórmula:
thread cache utilization (%) = (threads_created / conexiones) * 100
  • El key buffer puede mejorar la velocidad de acceso a las solicitudes SELECT de Moodle (Moodle's SELECT queries). El tamaño correcto depende del tamaño de los archivos índice (index files) (.myi) y en el caso de Moodle 1.6 o posteriores (sin algún módulo ni plugin adicionales), la recomendación para este valor es key_buffer_size = 32M. Idealmente, Usted quisiera que la BasedeDatos estuviera leyendo desde el disco una vez por cada 100 solicitudes, por lo que Usted debe monitorear que el valor sea el adecuado para su instalación al ajustar el valor de key_buffer_size de forma tal que las siguientes fórmulas sean verdaderas:
key_read / key_read_requests < 0.01
key_write / key_write_requests <= 1.0
  • Configure el número máximo de conexiones (maximum number of connections), de forma tal que sus usuarios no vean un mensaje de "Demasiadas conexiones" (Too many connections). Tenga cuidado, pues esto puede tener impacto en la memoria total utilizada. Las conexiones de MySQL usualmente duran por milisegundos, por lo que no es raro que aun en un servidor con carga fuerte que este valor esté por arriba de 200.
  • Gestione actividad en picos altos (high burst activity). Si su instalación de Moodle usa muchos exámenes (cuestionarios) y Usted está experimentando problemas de desempeño (revise al monitorear el valor de threads_connected - que no debería de estar elevándose) considere incrementar el valor para back_log.
  • Optimize sus tablas semanalmente y después de cada actualización de Moodle. Es una buena práctica el optimizar también sus tablas después de realizar un ejercicio de eliminación de muchos datos; por ejemplo, al final del semestre o año académico. Esto asegurará que los archivos de índices estén actualizados. Respalde primero su BasedeDatos y después use:
mysql>CHECK TABLE mdl_tablename;
mysql>OPTIMIZE TABLE mdl_tablename;
Las tablas comunes a revisar son mdl_course_sections, mdl_forum_posts, mdl_log y mdl_sessions (si está usando dbsessions). Cualquier error necesitará ser reparado usando REPAIR TABLE (vea el manual de MySQL y este forum script).
  • Mantenga la distribución clave (Maintain the key distribution). Cada mes aproximadamente, es una buena idea el detener el servidor mysql y correr estos comandos myisamchk (commands).
#myisamchk -a -S /pathtomysql/data/moodledir/*.MYI
Advertencia: Usted debe de tener el proceso de la BasedeDatos mysql (mysqld) antes de correr cualquier comando myisamchk. Si no lo hace, corre el riesgo de perder datos.
  • Reduzca el número de tablas temporales guardadas en disco (temporary tables saved to disk). Revise esto mediante el valor de created_tmp_disk_tables. Si éste fuera relativamente grande, (>5%) aumente entonces tmp_table_size hasta que Usted vea una reducción. Tome nota de que esto tendrá un impacto en la utilización de RAM.

Desempeño de PostgreSQL

La Open University usa PostgreSQL porque es la mejor BasedeDatos. Hay algunos buenos artículos acerca de como optimizar PostgreSQL (como éste) , y para el caso de Moodle no parece ser diferente respecto al caso general.

Lo primero que debemos reconocer es si realmente tienes que preocuparte sobre el ajuste que usted debe utilizar en un equipo diferente para el servidor de base de datos. Si no estás utilizando un equipo diferente entonces las respuestas a muchas preguntas de desempeño se enturbian sustancialmente respecto a los requisitos de memoria del resto de la aplicación .

Deberías habilitar autovacuum, a menos que sepas lo que está haciendo . Muchos sitios de e-learning tienen períodos previsibles de bajo consumo, por lo que autovacuum deshabilitado en esos momentos puede ser una buena opción. O tal vez dejar autovacuum en funcionamiento pero deshabilitarlo en períodos de carga baja.

Se recomienda ajustar shared_buffers. Para las versiones hasta 8.1 mi prueba ha demostrado que el rendimiento máximo se obtiene casi siempre con buffers < 10.000 , así que si estás usando tal versión , y tienes más de 512 Mb de memoria RAM establece shared_buffers en 10.000 ( 8MB) .

La gestión de memoria intermedia tuvo una gran revisión en 8.2 y "se recomienda" que se ajuste a un número mucho más grande. No he llevado a cabo pruebas de rendimiento con 8,2 , pero las recomendaciones de otras personas son por lo general que ahora debe escalar shared_buffers mucho más con la memoria y seguir disfrutando de los beneficios anteriores, incluso hasta valores como 100.000 ( 80 MB ). Considera el uso de un 1-2% de la memoria RAM del sistema .

PostgreSQL también sederá el control al sistema operativo el almacenamiento en caché de sus archivos , por lo que establecer ' effective_cache_size ' a un valor razonable es también una buena idea. Un valor razonable será normalmente (RAM total - RAM ocupada por programas ) . Si está ejecutando Linux y dejas el sistema en funcionamiento durante un día o dos se puede ver en "libre" y en la columna ' caché ' podrás ver el valor actual. Considera poner este número (que es kB ) y dividiéndolo por 10 (es decir, dejar un 20% para otras necesidades caché programas y luego dividir por 8 para obtener páginas) . Si no estás utilizando un servidor de base de datos dedicado tendrás que disminuir ese valor y tener en cuenta el uso de RAM por otros programas.

Algunos otros parámetros útiles que pueden tener efectos positivos y valores que normalmente les serviría a una máquina con 4GB de RAM, son: . 

work_mem = 10240

Alrededor de 10M de RAM para usar en lugar de la clasificación en el disco y así sucesivamente. Que puede dar un gran aumento de velocidad, pero es por conexión y 200 conexiones * 10M es 2G, por lo que teóricamente puede dejar libre una gran cantidad de RAM. 

maintenance_work_mem = 163840

Es 160M de memoria RAM que se utiliza (por ejemplo) VACUUM, reconstrucción de índices, agrupación, etc. Esto sólo se debe utilizar periódicamente y debe ser liberado con los procesos de salida, así que creo que es bien vale la pena. 

max_fsm_pages = 100000
max_fsm_relations = 5000

Estos se usan para mantener el mapa de espacio libre (free-space map´´), y si fueran muy pequeños Usted vería una degradación del desempeño después de que la BasedeDatos haya estando operando por cierto tiempo. Los números exactos a configurar pueden vislumbrase por la salida de VACUUM VERBOSE, que imprime las páginas FSM requeridas al final de su corrida. El aumento por 5x al parecer es útil para una instalación Moodle, por experiencia. 

wal_buffers = 64

Estos buffers se usan para la bitácora de anticipar-escritura (write-ahead log), y ha habido varios reportes en las listas de correos de PostgreSQL sobre mejoras por este nivel de aumento.

Existe una versión levemente antigua (versión 8.0) pero que todavía vale la pena de leer: http://www.powerpostgresql.com/Docs

Y hay muchas cosas buenas también aquí: http://www.varlena.com/GeneralBits/Tidbits/index.php

Based on Andrew McMillan's post at Tuning PostgreSQL forum thread.

  • El dividir mdl_log en varias tablas y usar VIEW con UNION para leerlas como una. (Vea lo escrito por Tim Hunt su explicación en los Moodle forums)

Enlaces acerca de desempeño de otras BasesdeDatos

Arguments in favour of PostgreSQL] and how to migrate from MySQL to PostgreSQL (forum discussion).

Desempeño de diferente módulos de Moodle

Moodle's activity modules, filters, and other plugins can be activated/deactivated. If necessary, you may wish to deactivate some features (such as chat) if not required - but this isn't necessary. Some notes on the performance of certain modules:

  • Se dice que el Módulo de chat es un cerdo glotón, acaparador en términos de solicitudes HTTP frecuentes al servidor principal. Esto puede reducirse al configurar el módulo para que use actualizaciones Streamed ,o, si Usted estuviera usando un servidor web basado en Unix, al correr el chat en modo de demonio (daemon mode). Al usar el módulo de chat, use las configuracionespara optimizar su carga esperada. Ponga particular atención a los parámetros de chat_old_ping y chat_refresh, dado que estos pueden tener un impacto mayor sobre la carga del servidor.
  • La tarea Cron de Moodle es disparada al llamar al script cron.php. Si esto se llama desde HTTP (por ejemplo, al usar wget o curl) se puede emplear mucha memoria en instalaciones grandes. Se puede mejorar mucho la eficiencia si se llama invocando directamente el comando PHP (por ejemplo, php -f /ruta/al/directorio/moodle/admin/cron.php).
  • El Bloque de actividad reciente consume muchos recursos si Usted tiene un grán número de registros mdl_log. esto está siendo probado, para optimizar las solicitudes SQL.
  • El Módulo de examen (cuestionario), (en inglés Quiz) es conocido que esfuerza el desempeño de la BasedeDatos. Sin embargo, ha ido mejorando en versiones recientes de Moodle, y no sabemos de ningunas buenas mediciones sobre desempeño actualizadas. (Aquí hay un estudio de caso del 2007 con 300 usuarios de exámenes.). Las siguientes sugerencias fueron descritas por Al Rachels en este hilo del foro:
    • asegúrese de que ambos Moodle y el Sistema Operativo, estén instalados en un disco de estado sólido
    • actualice a y use PHP 7
    • ejecute MySQLTunere implemente sus recomendaciones

Vea Configuraciones para desempeño para más información sobre configuraciones relacionadas con desempeño.

Vea también

Ha habido muchas discusiones en moodle.org acerca del desempeño, aquí están algunas de las más interesantes y (potencialmente) más útiles:

Documentación antigua

Optimización de imágenes en Moodle

Las imágenes de base incluidas en el paquete de la distribución de Moodle original proporcionan gráficas no-optimizadas, la mayoría de las cuales pueden beneficiarse de una recompresión sin pérdida utilizando optipng para PNGs, gifsicle para GIFs y jpegoptim para JPGs. Las gráficas optimizadas se transfieren más rápido y proporcionan una respuesta percibida por el cliente más veloz [5], especialmente en estudiantes a distancia. El ejemplo siguiente optimizará en forma recursiva (sin pérdida alguna de calidad) todos los archivos de gráficas y de imágenes incluídos en el directorio de instalación de MOODLE base en un servidor que tenga los comandos de arriba instalados y disponibles. 

find /example/directory/moodle-1.9 -iname *.png -exec optipng -o7 {} \;
find /example/directory/moodle-1.9 -iname *.gif -exec gifsicle -O2 -b {} \;
find /example/directory/moodle-1.9 -iname *.jpg -exec jpegoptim -p {} \;

Tanto optipng como gifsicle están incluidos en los repositorios base de las distribuciones Linux más recientes; jpegoptim debe descargarse e instalarse manualmente.

Consejo acerca de desempeño para Moodle 2.4 con servidores web con balance de carga

Consejo sobre desempeño: Si Usted está corriendo Moodle 2.4 en servidores web con balance de carga, no use la configuraciónpor por defecto del caché que almacena datos en moodledata en un disco compartido en red. En su lugar use memcache. Vea el artículo de Tim Hunt's en http://planet.moodle.org/ de fecha 02 Mayo 2013.

Consejo de una publicación de 2013 en foro

El instalar y ejecutar MySQLTuner da muchos consejos acerca de cómo optimizar el uso de memoria asignada a la BasedeDatos MySQL. La configuración por defecto no hace uso de mucha de la memoria disponible, por lo que el correr MySQLTuner y después ajustar apropiadamente el archivo my.cnf repetidamente, con el tiempo rendirá muchos mejores resultados y completa estabilidad.

Se obtienen mayores mejoras en velocidad al instalar y afinar el APC (Alternative PHP Cache) o Caché alterno de PHP. Esto ha funcionado en un sitio con un único servidor virtualizado, con 2000 usuarios, llegando a tiempos de carga de página menores a un segundo.

Véase también

Obtenido de «https://docs.moodle.org/all/es/index.php?title=Recomendaciones_sobre_desempeño&oldid=55918»
Powered by MediaWiki