17000 conexiones en una hora

Le recomiendo estos artículos:

Stress Testing SQL Server
http://www.sqlservercentral.com/art...eous/2634/

SQL Server Performance Monitoring Guidelines
http://www.windowsitlibrary.com/Con.../15/1.html


También puede usar herramientas especializadas como Benchmark Factory o
Spotlight (ambas en www.quest.com) o SQL Diagnostic Manager (en
www.idera.com).

Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/profile/gux
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.



"" wrote:

Si, eso lo voy a hacer. Lo que no se, es que indicador, de los muchos que
hay, es el que tengo que mirar.
Para las conexiones activas, me imagino que será este: User Connectios
pero ¿para la memoria?

Gracias,

"Gux (MVP)" wrote in message
news:
> En mi humilde opinión deberías planificar una prueba de stress, que simule
> carga de usuarios, para ver cómo responde el servidor o para establecer
> métricas de comportamiento del mismo.
>
> Gustavo Larriera, Microsoft MVP
> https://mvp.support.microsoft.com/profile/gux
> Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
>
>
>
> "" wrote:
>
>> Hola,
>> estoy haciendo un desarrollo sencillo pero que afecta a muchos usuarios y
>> tengo dudas sobre si lo soportar el servidor y como configurarlo.
>> Os cuento,
>> se basa en un programa cliente ( vb 6.0 ) que recoge datos en el inicio
>> de
>> sesin de cada pc de una red de unos 17000 equipos..
>> Lo que hace el programita es muy sencillo, simplemente actualizar unos
>> pequeos datos, ( informacin hw, etc, y poca cosa mas)
>> El problema que veo es que se ejecutarn todos ms o menos al mismo tiempo,
>> es decir, cuando empiecen a trabajar todos los usuarios, entre las 8 y
>> las 9
>> de la maana.
>> Cada ejecucin del cliente, cuando es solo un usuario en la misma red es
>> instantanea, pero los equipos estn disperdigados por toda Espaa. y las
>> comunicaciones no siempre son buenas.
>>
>> Al arrancar el cliente se crea una conexin por ADO a la BBDD, hace alguna
>> consulta sencilla, se desconecta de la BBDD y se cierra. A veces tocar
>> actualizar algn registro, pero simpre es poca cosa.
>>
>> Por todo esto, tengo dudas de como se va comportar el servidor, si va a
>> aguantar todas las conexiones, etc
>> Tampoco se como configurar el servidor sql server 2000, num de
>> conexiones,
>> etc.para este tipo de infraestructura.
>> Qu os parece? aguantar?, cmo debera configurar el servidor ?
>>
>> Tampoco sabra como monitorizar el rendimiento cuando lo ponga en
>> produccin
>> o cuando haga pruebas de rendimiento simulando un montn de conexiones a
>> la
>> vez.
>>
>> El servidor es probable que tenga 4 gb de Ram.
>>
>> Muchas gracias
>>
>> David
>>

Gracias Gux, voy a echarle un vistazo.



"Gux (MVP)" wrote in message
news:

Le recomiendo estos artículos:

Stress Testing SQL Server
http://www.sqlservercentral.com/art...eous/2634/

SQL Server Performance Monitoring Guidelines
http://www.windowsitlibrary.com/Con.../15/1.html


También puede usar herramientas especializadas como Benchmark Factory o
Spotlight (ambas en www.quest.com) o SQL Diagnostic Manager (en
www.idera.com).

Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/profile/gux
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.



"" wrote:

Si, eso lo voy a hacer. Lo que no se, es que indicador, de los muchos que
hay, es el que tengo que mirar.
Para las conexiones activas, me imagino que será este: User Connectios
pero ¿para la memoria?

Gracias,

"Gux (MVP)" wrote in message
news:
> En mi humilde opinión deberías planificar una prueba de stress, que
> simule
> carga de usuarios, para ver cómo responde el servidor o para
> establecer
> métricas de comportamiento del mismo.
>
> Gustavo Larriera, Microsoft MVP
> https://mvp.support.microsoft.com/profile/gux
> Este mensaje se proporciona tal como es, sin garantías de ninguna
> clase.
>
>
>
> "" wrote:
>
>> Hola,
>> estoy haciendo un desarrollo sencillo pero que afecta a muchos
>> usuarios y
>> tengo dudas sobre si lo soportar el servidor y como configurarlo.
>> Os cuento,
>> se basa en un programa cliente ( vb 6.0 ) que recoge datos en el
>> inicio
>> de
>> sesin de cada pc de una red de unos 17000 equipos..
>> Lo que hace el programita es muy sencillo, simplemente actualizar unos
>> pequeos datos, ( informacin hw, etc, y poca cosa mas)
>> El problema que veo es que se ejecutarn todos ms o menos al mismo
>> tiempo,
>> es decir, cuando empiecen a trabajar todos los usuarios, entre las 8 y
>> las 9
>> de la maana.
>> Cada ejecucin del cliente, cuando es solo un usuario en la misma red
>> es
>> instantanea, pero los equipos estn disperdigados por toda Espaa. y las
>> comunicaciones no siempre son buenas.
>>
>> Al arrancar el cliente se crea una conexin por ADO a la BBDD, hace
>> alguna
>> consulta sencilla, se desconecta de la BBDD y se cierra. A veces tocar
>> actualizar algn registro, pero simpre es poca cosa.
>>
>> Por todo esto, tengo dudas de como se va comportar el servidor, si va
>> a
>> aguantar todas las conexiones, etc
>> Tampoco se como configurar el servidor sql server 2000, num de
>> conexiones,
>> etc.para este tipo de infraestructura.
>> Qu os parece? aguantar?, cmo debera configurar el servidor ?
>>
>> Tampoco sabra como monitorizar el rendimiento cuando lo ponga en
>> produccin
>> o cuando haga pruebas de rendimiento simulando un montn de conexiones
>> a
>> la
>> vez.
>>
>> El servidor es probable que tenga 4 gb de Ram.
>>
>> Muchas gracias
>>
>> David
>>

Un problema que veo es que de forma prederminada, después de hacer las
operaciones necesarias y cerrar la conexión, realmente la conexión no se
cierra, sino que se va al pool de conexiones. No se va a cerrar realmente
hasta que no pasen unos minutos sin utilizarse la conexión.

Lo primero que yo haría en ese programa de VB 6.0 es desactivar el
Connection Pooling. La razón es que la conexión no se va a reutilizar una
vez que se cierra, por tanto es un desperdicio de recursos mantenerla en el
pool de conexiones. Para desactivar el connection pooling se pone "OLE DB
Services = -2" en la cadena de conexión ADO.

Por otra parte, estoy de acuerdo con la idea de usar algún tipo de middle
tier como web services. Una aplicación web services sí que haría buen uso
del Connection Pooling haciendo que el número de conexíones fuera más
pequeño que con el programilla VB 6.0 el cual se conecta directamente con
SQL Server.

Otra tecnología que podría usarse en este entorno es MSMQ. En caso de que el
sistema no pueda con la carga de trabajo que se da a las "horas punta", una
solución sería enviar la información a colas de mensajes en varios
servidores, donde se está ejecutando un programa que lee de la cola esos
datos y los envía a SQL Server. Así además se reduce el tiempo de inicio de
sesión de los usuarios. En el inicio de sesión se envia un mensaje a una
cola y punto, no se espera a que ese mensaje se procese y se haga lo que se
tenga que hacer en SQL Server.

Saludos:

Jesús López
www.solidq.com



escribió en el mensaje
news:

Lo que hará es muy simple. Simplemente buscar en una tabla de 17.000
registros bien indexada. Si no lo encuentra se añade y si no lo actualiza.
El problema lo veo, en que si hay conexiones lejanas que tardan más en
hacer el proceso, se vayan quedando conexiones abiertas y poco a poco se
vayan "comiendo" la memoria.




"Maxi" wrote in message
news:#

Hola, es imposible saber si eso funciona sin conocer detalles del
servidor ! El tema es saber que haran esas conexiones y como impacta,
cada conexion consume memoria con lo cual deberias tener un buen numero
ahi, yo trataria de elevarlo a mas de 4GB.

Ahora bien, porque tienes esa arquitectura? no seria mas simple armar un
Web Service y centralizar todo ahi? o un servidor de aplicacion con
Remoting o alguna tecnica de esas?


-
Microsoft M.V.P en SQLServer
SQLTotal Consulting - Servicios en SQLServer
Email:
escribió en el mensaje
news:

Hola,
estoy haciendo un desarrollo sencillo pero que afecta a muchos usuarios
y tengo dudas sobre si lo soportará el servidor y como configurarlo.
Os cuento,
se basa en un programa cliente ( vb 6.0 ) que recoge datos en el inicio
de sesión de cada pc de una red de unos 17000 equipos..
Lo que hace el programita es muy sencillo, simplemente actualizar unos
pequeños datos, ( información hw, etc, y poca cosa mas)
El problema que veo es que se ejecutarán todos más o menos al mismo
tiempo, es decir, cuando empiecen a trabajar todos los usuarios, entre
las 8 y las 9 de la mañana.
Cada ejecución del cliente, cuando es solo un usuario en la misma red es
instantanea, pero los equipos están disperdigados por toda España. y las
comunicaciones no siempre son buenas.

Al arrancar el cliente se crea una conexión por ADO a la BBDD, hace
alguna consulta sencilla, se desconecta de la BBDD y se cierra. A veces
tocará actualizar algún registro, pero simpre es poca cosa.

Por todo esto, tengo dudas de como se va comportar el servidor, si va a
aguantar todas las conexiones, etc
Tampoco se como configurar el servidor sql server 2000, num de
conexiones, etc.para este tipo de infraestructura.
¿Qué os parece? ¿aguantará?, ¿cómo debería configurar el servidor ?

Tampoco sabría como monitorizar el rendimiento cuando lo ponga en
producción o cuando haga pruebas de rendimiento simulando un montón de
conexiones a la vez.

El servidor es probable que tenga 4 gb de Ram.

Muchas gracias

David

Muchas gracias Jesús,
sobre crear un webservices, no tendría problema en crearlo con .Net , pero
el problema es que no se si se puede desde vb 6.0 acceder a un webservice
sin instalar ninguna librería ,ocx, etc.
Una condición que no puedo cambiar es que el cliente tiene que basarse en un
exe ligero y único, sin instalación, ocx, etc.

Un saludo,

David

"Jesús López" wrote in message
news:

Un problema que veo es que de forma prederminada, después de hacer las
operaciones necesarias y cerrar la conexión, realmente la conexión no se
cierra, sino que se va al pool de conexiones. No se va a cerrar realmente
hasta que no pasen unos minutos sin utilizarse la conexión.

Lo primero que yo haría en ese programa de VB 6.0 es desactivar el
Connection Pooling. La razón es que la conexión no se va a reutilizar una
vez que se cierra, por tanto es un desperdicio de recursos mantenerla en
el pool de conexiones. Para desactivar el connection pooling se pone "OLE
DB Services = -2" en la cadena de conexión ADO.

Por otra parte, estoy de acuerdo con la idea de usar algún tipo de middle
tier como web services. Una aplicación web services sí que haría buen uso
del Connection Pooling haciendo que el número de conexíones fuera más
pequeño que con el programilla VB 6.0 el cual se conecta directamente con
SQL Server.

Otra tecnología que podría usarse en este entorno es MSMQ. En caso de que
el sistema no pueda con la carga de trabajo que se da a las "horas punta",
una solución sería enviar la información a colas de mensajes en varios
servidores, donde se está ejecutando un programa que lee de la cola esos
datos y los envía a SQL Server. Así además se reduce el tiempo de inicio
de sesión de los usuarios. En el inicio de sesión se envia un mensaje a
una cola y punto, no se espera a que ese mensaje se procese y se haga lo
que se tenga que hacer en SQL Server.

Saludos:

Jesús López
www.solidq.com



escribió en el mensaje
news:

Lo que hará es muy simple. Simplemente buscar en una tabla de 17.000
registros bien indexada. Si no lo encuentra se añade y si no lo
actualiza.
El problema lo veo, en que si hay conexiones lejanas que tardan más en
hacer el proceso, se vayan quedando conexiones abiertas y poco a poco se
vayan "comiendo" la memoria.




"Maxi" wrote in message
news:#

Hola, es imposible saber si eso funciona sin conocer detalles del
servidor ! El tema es saber que haran esas conexiones y como impacta,
cada conexion consume memoria con lo cual deberias tener un buen numero
ahi, yo trataria de elevarlo a mas de 4GB.

Ahora bien, porque tienes esa arquitectura? no seria mas simple armar un
Web Service y centralizar todo ahi? o un servidor de aplicacion con
Remoting o alguna tecnica de esas?


-
Microsoft M.V.P en SQLServer
SQLTotal Consulting - Servicios en SQLServer
Email:
escribió en el mensaje
news:

Hola,
estoy haciendo un desarrollo sencillo pero que afecta a muchos usuarios
y tengo dudas sobre si lo soportará el servidor y como configurarlo.
Os cuento,
se basa en un programa cliente ( vb 6.0 ) que recoge datos en el inicio
de sesión de cada pc de una red de unos 17000 equipos..
Lo que hace el programita es muy sencillo, simplemente actualizar unos
pequeños datos, ( información hw, etc, y poca cosa mas)
El problema que veo es que se ejecutarán todos más o menos al mismo
tiempo, es decir, cuando empiecen a trabajar todos los usuarios, entre
las 8 y las 9 de la mañana.
Cada ejecución del cliente, cuando es solo un usuario en la misma red
es instantanea, pero los equipos están disperdigados por toda España. y
las comunicaciones no siempre son buenas.

Al arrancar el cliente se crea una conexión por ADO a la BBDD, hace
alguna consulta sencilla, se desconecta de la BBDD y se cierra. A veces
tocará actualizar algún registro, pero simpre es poca cosa.

Por todo esto, tengo dudas de como se va comportar el servidor, si va a
aguantar todas las conexiones, etc
Tampoco se como configurar el servidor sql server 2000, num de
conexiones, etc.para este tipo de infraestructura.
¿Qué os parece? ¿aguantará?, ¿cómo debería configurar el servidor ?

Tampoco sabría como monitorizar el rendimiento cuando lo ponga en
producción o cuando haga pruebas de rendimiento simulando un montón de
conexiones a la vez.

El servidor es probable que tenga 4 gb de Ram.

Muchas gracias

David

Puedes llamar a un web service desde VB 6.0 sin tener que instalar ninguna
librería, sólo necesitas el componente COM MSXML (referencia a "Microsoft
XML") que está en todos los Windows. Básicamente se trata de construir tú
mismo "a pelo" la llamada SOAP en XML y enviarla mediante HTTP.

Aquí tienes un ejemplo de llamada a un servicio web sencillo desde Access
usando VBA que postee una vez en el grupo de Access. (si se puede hacer con
VBA seguro que también con VB 6.0):

http://groups.google.es/group/micro...ff69d3f9e0


Otra posibilidad más sencilla en la parte de VB 6.0, es hacer una especie
de servicio web, pero que no es un servicio web porque no usa SOAP, pero sí
XML y HTTP. Se trata de crear un "generic handler", es decir un archivo
.ashsx en una aplicación web ASP.NET 2.0. Este generic handler tiene código
asociado que te permite procesar la petición HTTP a tu manera. Por ejemplo
se podrían enviar los datos por HTTP POST en un documento XML a este generic
handler desde VB 6.0, entonces el generic handler parsea el documento xml
enviado y llama a SQL Server .


En definitiva, en VB 6.0 tienes el componente COM "Microsoft XML" que viene
de serie en Windows y que tiene objetos que te permiten:
* Manipular XML
* Enviar peticiones HTTP

Con este componente puedes llamar a servicios web SOAP, o construir
peticiones HTTP más sencillas y enviarlas a un servidor web para que las
procese.


Saludos:

Jesús López
www.solidq.com





escribió en el mensaje
news:

Muchas gracias Jesús,
sobre crear un webservices, no tendría problema en crearlo con .Net , pero
el problema es que no se si se puede desde vb 6.0 acceder a un webservice
sin instalar ninguna librería ,ocx, etc.
Una condición que no puedo cambiar es que el cliente tiene que basarse en
un exe ligero y único, sin instalación, ocx, etc.

Un saludo,

David

"Jesús López" wrote in message
news:

Un problema que veo es que de forma prederminada, después de hacer las
operaciones necesarias y cerrar la conexión, realmente la conexión no se
cierra, sino que se va al pool de conexiones. No se va a cerrar realmente
hasta que no pasen unos minutos sin utilizarse la conexión.

Lo primero que yo haría en ese programa de VB 6.0 es desactivar el
Connection Pooling. La razón es que la conexión no se va a reutilizar
una vez que se cierra, por tanto es un desperdicio de recursos mantenerla
en el pool de conexiones. Para desactivar el connection pooling se pone
"OLE DB Services = -2" en la cadena de conexión ADO.

Por otra parte, estoy de acuerdo con la idea de usar algún tipo de middle
tier como web services. Una aplicación web services sí que haría buen uso
del Connection Pooling haciendo que el número de conexíones fuera más
pequeño que con el programilla VB 6.0 el cual se conecta directamente con
SQL Server.

Otra tecnología que podría usarse en este entorno es MSMQ. En caso de que
el sistema no pueda con la carga de trabajo que se da a las "horas
punta", una solución sería enviar la información a colas de mensajes en
varios servidores, donde se está ejecutando un programa que lee de la
cola esos datos y los envía a SQL Server. Así además se reduce el tiempo
de inicio de sesión de los usuarios. En el inicio de sesión se envia un
mensaje a una cola y punto, no se espera a que ese mensaje se procese y
se haga lo que se tenga que hacer en SQL Server.

Saludos:

Jesús López
www.solidq.com



escribió en el mensaje
news:

Lo que hará es muy simple. Simplemente buscar en una tabla de 17.000
registros bien indexada. Si no lo encuentra se añade y si no lo
actualiza.
El problema lo veo, en que si hay conexiones lejanas que tardan más en
hacer el proceso, se vayan quedando conexiones abiertas y poco a poco se
vayan "comiendo" la memoria.




"Maxi" wrote in message
news:#

Hola, es imposible saber si eso funciona sin conocer detalles del
servidor ! El tema es saber que haran esas conexiones y como impacta,
cada conexion consume memoria con lo cual deberias tener un buen numero
ahi, yo trataria de elevarlo a mas de 4GB.

Ahora bien, porque tienes esa arquitectura? no seria mas simple armar
un Web Service y centralizar todo ahi? o un servidor de aplicacion con
Remoting o alguna tecnica de esas?


-
Microsoft M.V.P en SQLServer
SQLTotal Consulting - Servicios en SQLServer
Email:
escribió en el mensaje
news:

Hola,
estoy haciendo un desarrollo sencillo pero que afecta a muchos
usuarios y tengo dudas sobre si lo soportará el servidor y como
configurarlo.
Os cuento,
se basa en un programa cliente ( vb 6.0 ) que recoge datos en el
inicio de sesión de cada pc de una red de unos 17000 equipos..
Lo que hace el programita es muy sencillo, simplemente actualizar unos
pequeños datos, ( información hw, etc, y poca cosa mas)
El problema que veo es que se ejecutarán todos más o menos al mismo
tiempo, es decir, cuando empiecen a trabajar todos los usuarios, entre
las 8 y las 9 de la mañana.
Cada ejecución del cliente, cuando es solo un usuario en la misma red
es instantanea, pero los equipos están disperdigados por toda España.
y las comunicaciones no siempre son buenas.

Al arrancar el cliente se crea una conexión por ADO a la BBDD, hace
alguna consulta sencilla, se desconecta de la BBDD y se cierra. A
veces tocará actualizar algún registro, pero simpre es poca cosa.

Por todo esto, tengo dudas de como se va comportar el servidor, si va
a aguantar todas las conexiones, etc
Tampoco se como configurar el servidor sql server 2000, num de
conexiones, etc.para este tipo de infraestructura.
¿Qué os parece? ¿aguantará?, ¿cómo debería configurar el servidor ?

Tampoco sabría como monitorizar el rendimiento cuando lo ponga en
producción o cuando haga pruebas de rendimiento simulando un montón de
conexiones a la vez.

El servidor es probable que tenga 4 gb de Ram.

Muchas gracias

David