Tenemos la mejor solución que hallamos on line. Nosotros esperamos que te resulte de utilidad y si puedes aportar algo que nos pueda ayudar a mejorar hazlo con libertad.

Solución:

Gran pregunta. Al abrir esta lata de gusanos, me gustaría exponer la premisa si no le importa 🙂 solo para saber si estamos resolviendo el rendimiento en el cuadrante correcto. ¿Qué motiva exactamente tu pregunta?

easy problem         ^         hard problem
easy solution        |        easy solution
                     |                     
[start here]         |   [graduate to here]
                     |                     
<--------------------+-------------------->
                     |                     
[dragons be here]    |    [data scientists]
                     |                     
easy problem         |         hard problem
hard solution        |        hard solution

Definitivamente el rendimiento es importante, pero la plataforma Force.com es bastante buena para mantenerlo dentro de límites razonables. No tienes que preocuparte por nginx vs iis vs apache servicio XYZ solicitudes por segundo. Flota por encima de esas cosas. Salesforce ofrece inteligencia y hardware a esos problemas para que nosotros no tengamos que hacerlo.

Como desarrollador de la capa de servicios, errar por el lado de inspeccionar:

rendimiento de llamadas (servicios web, ganchos de terceros que cuelgan de sus controladores o cosas locas que viven en código JavaScript frente a sus usuarios a través de botones personalizados, etc.)
Si es un ISV que está desarrollando un producto real, mantenga franjas de DML fuera de las pruebas por su paciencia / cordura, verifique que las inserciones grandes y las eliminaciones grandes no estén cerca de los límites del gobernador,
verifique su uso de herramientas asincrónicas / métodos de establecer y olvidar (como @future, lotes, horarios) para desviar cualquier trabajo pesado de los contextos de ejecución invocados por las interfaces de usuario,

En lugar de hacer un trabajo preliminar por el bien del tiempo de ejecución de Apex, optimice para usted el arquitecto, nosotros los desarrolladores, ellos los futuros mantenedores. El tiempo de ejecución de Apex será más rápido e inteligente, no es necesario que le hagas ningún favor. El principio del menor asombro y la semántica triunfa sobre los trucos cada vez.

Los límites del gobernador son la camisa de fuerza reflexiva y útil que nos da una bofetada suave en la cara como corrección de curso si el código cae fuera de esos límites razonables.

Como desarrollador del lado del cliente, invierta su valioso tiempo:

aprovechando las funciones rápidas (JavaScript Remoting) y reactivas (Streaming API) para ofrecer la agilidad (o la agilidad percibida) que esperan sus usuarios, desacoplada del rendimiento de Apex,
comprobar el expires attributes de páginas que contienen clientes de JavaScript, cache control attributes de static recursos (cremalleras, por supuesto, CSS / JS concatenados cortesía de un script de compilación no exagerado)
perfil primero, dispara después!

La mayoría de las optimizaciones generales no importan, y realmente no debería preocuparse demasiado por el rendimiento, como decía la otra respuesta, pero voy a proporcionar algunas reglas muy específicas que debe seguir independientemente:

Utilice Configuración en lugar de Código, si es posible.

Esto se debe simplemente a que el código usa el tiempo de ejecución y la configuración no (el límite de 10,000 ms). Hay un límite más alto de 10 minutos por transacción que incluye validaciones, etc., pero son mucho más difíciles de alcanzar. Las reglas de validación, las reglas de flujo de trabajo, las reglas de uso compartido y los resúmenes acumulados son elementos estándar que se pueden replicar en Apex Code, pero no deberían ser sin razón.

Utilice mapas en lugar de bucles, si es posible.

Un bucle for dentro de un bucle for usa tiempo de procesamiento multiplicativo (específicamente, tiempo de procesamiento x * y), que es una pérdida de rendimiento importante si no se considera con cuidado. Por ejemplo, si está en un activador de contacto y consulta todas las cuentas y recorre cada cuenta para ver si coincide con el contacto, eso es malo. 200 cuentas y 200 contactos se convierten en 40.000 ciclos de bucle en lugar de 200 ciclos mediante el uso de un mapa. Puede, y probablemente lo hará, el tiempo de espera en transacciones más grandes sin el uso de mapas.

Consultar antes de las ramas, si es posible.

Nunca debes escribir un bucle como este:

for(Account record: [SELECT Id, Name, Date__c FROM Account WHERE Id IN :accountIds]) {
    if(record.Date__c != null) {
        ...

Cuando podría reducir el número de filas consultadas, ciclos de bucle, etc. con esto:

for(Account record: [SELECT Id, Name, Date__c FROM Account WHERE Id IN :accountIds AND Date__c != NULL]) {
    ...

Los beneficios de rendimiento son asombrosos cuando lo haces de esta manera. Además, el tiempo de consulta no se cuenta para el tiempo de ejecución de 10,000 ms.

Consulta solo los campos que necesitas.

Si sabe de antemano qué campos necesita, consulte solo esos. No use listas de campos dinámicos si puede evitarlo, ya que ralentizará el tiempo de consulta y el tiempo de ejecución, aumentará el uso de memoria y, en general, ralentizará las cosas, significativamente. También puede causar errores en situaciones que no ocurrirían sin listas dinámicas.

Nunca consulte dentro de un bucle.

Probablemente leerá sobre esto en otro lugar, por lo que no diré mucho al respecto, pero recuerde que alcanzará sus límites con muchos menos datos si hace esto. Usar mapas correctamente generalmente significa que no lo hará de todos modos, porque lo sabrá mejor.

Aparte de estas simples pautas, la mayoría de las otras optimizaciones son más cosméticas que cualquier mejora importante en el rendimiento, y las irá adquiriendo a medida que avanza.

Formas de agilizar sus consultas:

1) No utilice campos de fórmula en los filtros: se vuelven a calcular al acceder.

2) Si necesita filtrar en un campo de fórmula con frecuencia, SF Support podría indexarlo. Esto solo sería posible para fórmulas “deterministas”, cuyos valores no cambian todo el tiempo dependiendo de la fecha de hoy, por ejemplo, y que no tienen búsquedas entre objetos.

3) No utilice condiciones de exclusión (! =, NOT) o comparación con NULL (! = NULL). Esos hacen que SF Query Optimizer no use índices en campos indexados. En su lugar, intente usar = o IN.

4) Intente usar campos indexados estándar en los filtros, como ID, nombre, createdDate, lastModifiedDate, etc. También intente usar rangos de fechas en los filtros, para reducir el número de registros disponibles.

5) No utilice el comodín% inicial en los criterios LIKE. por ejemplo, LIKE ‘% somestring’. Esto también hará que el optimizador de consultas no use índices en campos indexados.

6) Use “con uso compartido” en las clases donde tenga sentido: esto limitará el número de filas buscadas a las disponibles para el usuario a través de reglas de uso compartido, reduciendo el número total de filas buscadas y reduciendo la longitud de la consulta.

Nos puedes añadir valor a nuestra información cooperando tu experiencia en las ilustraciones.

¡Haz clic para puntuar esta entrada!

(Votos: 2 Promedio: 5)

Tags : Apex / Bestpractice / Performance /

¿Cuáles son las mejores prácticas de rendimiento de Apex?