Ejecutable por cada cliente o uno solo compartido

[roman]

En mi experiencia, el ubicar el ejecutable en una locación central hace muy lenta la operación. Yo pensaría más por el lado de agregar al software un módulo de actualización automática que detecte cuando hay nuevas versiones, las descargue y las instale. Se ha habaldo de esto anteriormente en los foros.

En su defecto, mientras implementas la actualización, pones una dirección web de dónde descargar las actualizaciones y avisas a todos por mail/teléfono cuando haya una. Yo hago algo similar en un sistema y lo que se descarga es un instalador hecho con InnoSetup para que el usuario no tenga problemas en cómo instalar.

// Saludos

[MartinS]

Gracias román por responder. Igualmente el sistema esta en un red local y mas de ahí no va a pasar el tema es que hay 12 PC's que usan la aplicación por lo tanto 12 copias del ejecutable. Creo que mucho no se va a actualizar, tal vez ahora porque lo implemente la semana pasada y algunas correcciones surgieron. Si sugeris que siga así, así va a ser. Todo sea porque no se me venga abajo el rendimiento.

Gracias y saludos

[[newtron]]

Hola.

Ciertamente el tirar del ejecutable en el servidor se nota al ejecutar el programa pero una vez cargado en memoria no debe de haber muchas diferencias entre usarlo en modo local o desde el servidor y para mi es bastante más cómodo mantener un ejecutable del servidor que no andar actualizando cada uno de los clientes.

Un ejecutable de 6 megas lo debe de leer facilmente desde la red pero no te costará mucho probar las dos opciones y escoger la que más te convenga.

Saludos

[Casimiro Noteví]

Es que todo esto realmente es mucho más amplio de lo que aparenta. En principio, un servidor de bases de datos debe ser sólo eso, un servidor de bases de datos, los demás equipos no deben tener acceso a nada del servidor, sólo hacer una petición por un puerto al mismo y esperar a que te conteste por el mismo puerto. Todo lo demás es sobrecargarlo con cosas que no son necesarias.
En todo caso para esa tarea se debería usar un servidor de aplicaciones, que para eso están.
Además que con más usuarios conectados... más sobrecarga y más lento se va a convertir ese servidor, y si además añadimos directorios compartidos, servidor de impresión, etc. entonces el servidor se va a arrastrar de lento.
Entiendo que una pequeña oficina con 4 ó 5 equipos puede aprovechar un servidor para ese tema (aunque los precios hoy en día permite poner un servidor dedicado bastante económico), pero si ya son más de 10 equipos, la cosa empieza a cambiar, para empezar, que yo sepa, un windows "normal" no admite más de 10 conexiones de usuarios, y aquí se está hablando de 12, así que a pagar más licencias o poner una versión del windows que permita más.
Y si hablamos de memoria ram, 12 usuarios conectados también se lleva una buena cantidad, porque estamos hablando de "sesiones abiertas" en el servidor, no de simples conexiones para hacer/recibir peticiones por un puerto.
En fin, que son muchos detalles los que hay que tener en cuenta, y para ello hace falta conocer bien el caso, estudiarlo y llegar a una conclusión.
Todo lo que se ha comentado aquí es algo muy "genérico", ya que no conocemos los detalles concretos de esta oficina/empresa.

[MartinS]

Hola: En principio estaba implementado para algunas PC's y se fueron sumando de a poco. También debo reconocer que estoy recién empezando con esto de los sistemas administrativos cliente/servidor, de tal manera que en ningún momento me puse a pensar en un servidor dedicado ni nada por el estilo. Esta organización para la cual trabajo tiene varias secciones y a medida que se iba realizando las pruebas iba creciendo el numero de usuarios que querían participar lo que conllevo a ir "emparchando" el programa ya que había mas cosas que no estaban analizadas desde un principio (y ahí empezaron los problemas).
En definitiva hoy esta funcionando de acuerdo a lo esperado y lo único que hay como "servidor" es una pc nueva con bastante capacidad para lo que se necesita, pero nada raro (2 gb de ram, un disco de 500 gb y win 7 ultimate) donde se aloja la base de datos firebird de 2.9 gb. Lo graciosos es que también esa trabaja como cliente. (Somos una organización mediana, pero sin recursos... Argentina ).-
Como verán, eso de emparchar el programa es lo que me lleva a realizar las correcciones que hablaba en un principio y debo andar con un pen con el ejecutable actualizando a cada cliente. Igual estoy conforme con el desempeño del programa porque hace precisamente una semana había un par de cabos sueltos y a partir de ayer comenzaron a cerrar el circuito.- (La famosa luz al fondo del tunel).
Ahora veré como se sigue desempeñando el sistema y en el caso que explote volveré

Gracias a todos.

PD. (asi por lo bajo... ni se imaginan como son las conexiones, cables, switch y demas (hasta hub`s tengo y ni se de que epoca son ) asi que mucho mas no puedo pedir )

Saludos.-

[cloayza]

Sobre el tema hay varias alternativas, pero les contaré mi experiencia.

Tenemos desarrollado un software de simulación para plantaciones forestales que usan diariamente las principales empresas forestales de mi país. En las versiones anteriores (monousuario), cada persona que requeria usar el software se le enviaba un instalador y el software tenía un módulo de actualización en línea, que te indicaba que existia una nueva versión y le sugería actualizar.

El problema era que ningún usuario realizaba la actualización, motivo por el cuál muchas versiones estaban distribuidas en las compañías.

Se tomo la desición de cambiar a una arquitectura multu-usuario, todo centralizado en un servidor en cada compañía. Los usuarios acceden al software a través de un recurso compartido así evitamos tener el problema de muchas versiones dando vueltas.

Lo de la carga del software a traves de la red, es un problema menor (12MB app). Y todo funcionando Ok.

Cantidad de usuarios por compañía promedio al mes de julio (23), funcionando a full.

Empezado por MartinS

(La famosa luz al fondo del tunel).

Alejate de la luz...

[roman]

Bueno, yo creo que lo de la desincronización de las versiones se arregla metiendo el módulo de actualización automática en el que no se le de opción al usuario. Es un añadido en el que se tiene que trabajar una vez y ya luego te olvidas y te evitas la sobrecrga del servidor.

Es hasta verdad hasta cierto punto lo que comenta Newtron, pero muchas conexiones a una pequeña máquina (y la descrita es algo pequeña) sí pueden ser una carga fuerte.

// Saludos

[[newtron]]

Empezado por Casimiro Notevi

En todo caso para esa tarea se debería usar un servidor de aplicaciones, que para eso están.

¿Te importaría contarme cómo va el tema ese del servidor de aplicaciones?. Nunca he hecho una instalación con dos servidores, uno para datos y otro para aplicaciones.

Gracias y un saludo

[Casimiro Noteví]

Normalmente se habla de un servidor de aplicaciones en entornos web y se usa para centralizar y tener más control sobre los distintos servicios/dispositivos/fuentes con lo que se trabaja y no tener desperdigados y repetidos distintos sistemas/controles/aplicaciones por la red.
Aunque te recomiendo que leas la entrada en wikipedia para realmente saber con más seguridad lo que es y de qué trata
En mi experiencia hemos usado algunas veces un servidor de aplicaciones para hacer algo similar a lo propuesto antes, los usuarios conectan a un servidor (de aplicaciones) donde está el software que usan habitualmente, por lo que ellos (los usuarios) no tienen esos programas en sus equipos.
Y es el servidor de aplicaciones el que conecta al servidor de BD.
Imagina que los usuarios conectan todos mediante un programa de control remoto al servidor de aplicaciones, allí se identifican y ya pueden ejecutar los programas que están en ese servidor.
Entre otros motivos también es para tener un lugar "controlable" y "centralizado" para todos los usuarios, ya sean 'internos o externos'.
Diría que es como la programación por capas, pero llevado al aspecto físico, separar la BD de la lógica de negocio, cada uno en un servidor distinto.
Puede ser algo similar al cliente/servidor de toda la vida (de antes), terminales 'tontos' conectados a un servidor unix (donde estaba el programa) que conectaba a su web al servidor (miniordenador* o mainframe) donde estaban los datos.

* miniordenador, antes era un gran ordenador, que se llamaba 'mini' porque era más pequeño que el mainframe

Empezado por wikipedia

Las minicomputadoras son una clase de computadoras multiusuario, que se encuentran en el rango intermedio del espectro computacional; es decir entre los grandes sistemas multiusuario (mainframes), y los más pequeños sistemas monousuarios (microcomputadoras, computadoras personales, o PC, etc.).

[[newtron]]

Ok. Hasta ahí llego pero me surge una cuestión. Si tienes la base de datos en un servidor y el programa en otro tendrás que compartir la carpeta donde se aloje la base de datos para que el servidor donde está la aplicación pueda acceder a ella, ¿no?.