Hola,
Queria preguntarles si creen que baja mucho el rendimiento de utilizar cargar lista a utilizar búsquedas mediante el manejador de objetos.
Gracias de antemano.
Una respuesta genérica:
Todas las tareas son más rápidas cuando se ejecutan en el servidor.
Con el manejador de objetos puedes ejecutar busquedas, pero tambien puedes ejecutar procesos en 3P
En realidad, para saber si es mejor la búsqueda o Cargar lista, solo hay que hacer muchas pruebas de rendimiento, nada mas.
un saludo
José Luis
http://www.ascsl.com
Depende lo que quieras conseguir. Si quieres cargar toda la lista, mejor cargar lista y te evitas más líneas de programación, si quieres cargar listas con una serie de datos, utiliza las búsquedas.
Un saludo
PD Te has adelantado, Pepeto
Hola:
Tened en cuenta que las búsquedas SIEMPRE se ejecutan en tercer plano (es decir en el sevidor)
Un saludo
¿De dónde sacas que las búsquedas siempre se disparan en el servidor?, eso es si instancias la búsqueda en un objeto y lo disparas en 3er plano, lo mismo que un proceso.
Para saber qué es más rápido se tendrán que hacer pruebas calculando los tiempos de búsqueda para los dos casos.
@sonovision.telecable @ayudavelneo
Sonivision tiene toda la razón, de hecho he hecho unos bencharmks y la diferencia es considerable. Si lanzas la busqueda usando el manejador de objectos en servidor, siempre vá a ser más rapido do que si lanzas la busqueda en 1º plano.
En una de las pruebas que hice la diferencia rondava los 500 milesegundos, esto con una dezena de registros.
me he quedado un poco alucinado cuando afiramas que las búsquedas se ejecutan SIEMPRE EN TERCER PLANO ya que hasta donde he llegado en V7 esto no es así para nada y por tu nick deduzco que eres personal de Velneo, ¿es así?
@ pacomj5.qmal
nosotros hemos hecho estas pruebas más de una vez, siempre en tercer plano y no me preguntes porqué pero las búsquedas se ejecutan mucho más rápido. De hecho, casi en el 100% de nuestra aplicación hemos dejado de usar el cargar lista.
Saludos
Hola
@apinna.winmotor no pertenezco a la plantilla de Velneo. Soy F.Jose Vila y el nick es por un blog que estoy creando que sirva de ayuda a la comunidad velneo.
La búsqueda da igual donde la lances… sigo afirmando que se resuelve en el servidor…
De todas formas lo mejor seria consultarlo con Velneo
Un saludo
Haz un ejemplo y compruebas la diferencia de tiempos, y después nos cuentas el resultado, yo ya lo he hecho.
En mi caso en un solo proceso me he ahorrado casi 1 segundo de diferencia.
En defensa de @ayudaVelneo dire que yo tambien estuve ese dia y escuche tal afirmación.
Sin embargo, prefiero no limitarme a repetir lo que oigo. Es preferible llegar a conclusiones propias despues de realizar las pruebas correspondientes.
un saludo
José Luis
http://www.ascsl.com
Hay varias cuestiones que están en el aire que son interesantes (patrones de desarrollo), todos tenéis razón pero ninguno puede dar la respuesta óptima a estas cuestiones ya que ninguno conoce en detalle como están implementadas.
Creo que hay ciertas cuestiones de funcionamiento de V7 que debiera responder Velneo I+D directamente.
Otra opción es demostrar mediante evidencias el comportamiento de V7 con ejemplos reales (vídeo incluido) y poner en algún blog en limpio todo esto. Tal vez ayudavelneo sea el blog adecuado.
PD: Yo también estaba presente en esa conversación y escuche tal afirmación (en la v1.0 de PaaSOS siempre forzamos las búsquedas en 3plano aún sabiendo que en teoría todas se ejecutan en 3plano lo indiques o no).
Un saludin…
Jorge Hontoria
http://tipesoft.com
Entonces,¿por qué ponen un tutor de búsquedas en tercer plano?, si de todas formas ya se ejecutan en 3er plano.
Refloto el tema porque justo ahora estoy usando búsquedas complejas.
Yo tengo, de tiempo atrás, una respuesta oficial de soporte.
"…las búsquedas siempre se ejecutan en el servidor. Funcionan del siguiente modo:
Petición de datos (cliente) se envía al servidor la petición
Búsqueda (se ejecuta en el servidor)
El servidor debe retornar al cliente los registros encontrados.
Lo mismo es extrapolable a los localizadores.
Lo que más retarda su ejecución no es la ejecución en sí, sino el envío de datos al cliente para mostrarlos en la rejilla. Por tanto, no es necesario que programes nada para disparar la búsqueda en tercer plano."
Por esto mismo, quisiera saber si alguien ha hecho pruebas de rendimiento, para ver si existe alguna diferencia entre usar la búsqueda en forma estándar y la alternativa de usar el manejador de objetos. En teoría no debería haber diferencia, ¿cierto?
Buenos dias:
Creo que se están mezclando dos conceptos:
-
Plano en el que se ejecutan las búsquedas
-
Rendimiento de las búsquedas
A mi me da igual en qué plano se ejecuten, lo que me importa es el rendimiento. Y siendo ese mi interés, es comprobable que cuando una búsqueda es compleja, es decir, cuando tiene varios índices a resolver (cuyas listas se deben combinar), el rendimiento de esa búsqueda lanzada desde primer plano es pobre. Cada una de las subbúsquedas o subíndices puede que se resuelva en tercer plano, no lo discuto, pero la combinación de las listas se hace en primer plano. Imaginaos el tráfico de datos que eso supone…
Si esa misma búsqueda, con los mismos índices, se lanza desde un proceso que ha sido ejecutado en tercer plano usando un manejador al que se le hayan pasado las variables adecuadas (que a su vez pasará a la búsqueda), las listas de las subbúsquedas no tienen que cambiar de plano y el rendimiento MEJORA MUCHO.
Esto es fácil de comprobar haciendo algunas pruebas…
Saludos. Ramiro
Ramiro, estoy contigo.
Yo lanzo las búsquedas desde un manejador de objetos que llama a un proceso 3P que es el que ejecuta la búsqueda. Y efectivamente, los retornos son más eficientes.
de esta forma me aseguro que todo el proceso de búsqueda se ejecuta en el servidor.
Hola.
Hay un artículo en la Base de Conocimiento Técnica (disponible en el Centro de Soporte) que explica con detalle este tema:
http://soporte.velneo.es/entries/21662276-cargar-lista-vs-busquedas-y-busquedas-en-tercer-plano
Para los no suscriptores, en resumen:
En una búsqueda lanzada en 1º plano, sólo el primer componente de la búsqueda se ejecuta en el servidor, el resto se ejecutan en el cliente.
Un cargar lista y una búsqueda equivalente (es decir, con un sólo componente de búsqueda) tienen el mismo rendimiento, y ambas realizan la búsqueda en el servidor, y devuelven la lista de registros al cliente
Para lanzar de forma eficiente búsquedas complejas (con varios componentes de búsqueda), el mejor modo es llamar a la búsqueda desde un proceso que se ejecute en 3º plano. Así, todos los componentes de búsqueda se ejecutan en el servidor.
Lo que hago para ejecutar búsquedas complejas es:
Creo una búsqueda con variables locales, y hago que los componentes de búsqueda dependan de esas variables locales.
Creo un proceso con salida la lista de la búsqueda, con las mismas variables locales, en el que creo un manejador de objeto de la búsqueda, le paso las variables, ejecuto la búsqueda y devuelvo a la salida el resultado de la misma.
Llamo a ese proceso con un manejador, dando valores a sus variables locales, ejecutándolo en 3º plano y tomando su salida como el resultado de la búsqueda.
Si me equivoco en algún punto, no dudéis en decírmelo.
1 me gusta
Lo has explicado perfectamente Fran.
un saludo.
José Luis
Quizá es obvio, pero preferiría una confirmación explicita.
Estas búsquedas llamadas con el manejador de objetos, deben prescindir del formulario asociado, cierto?
Lo otro, ¿que impide que la búsqueda se comporte por defecto en tercer plano y en el servidor, aun si tiene un formulario asociado?, de última, si tan complejo es, que usen internamente un manejador de objetos, pero que esa complejidad esté oculta al desarrollador, manteniendo la filosofía ‘Life is soft’ y ahorrando tiempo en tareas que se hacen siempre, que es lo que se busca.
Y mi punto es que en todo comportamiento estándar, no solo en búsquedas. Lo óptimo deberia ser el default, ocultando al máximo la complejidad, no les parece?
Todo lo explicado anteriormente, es aplicable a búsquedas sin formulario, ya que, cuando la búsqueda tiene formulario, debe ejecutarse en primer plano.
Para búsquedas con formulario, hay que cambiar la forma de realizar la búsqueda pero también se puede hacer:
- Desde el proceso que ejecuta la búsqueda, y le pasa los valores con el manejador de objetos, debemos pedir el formulario, justo antes de lanzar la búsqueda, por ejem. con otro manejador de objetos y pasar los valores del formulario a la búsqueda.
En cuanto a la importancia de simplificar todo eso, entiendo que no debe ser fácil, pero lo importante, es que se puede solucionar, aunque tenga un poco mas de trabajo por nuestra parte. Que realmente tampoco es tanto, porque cuando se tiene un sistema de trabajo depurado, el resto es “Copiar” y “Pegar como” 
un saludo
José Luis
Hay algun ejemplo ya armado, open app, de como hacer esto?
Es decir, que funcione de cara al usuario final IDÉNTICO a la búsqueda estándar con formulario, pero usando internamente el manejador de objetos.
Sería una acción, que dispara un proceso, y dentro del proceso, disparo un formulario donde me pide datos, y estos datos después se pasan a la búsqueda, ¿cierto?
El asunto es en los detalles, que HAYA UN EJEMPLO FUNCIONANDO, para ver si el formulario debe ser sin origen, con que comando llamarlo, si llamarlo desde el proceso o desde la acción, etc. Tal que uno vea ese ejemplo UNA SOLA vez, y no necesite preguntar mas.
¿Existe algún ejemplo así?, si no existe, ¿podrían mostrar la pantalla (o pantallas) necesaria(s)?