Hola Amigos, soy de Argentina, les queria consultar porque funciona tan lento las aplicaciones cloud de velneo, mi conexion de internet es muy buena ( 5 mb ) tendre que montarlo en un hosting local? desde ya muchas gracias por su tiempo.
Hola cotillonlourdes, podrías definir Lento ?, algo como una consulta con x registros se esta llevando x tiempo.
Salvo que tengas certeza de que el problema es el ambiente en el que corre el vserver no es mas factible que sea tu proceso, busqueda, función, etc.
Saludos,
Hola cristianvg2003 , la lentitud es general en todos los procesos he probado todas las app y con todas pasa lo mismo , me da la impresion que hay mucho delay entre el lugar donde estoy con el server de España, desde ya gracias por tu atencion
Hola cotillonlourdes, que pena y que raro, hace unos dias un familiar mio desde Buenos Aires no tuvo ningún problema, es decir muy contento en cuanto a rapidez
Por otra parte ¿en donde están ubicados los cluod vserver ? A lo mejor no están en España
Los servidores cloud, en principio estan o en Irlanda o en Estados Unidos, depiende de la configuración elegida por velneo en Amazon.
Con respecto a la lentitud de las aplicaciones, salvo que exista algo raro con tu conexión, normalmente se debe a que las aplicaciones no están del todo optimizadas para trabajar en la nube. Yo de inicio trabajava con el vserver en local, y dejé de hacerlo, cuando ya tenia casi terminada una aplicación, la probé en cloud y iba lentissimo. Ahora desarrollo siempre en cloud, así estoy seguro de que la programación que haga está siempre optimizada para cloud.
Y sin ferir susceptibilidades te puedo decir que muchas openapps, no están optimizadas para la nube, desarrollar en la nube implica tener mucho cuidado a la hora de programar, para que cada proceso y/o función esté al máximo optimizado.
+1 filipe y si la latencia se siente y mas en tu caso cuando estas tan alejado, alguna vez hice la prueba para ver que tanto me afectaba la latencia (yo estando en Colombia) entre los servidore de Velneo (irlanda) y una Amazon EC2 en la region del este, y la diferencia es abismal literalmente el doble de rápido en algunos casos hasta mas, en tu caso si se usa Amazon lo ideal sería que tu vServer estuviera en los datacenters de Sao Paulo.
un Saludo,
Gracias a todos por sus respuestas, de a poco voy aclarando el panorama, ahora sabiendo este problemita pregunto, se puede instalar un vserver en un hosting de Argentina? si se puede, es muy complejo? y que licencia tendria que usar?
@Filippe, Ademas de esto:
http://velneo.es/consejos-programar-aplicaciones-nube/
http://velneo.es/diseno-rejilla-optimizado/
http://velneo.es/ejecucion-de-procesos-en-tercer-plano/
¿hay alguna documentación adicional, con mayor detalle, o tutores de casos mas comunes, donde se pueda ver que mas hacer en vDevelop, para tener una solución optimizada para la nube?
.
Gracias de antemano cualquier tip.
Saludos.
@cjribera.yahoo
Muy honestamente ni siquiera he leído con atención eses articulos.
Relativamente a la optimización, pienso que en este momento, muy poca gente que programa en v7, tiene claro lo que es lento y que no, entre ellos, (seguramente haya más gente) quiero destacar el trabajo de Nacho de Guida21 (http://nachov7.wordpress.com/) y de José Luis de ASCSL (http://www.ascsl.com/).
Si leemos sus articulos vamos descubriendo a poco y poco pequeños detalles en sus ejemplos que realmente hacen la magia en aplicaciones cloud, y hacen que estas literalmente vuelen.
Con mi pequeña experiencia en v7 (realtivamente con otros desarrolladores) te puedo decir el seguiente:
1 - Evita las funciones, si puedes usar un proceso lanzado desde un manejador de objectos, usa el manejador (También te permite enviar parametros).
2- Las tablas en memória son lentas comparadas con v6 (evitar siempre que se pueda). Como ejemplo te digo que en una de las pruebas que hice, en el oninit de un formulario llamava a una función, entre devolver un contenido estático y devolver un dato de una tabla en memória la diferencia es abismal.
3- En la mayoria de los casos ganamos velocidad si las busquedas y/o cargar listas las lanzamos con el manejador de objectos en el servidor (Hay que tener cuidado, para no saturar el servidor con demasiadas tareas, si es solo consulta en principio no hay problema).
4- Evitar al maximo poner en las condiciones de activo y visibilidad de objectos, funciones. Estas condiciones se evaluan varias veces al iniciar el formulario, y siempre que se ejecuta un evento del formulario o que este se refresca.
5- Evitar siempre que posible el uso de variables globales. Con la funcionalidad del manejador de objectos para pasar parametros a busquedas, procesos, etc, ganamos mucha velocidad y no necesitamos para nada de las variables globales. Normalmente solo necesito de dos o tres variables globales por aplicación (EJ: Id de usuario logeado, etc.)
6- En las rejillas por defecto no listar datos, solo cuando se pincha en buscar (personalmente a min no me gusta demasiado, parece que no hay datos, pero siempre podremos cortar la lista para que solo nos devuelve un numero x de resultados, así no quedamos con la sensación de que no existen datos). Esto incrementa mucho la velocidad de la aplicación. Ten en cuenta que se abres un formularios con sub-formularios y cada sub-formulario tiene su rejilla, al abrir el formulario hay que cargar todos las listas de todos los subformularios. (Si no está visible la rejilla, los datos los siguen cargando)
7- Limitar el uso de css. El uso excesivo de css en las aplicaciones, hacen que estas sean más lentas, principalmente si estos datos los recoje de una tabla o usa información de una tabla, dá igual que sea en memória o en disco.
8- Evitar guardar en las tablas imagenes. Yo opté por guardar las imagenes externamente, y genero de forma automatica una miniatura de la imagen de muy reducida dimensión solo para poder presentarlas en las rejillas, en los formularios las visualizo usando html.
9- Cuidado con el tamaño de las imagenes que creamos de manera estática en el vdeveloper, intentar al maximo optimizar su tamaño.
Seguramente hay mucho más truquillos de como optimizar, ahora mismo no se me ocurre ningnuno más.
Seria interesante aprovechar este hilo, para que la gente coloque sus experiencias y agrupar las tecnicas usadas para optimizar para cloud.
Por veces seguir todos estos pasos, haz que la programación se complique un poco, pero te aseguro que los resultados son bien visibles.
Filippe, lo tuyo no tiene precio. Muchas gracias
Por añadir, diría que si no queda otra posibilidad y hay que añadir variables globales, procurar que no sean en disco.
Ralentizan excesivamente cualquier formulario en que se muestre.
Filippe, muchas gracias por tu enseñanza es muy util, te hago una consulta relacionada con este tema, es posible crear un vserver que trabaje en cloud propio ?
@cotillonlourdes@gmail.com
Pues claro que si, basta instalar el server en un servidor dedicado o un virtual en un hosting, y ya lo tienes.
A todos muchas gracias por su ayuda !!!
Hola,
Referente a las búsquedas .
Si la tabla sobre la que vamos a buscar no va a tener más de 10/20.000 registros no se va a notar mucho si no está optimizada. Pero como tenga 100.000 registros o más merece la pena pensar muy bien cómo se crean los índices y cómo se montan los componentes en la búsqueda.
He llegado a dos conclusiones :
- El primer componente de la búsqueda debe de filtrar el mayor número de registros.
- Por cada componente de búsqueda que añadimos sube el tiempo de respuesta. Por lo tanto es preferible utilizar un componente basado en un índice compuesto por dos campos a utilizar dos componentes de búsqueda con dos índices simples.
Un ejemplo :
Tabla de 800.000 registros. Un búsqueda que devuelve unos 70 registros, si se basa en 9 componentes de búsqueda tarda el triple de tiempo que si se basa en 5 componentes (utilizando índices compuestos). Todo esto en un servidor local, no en la nube.
Todos sabemos que búsquedas realizadas en la nube o en servidores remotos se deben lanzar siempre en 3er. plano. Bien pues no sé si se realizan realmente en el servidor porque cuando hay varios miles de registros el tiempo de respuesta no es inmediato, e incluso puede demorarse la respuesta demasiado tiempo. En cambio si la búsqueda la incluimos dentro de un proceso, y este proceso lo lanzamos en 3er. plano si se realiza realmente en el servidor, el tiempo de respuesta es inmediato aunque nos devuelva muchos registros.
Un saludo.
José Luis ha escrito un articulo acerca de este post en su blog. Vale la pena leerlo.
http://www.ascsl.com/2012/06/consejos-para-mejorar-el-desarrollo-en-la-nube/
Gracias de nuevo @Filipe,
Espero que no te haya importado, me parecian buenos consejos y he querido incluir algunos mas y ampliar/detallar mejor como llegar a esos resultados.
Ademas, hay temas en el foro que requieren especial atención, y he considerado oportuno mencionarlo especialmente.
un saludo
José Luis
http://www.ascsl.com
Quisiera, si es posible, se comente esto que dejó Filipe en su tiempo
“1 – Evita las funciones, si puedes usar un proceso lanzado desde un manejador de objectos, usa el manejador (También te permite enviar parametros).”
Si las funciones se ejecutaran siempre en tercer plano, ¿creen que ya se podría usar funciones en la nube sin penalizar severamente el rendimiento?, ¿creen que ese era el origen del problema?
Esta es la idea lanzada al respecto, por favor verla, comentarla, votarla si hace falta.
http://velneo.zendesk.com/entries/22993003-funciones-en-tercer-plano