Ejecutable por cada cliente o uno solo compartido
 

Hola gente, recurro a ustedes que deben tener mucha mas experiencia en sistemas de bases de datos cliente/servidor que yo. Necesito que me orienten sobre la ejecucion y ubicacion del archivo ejecutable de mi aplicacion delphi XE.
El hecho es que el ejecutable pesa alrededor de 6 mb y actualmente cada nodo o cliente que opera en el sistema tiene una copia de este
Ahora la pregunta:

¿Esta bien que ponga un ejecutable (copia) por cada pc que ingrese a operar el sistema o bien debo hacer el enlace para que lo ejecute desde la Pc donde se encuentra la base de datos?. ¿es indistinto o va en detrimento de la red?. ¿hago un acceso directo al ejecutable o debo generar una unidad de red?

Para acceder a la base de datos existe un archivo .ini que utiliza cada pc con la ubicación de la base de datos y sus respectivos parámetros (Ubicacion, claves, directorios y demas).-

Esta consulta viene porque si hay que modificar algo obviamente debo actualizar los ejecutables de todos lo clientes en vez de actualizar solo uno y si definitivamente pongo uno solo para todos los clientes no se si se vera afectado el rendimiento general.

Saludos.-

Pd: El sistema operativo donde se aloja la base de datos (Firebird 2.5) es win 7 y los clientes Xp Sp2

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

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

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

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.

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 :o ).-
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é :D

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 :D:D )

Saludos.-

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.

Alejate de la luz...:D:D

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

Me llamó la atención que tratándose de "una empresa sin recursos" (sic) tengan instalado el "Windows 7 Ultimate" je je.

Es que antes de instalarlo eran una empresa con recursos :D

// Saludos

Eso.... cof cof cof!!

¿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

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 :)

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?.

No, para nada, ningún sistema de bases de datos (firebird, postgresql, mysql, etc.) necesitan compartir nada en el servidor.
Las peticiones se hacen por un puerto, y se recogen los datos por ese mismo puerto. No hay más.
Los clientes/usuarios no tienen que saber siquiera dónde está la BD, ni siquiera necesitan saber en qué ordenador, normalmente se usa un "alias" y en ese alias se guarda la ruta a la BD.
Los servidores (linux, en mi caso) tienen instalado firebird y no tiene nada compartido, absolutamente nada. Es el servicio/demonio firebird el que "escucha" por el puerto 3050 esperando peticiones y responde por el mismo puerto.

Edito: y el sistema de bases de datos que tú usas también hace eso, seguro.

Pero yo no entiendo como funciona esto de un servidor de aplicaciones en entornos web. ¿Cómo se ejecuta una aplicación delphi desde un entorno web?

// Saludos

Supongo que en casos como delphi se ejecutarán mediante aplicaciones cgi.
Aunque el servidor de aplicaciones, "formalmente", se le llama a un servidor web. No conozco bien la denominación, pero supongo que en un modelo MVC (modelo, vista, controlador), el servidor de aplicaciones será el 'controlador', y el servidor web, propiamente dicho, será el 'vista'.

De todas formas no me hagan mucho caso, no estoy informado sobre estos asuntos, y lo que yo llamo un servidor de aplicaciones es lo que he comentado antes, un equipo a donde se conectan los demás usuarios, y que hace de servidor de los programas que usan en la red. En lugar de tener el programa en cada uno de los equipos clientes.

Por lo que alcanzo a ver en el artículo, creo que el término se usa más en relación a Java, y claro, ahí tiene más sentido hablar de acceso por web. En el caso que inició este hilo me parece que hablamos más bien de una red local de windows con una aplicación instalada en una pc central a la que se accede mediante una carpeta compartida.

// Saludos

Si Román, es así, aunque también como dice Casimiro solo comparto la carpeta en la que se encuentra el ejecutable en tanto en la carpeta donde se encuentra la base de datos lo hace a través del 3050 (no se comparte por lo menos "visualmente").-

Saludos

Pues sí, realmente no tiene mucho que ver una cosa con otra.