![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
||||
|
||||
|
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
__________________
Be water my friend. |
|
#2
|
||||
|
||||
|
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.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
#3
|
|||
|
|||
|
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.- |
|
#4
|
|||
|
|||
|
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... ![]() ![]() |
|
#5
|
||||
|
||||
|
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 |
|
#6
|
||||
|
||||
|
Me llamó la atención que tratándose de "una empresa sin recursos" (sic) tengan instalado el "Windows 7 Ultimate" je je.
__________________
Lazarus Codetyphon : Desarrollo de aplicaciones Object Pascal, libre y multiplataforma. |
|
#7
|
||||
|
||||
|
Es que antes de instalarlo eran una empresa con recursos
![]() // Saludos |
|
#8
|
||||
|
||||
|
Cita:
Gracias y un saludo
__________________
Be water my friend. |
|
#9
|
||||
|
||||
|
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 ![]() Cita:
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
#10
|
||||
|
||||
|
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?.
__________________
Be water my friend. |
|
#11
|
||||
|
||||
|
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.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
#12
|
||||
|
||||
|
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 |
|
#13
|
||||
|
||||
|
Ok.
Me ha costado (estoy algo espeso) pero creo que he pillado el concepto, aunque instales el programa en otro servidor la ip para conectarse a la base de datos tiene que ser la del equipo que alberga la misma, ¿correcto?. Saludos
__________________
Be water my friend. |
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Como hacer un ejecutable unico para cada ordenador? | negrokau | Varios | 1 | 14-10-2011 15:21:39 |
| solo copio el ejecutable? | Patricio | Varios | 3 | 17-05-2008 00:00:44 |
| Usar un TDataModule compartido entre un ejecutable y una dll | Luzma | Conexión con bases de datos | 1 | 18-07-2007 02:37:25 |
| Seleccionar impresora predeterminada en cada cliente | david duarte | Impresión | 6 | 26-04-2006 17:04:24 |
| mostrar SOLO cliente de los que tengo un sólo registro | Giniromero | SQL | 15 | 11-06-2004 13:33:19 |
|