Timeout Expired

Hola Maxi,

aquí hay un artículo interesante sobre pooling:
http://www.netveloper.com/contenido.aspx?IDA&IDAP=0&IDC9&IDP=0

de todas formas, el pooling no debe ser problema porque mientras la conexión
está en el pool no existe comunicación entre cliente y servidor; consume
recursos en el servidor (mantener una conexión abierta), y en el cliente
(mantener el objeto connection en memoria)

Eladio Rincón
SQL Server MVP

Solid Quality Learning (http://www.solidqualitylearning.com)
"Comparte lo que sabes, aprende lo que no sepas", FGG

Consulte el histórico del grupo en Google
http://groups.google.com/groups?gro....sqlserver

¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

"MAXI" wrote in message
news:#

Hola, mmm, para mi lo que estas teniendo es un alto consumo de ancho de
banda hacia el servidor de datos :(

Probar lo del pool es simple, sacalo de la cadena de conexion y probamos

Preguntas:

1) Estas usando Sp' o envias consultas desde la aplicacion?
2) Tenes los service Pack instalados del Sqlserver y el SO?
3) Podes medir el ancho de banda en que consumo esta?

Empecemos por aca y vayamos descartando temas ;)

Un abrazo




Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)

"hpmig" escribió en el mensaje
news:
> Mil gracias por responder. Te ampliaré un poco más el escenario: este
> módulo
> de ACD, forma parte de una solución CTI que se conecta, vía socket

TCP/IP,

> a
> un servidor (Switch telefónico) que le envía paquetes con la información
> de
> la llamada arribante. El ACD con esta info. consulta al serv. de SQL

para,

> también mediante un paq. vía red, indicarle al Switch cómo tratar la
> llamada.
> Cuando tuve que finalizar la aplicación, que es multithread (una thread
> para
> mensajes de entrada y otra para los de salida), había procesado

alrededor

> de
> 25 millones de mensajes de entrada y unos 12 millones de salida. En un
> estimado, de los 25 millones de entrada, un 70% necesitan consultar la
> base
> de datos. Estoy utilizando la librería DAAB para .NET 1.1, es decir,
> cierro
> conexiones después de toda actividad. Claro, el pool mantiene, se

supone,

> cierto número de conexiones "dormidas". Cuando inhabilito el pool,

cierra

> perfectamente, ahora sí, la conexión que uso. Aumentar el timeout no me
> sería
> útil, pues cuando una llamada entra, debo contestarle lo más rápido
> posible:
> si no le contesto a la llamada en menos de 15 seg. se colgará. ¿Cómo

puedo

> saber si es un problema de pool? ¿Porqué después de manejar tantas
> consultas,
> de manera tan crítica, con un buen desempeño durante 2 semanas,
> súbitamente,
> cuando menos demandado es, se colapsa el SQL Server? Perdón, no te lo
> había
> mencionado: se colapsó el servicio de datos, pues mi aplicación se pudo
> reiniciar perfectamente, pero ya no se pudo conectar, enviándome el

mismo

> mensaje de error.
>
> "MAXI" wrote:
>
>> Hola, podria ser un problema de pool, tambien podria ser un problema de
>> red.
>> Probaste con aumentar el Timeout?
>>
>>
>>
>> Maxi
>>
>> Buenos Aires - Argentina
>> Desarrollador .NET 3 Estrellas
>> Microsoft User Group (MUG)
>>
>> "HPMig" escribió en el mensaje
>> news:
>> > Desarrollé una apl. telefónica, en C#, muy demandante (cálculo de

ACD)

>> > de
>> > un
>> > call center que recibe en prom. 9000 llamadas diarias. Su desempeño
>> > parece
>> > ser bueno en cuanto a uso de memoria y tiempo de proc. Sin embargo,
>> > después
>> > de un periodo de dos semanas obtengo el siguiente error: "Timeout
>> > expired.
>> > The timeout period elapsed prior to completion of the operation or

the

>> > server
>> > is not responding". Lo extraño es que ocurrió alrededor de las 3:00

am,

>> > cuando el tráfico de llamadas es muy bajo. En mi cadena de conexión

no

>> > inhabilito el "pool", dejo el default de 100 conexiones, ni el

timeout

>> > (30
>> > s). ¿podría ser un problema del pool?
>>
>>
>>

Hola, sip, tienes razon!! pero me ha pasado algo parecido con el DAAB en
unas pruebas que hice :(


Salu2
Maxi


"Eladio Rincón" escribió en el mensaje
news:

Hola Maxi,

aquí hay un artículo interesante sobre pooling:
http://www.netveloper.com/contenido.aspx?IDA&IDAP=0&IDC9&IDP=0

de todas formas, el pooling no debe ser problema porque mientras la
conexión
está en el pool no existe comunicación entre cliente y servidor; consume
recursos en el servidor (mantener una conexión abierta), y en el cliente
(mantener el objeto connection en memoria)

Eladio Rincón
SQL Server MVP

Solid Quality Learning (http://www.solidqualitylearning.com)
"Comparte lo que sabes, aprende lo que no sepas", FGG

Consulte el histórico del grupo en Google
http://groups.google.com/groups?gro....sqlserver

¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

"MAXI" wrote in message
news:#

Hola, mmm, para mi lo que estas teniendo es un alto consumo de ancho de
banda hacia el servidor de datos :(

Probar lo del pool es simple, sacalo de la cadena de conexion y probamos

Preguntas:

1) Estas usando Sp' o envias consultas desde la aplicacion?
2) Tenes los service Pack instalados del Sqlserver y el SO?
3) Podes medir el ancho de banda en que consumo esta?

Empecemos por aca y vayamos descartando temas ;)

Un abrazo




Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)

"hpmig" escribió en el mensaje
news:
> Mil gracias por responder. Te ampliaré un poco más el escenario: este
> módulo
> de ACD, forma parte de una solución CTI que se conecta, vía socket

TCP/IP,

> a
> un servidor (Switch telefónico) que le envía paquetes con la
> información
> de
> la llamada arribante. El ACD con esta info. consulta al serv. de SQL

para,

> también mediante un paq. vía red, indicarle al Switch cómo tratar la
> llamada.
> Cuando tuve que finalizar la aplicación, que es multithread (una thread
> para
> mensajes de entrada y otra para los de salida), había procesado

alrededor

> de
> 25 millones de mensajes de entrada y unos 12 millones de salida. En un
> estimado, de los 25 millones de entrada, un 70% necesitan consultar la
> base
> de datos. Estoy utilizando la librería DAAB para .NET 1.1, es decir,
> cierro
> conexiones después de toda actividad. Claro, el pool mantiene, se

supone,

> cierto número de conexiones "dormidas". Cuando inhabilito el pool,

cierra

> perfectamente, ahora sí, la conexión que uso. Aumentar el timeout no me
> sería
> útil, pues cuando una llamada entra, debo contestarle lo más rápido
> posible:
> si no le contesto a la llamada en menos de 15 seg. se colgará. ¿Cómo

puedo

> saber si es un problema de pool? ¿Porqué después de manejar tantas
> consultas,
> de manera tan crítica, con un buen desempeño durante 2 semanas,
> súbitamente,
> cuando menos demandado es, se colapsa el SQL Server? Perdón, no te lo
> había
> mencionado: se colapsó el servicio de datos, pues mi aplicación se pudo
> reiniciar perfectamente, pero ya no se pudo conectar, enviándome el

mismo

> mensaje de error.
>
> "MAXI" wrote:
>
>> Hola, podria ser un problema de pool, tambien podria ser un problema
>> de
>> red.
>> Probaste con aumentar el Timeout?
>>
>>
>>
>> Maxi
>>
>> Buenos Aires - Argentina
>> Desarrollador .NET 3 Estrellas
>> Microsoft User Group (MUG)
>>
>> "HPMig" escribió en el mensaje
>> news:
>> > Desarrollé una apl. telefónica, en C#, muy demandante (cálculo de

ACD)

>> > de
>> > un
>> > call center que recibe en prom. 9000 llamadas diarias. Su desempeño
>> > parece
>> > ser bueno en cuanto a uso de memoria y tiempo de proc. Sin embargo,
>> > después
>> > de un periodo de dos semanas obtengo el siguiente error: "Timeout
>> > expired.
>> > The timeout period elapsed prior to completion of the operation or

the

>> > server
>> > is not responding". Lo extraño es que ocurrió alrededor de las 3:00

am,

>> > cuando el tráfico de llamadas es muy bajo. En mi cadena de conexión

no

>> > inhabilito el "pool", dejo el default de 100 conexiones, ni el

timeout

>> > (30
>> > s). ¿podría ser un problema del pool?
>>
>>
>>

Hola, estas usando la version 3.1 del DAAB?

Otra cosa, fijate el consumo de red, que velocidad y equipos tiene esa red?


Salu2
Maxi


"hpmig" escribió en el mensaje
news:

Saludos.

1. Utilizo exclusivamente stored procedures, tanto de consulta, como de
actualización. Para "llamarlos", hago uso de Data Access Application Block
(DAAB), en su versión p/.NET Framework 1.1 (mi apl. la desarrollé en C#
2003).

2. Tanto el servidor de SQL, como mi aplicación, "corren" en el mismo
equipo: W2K Server con SP 4, 2 procesadores Xeon 2.4Ghz (HT - es decir,
están
disponibles 4 procesadores), 3GB RAM. El SQL Server tiene instalado el SP
3a
( Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation Standard Edition on Windows
NT
5.0 (Build 2195: Service Pack 4) ).

3. ¿cómo puedo medir el ancho de banda?

Gracias.

"MAXI" escribió:

Hola, mmm, para mi lo que estas teniendo es un alto consumo de ancho de
banda hacia el servidor de datos :(

Probar lo del pool es simple, sacalo de la cadena de conexion y probamos

Preguntas:

1) Estas usando Sp' o envias consultas desde la aplicacion?
2) Tenes los service Pack instalados del Sqlserver y el SO?
3) Podes medir el ancho de banda en que consumo esta?

Empecemos por aca y vayamos descartando temas ;)

Un abrazo




Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)

"hpmig" escribió en el mensaje
news:
> Mil gracias por responder. Te ampliaré un poco más el escenario: este
> módulo
> de ACD, forma parte de una solución CTI que se conecta, vía socket
> TCP/IP,
> a
> un servidor (Switch telefónico) que le envía paquetes con la
> información
> de
> la llamada arribante. El ACD con esta info. consulta al serv. de SQL
> para,
> también mediante un paq. vía red, indicarle al Switch cómo tratar la
> llamada.
> Cuando tuve que finalizar la aplicación, que es multithread (una thread
> para
> mensajes de entrada y otra para los de salida), había procesado
> alrededor
> de
> 25 millones de mensajes de entrada y unos 12 millones de salida. En un
> estimado, de los 25 millones de entrada, un 70% necesitan consultar la
> base
> de datos. Estoy utilizando la librería DAAB para .NET 1.1, es decir,
> cierro
> conexiones después de toda actividad. Claro, el pool mantiene, se
> supone,
> cierto número de conexiones "dormidas". Cuando inhabilito el pool,
> cierra
> perfectamente, ahora sí, la conexión que uso. Aumentar el timeout no me
> sería
> útil, pues cuando una llamada entra, debo contestarle lo más rápido
> posible:
> si no le contesto a la llamada en menos de 15 seg. se colgará. ¿Cómo
> puedo
> saber si es un problema de pool? ¿Porqué después de manejar tantas
> consultas,
> de manera tan crítica, con un buen desempeño durante 2 semanas,
> súbitamente,
> cuando menos demandado es, se colapsa el SQL Server? Perdón, no te lo
> había
> mencionado: se colapsó el servicio de datos, pues mi aplicación se pudo
> reiniciar perfectamente, pero ya no se pudo conectar, enviándome el
> mismo
> mensaje de error.
>
> "MAXI" wrote:
>
>> Hola, podria ser un problema de pool, tambien podria ser un problema
>> de
>> red.
>> Probaste con aumentar el Timeout?
>>
>>
>>
>> Maxi
>>
>> Buenos Aires - Argentina
>> Desarrollador .NET 3 Estrellas
>> Microsoft User Group (MUG)
>>
>> "HPMig" escribió en el mensaje
>> news:
>> > Desarrollé una apl. telefónica, en C#, muy demandante (cálculo de
>> > ACD)
>> > de
>> > un
>> > call center que recibe en prom. 9000 llamadas diarias. Su desempeño
>> > parece
>> > ser bueno en cuanto a uso de memoria y tiempo de proc. Sin embargo,
>> > después
>> > de un periodo de dos semanas obtengo el siguiente error: "Timeout
>> > expired.
>> > The timeout period elapsed prior to completion of the operation or
>> > the
>> > server
>> > is not responding". Lo extraño es que ocurrió alrededor de las 3:00
>> > am,
>> > cuando el tráfico de llamadas es muy bajo. En mi cadena de conexión
>> > no
>> > inhabilito el "pool", dejo el default de 100 conexiones, ni el
>> > timeout
>> > (30
>> > s). ¿podría ser un problema del pool?
>>
>>
>>

ah si? y que pasaba? no se liberaban las conexiones? crecían indefinidamente
los SPIDs en sysprocesses?

Eladio Rincón
SQL Server MVP

Solid Quality Learning (http://www.solidqualitylearning.com)
"Comparte lo que sabes, aprende lo que no sepas", FGG

Consulte el histórico del grupo en Google
http://groups.google.com/groups?gro....sqlserver

¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

"Maxi" wrote in message
news:

Hola, sip, tienes razon!! pero me ha pasado algo parecido con el DAAB en
unas pruebas que hice :(


Salu2
Maxi


"Eladio Rincón" escribió en el mensaje
news:
> Hola Maxi,
>
> aquí hay un artículo interesante sobre pooling:
> http://www.netveloper.com/contenido.aspx?IDA&IDAP=0&IDC9&IDP=0
>
> de todas formas, el pooling no debe ser problema porque mientras la
> conexión
> está en el pool no existe comunicación entre cliente y servidor; consume
> recursos en el servidor (mantener una conexión abierta), y en el cliente
> (mantener el objeto connection en memoria)
>
> Eladio Rincón
> SQL Server MVP
>
> Solid Quality Learning (http://www.solidqualitylearning.com)
> "Comparte lo que sabes, aprende lo que no sepas", FGG
>
> Consulte el histórico del grupo en Google
> http://groups.google.com/groups?gro....sqlserver
>
> ¿Te interesa participar en las reuniones
> del grupo de Usuarios de SQL-Server y .NET
> Se harán en levante de España, (Alicante o Murcia)?
>
> "MAXI" wrote in message
> news:#
>> Hola, mmm, para mi lo que estas teniendo es un alto consumo de ancho de
>> banda hacia el servidor de datos :(
>>
>> Probar lo del pool es simple, sacalo de la cadena de conexion y

probamos

>>
>> Preguntas:
>>
>> 1) Estas usando Sp' o envias consultas desde la aplicacion?
>> 2) Tenes los service Pack instalados del Sqlserver y el SO?
>> 3) Podes medir el ancho de banda en que consumo esta?
>>
>> Empecemos por aca y vayamos descartando temas ;)
>>
>> Un abrazo
>>
>>
>>
>>
>> Maxi
>>
>> Buenos Aires - Argentina
>> Desarrollador .NET 3 Estrellas
>> Microsoft User Group (MUG)
>>
>> "hpmig" escribió en el mensaje
>> news:
>> > Mil gracias por responder. Te ampliaré un poco más el escenario: este
>> > módulo
>> > de ACD, forma parte de una solución CTI que se conecta, vía socket
> TCP/IP,
>> > a
>> > un servidor (Switch telefónico) que le envía paquetes con la
>> > información
>> > de
>> > la llamada arribante. El ACD con esta info. consulta al serv. de SQL
> para,
>> > también mediante un paq. vía red, indicarle al Switch cómo tratar la
>> > llamada.
>> > Cuando tuve que finalizar la aplicación, que es multithread (una

thread

>> > para
>> > mensajes de entrada y otra para los de salida), había procesado
> alrededor
>> > de
>> > 25 millones de mensajes de entrada y unos 12 millones de salida. En

un

>> > estimado, de los 25 millones de entrada, un 70% necesitan consultar

la

>> > base
>> > de datos. Estoy utilizando la librería DAAB para .NET 1.1, es decir,
>> > cierro
>> > conexiones después de toda actividad. Claro, el pool mantiene, se
> supone,
>> > cierto número de conexiones "dormidas". Cuando inhabilito el pool,
> cierra
>> > perfectamente, ahora sí, la conexión que uso. Aumentar el timeout no

me

>> > sería
>> > útil, pues cuando una llamada entra, debo contestarle lo más rápido
>> > posible:
>> > si no le contesto a la llamada en menos de 15 seg. se colgará. ¿Cómo
> puedo
>> > saber si es un problema de pool? ¿Porqué después de manejar tantas
>> > consultas,
>> > de manera tan crítica, con un buen desempeño durante 2 semanas,
>> > súbitamente,
>> > cuando menos demandado es, se colapsa el SQL Server? Perdón, no te lo
>> > había
>> > mencionado: se colapsó el servicio de datos, pues mi aplicación se

pudo

>> > reiniciar perfectamente, pero ya no se pudo conectar, enviándome el
> mismo
>> > mensaje de error.
>> >
>> > "MAXI" wrote:
>> >
>> >> Hola, podria ser un problema de pool, tambien podria ser un problema
>> >> de
>> >> red.
>> >> Probaste con aumentar el Timeout?
>> >>
>> >>
>> >>
>> >> Maxi
>> >>
>> >> Buenos Aires - Argentina
>> >> Desarrollador .NET 3 Estrellas
>> >> Microsoft User Group (MUG)
>> >>
>> >> "HPMig" escribió en el mensaje
>> >> news:
>> >> > Desarrollé una apl. telefónica, en C#, muy demandante (cálculo de
> ACD)
>> >> > de
>> >> > un
>> >> > call center que recibe en prom. 9000 llamadas diarias. Su

desempeño

>> >> > parece
>> >> > ser bueno en cuanto a uso de memoria y tiempo de proc. Sin

embargo,

>> >> > después
>> >> > de un periodo de dos semanas obtengo el siguiente error: "Timeout
>> >> > expired.
>> >> > The timeout period elapsed prior to completion of the operation or
> the
>> >> > server
>> >> > is not responding". Lo extraño es que ocurrió alrededor de las

3:00

> am,
>> >> > cuando el tráfico de llamadas es muy bajo. En mi cadena de

conexión

> no
>> >> > inhabilito el "pool", dejo el default de 100 conexiones, ni el
> timeout
>> >> > (30
>> >> > s). ¿podría ser un problema del pool?
>> >>
>> >>
>> >>
>>
>>
>
>

Gracias por sus respuestas.

Maxi, cómo se dió el problema en tus pruebas... ¿lo resolviste?,
¿abandonaste el DAAB?

En realidad, esta apl. de ACD hace uso de un "backend" de datos a petición
del cliente, pues originalmente cargaba todos los datos en memoria "DataSets"
y los cálculos no necesitaban, obviamente, consultas y no teníamos problemas.
El Switch telefónico también se ejecuta en el mismo equipo, y de manera
crítica, también requiere de ancho de banda, sin embargo nunca dejó de
procesar mensajes, ni generó errores de sockets, ni timeouts. Como verás,
todas las aplics. son altamentes "críticas", requiriendo de ancho de banda
todas. No tuvimos problemas en la comunicación entre módulos, sólo con SQL
Server... dudo que sea por ancho de banda. ¿Hay notificaciones de bugs en el
DAAB que estoy usando? Otra vez, mil gracias.

"Maxi" escribió:

Hola, sip, tienes razon!! pero me ha pasado algo parecido con el DAAB en
unas pruebas que hice :(


Salu2
Maxi


"Eladio Rincón" escribió en el mensaje
news:
> Hola Maxi,
>
> aquí hay un artículo interesante sobre pooling:
> http://www.netveloper.com/contenido.aspx?IDA&IDAP=0&IDC9&IDP=0
>
> de todas formas, el pooling no debe ser problema porque mientras la
> conexión
> está en el pool no existe comunicación entre cliente y servidor; consume
> recursos en el servidor (mantener una conexión abierta), y en el cliente
> (mantener el objeto connection en memoria)
>
> Eladio Rincón
> SQL Server MVP
>
> Solid Quality Learning (http://www.solidqualitylearning.com)
> "Comparte lo que sabes, aprende lo que no sepas", FGG
>
> Consulte el histórico del grupo en Google
> http://groups.google.com/groups?gro....sqlserver
>
> ¿Te interesa participar en las reuniones
> del grupo de Usuarios de SQL-Server y .NET
> Se harán en levante de España, (Alicante o Murcia)?
>
> "MAXI" wrote in message
> news:#
>> Hola, mmm, para mi lo que estas teniendo es un alto consumo de ancho de
>> banda hacia el servidor de datos :(
>>
>> Probar lo del pool es simple, sacalo de la cadena de conexion y probamos
>>
>> Preguntas:
>>
>> 1) Estas usando Sp' o envias consultas desde la aplicacion?
>> 2) Tenes los service Pack instalados del Sqlserver y el SO?
>> 3) Podes medir el ancho de banda en que consumo esta?
>>
>> Empecemos por aca y vayamos descartando temas ;)
>>
>> Un abrazo
>>
>>
>>
>>
>> Maxi
>>
>> Buenos Aires - Argentina
>> Desarrollador .NET 3 Estrellas
>> Microsoft User Group (MUG)
>>
>> "hpmig" escribió en el mensaje
>> news:
>> > Mil gracias por responder. Te ampliaré un poco más el escenario: este
>> > módulo
>> > de ACD, forma parte de una solución CTI que se conecta, vía socket
> TCP/IP,
>> > a
>> > un servidor (Switch telefónico) que le envía paquetes con la
>> > información
>> > de
>> > la llamada arribante. El ACD con esta info. consulta al serv. de SQL
> para,
>> > también mediante un paq. vía red, indicarle al Switch cómo tratar la
>> > llamada.
>> > Cuando tuve que finalizar la aplicación, que es multithread (una thread
>> > para
>> > mensajes de entrada y otra para los de salida), había procesado
> alrededor
>> > de
>> > 25 millones de mensajes de entrada y unos 12 millones de salida. En un
>> > estimado, de los 25 millones de entrada, un 70% necesitan consultar la
>> > base
>> > de datos. Estoy utilizando la librería DAAB para .NET 1.1, es decir,
>> > cierro
>> > conexiones después de toda actividad. Claro, el pool mantiene, se
> supone,
>> > cierto número de conexiones "dormidas". Cuando inhabilito el pool,
> cierra
>> > perfectamente, ahora sí, la conexión que uso. Aumentar el timeout no me
>> > sería
>> > útil, pues cuando una llamada entra, debo contestarle lo más rápido
>> > posible:
>> > si no le contesto a la llamada en menos de 15 seg. se colgará. ¿Cómo
> puedo
>> > saber si es un problema de pool? ¿Porqué después de manejar tantas
>> > consultas,
>> > de manera tan crítica, con un buen desempeño durante 2 semanas,
>> > súbitamente,
>> > cuando menos demandado es, se colapsa el SQL Server? Perdón, no te lo
>> > había
>> > mencionado: se colapsó el servicio de datos, pues mi aplicación se pudo
>> > reiniciar perfectamente, pero ya no se pudo conectar, enviándome el
> mismo
>> > mensaje de error.
>> >
>> > "MAXI" wrote:
>> >
>> >> Hola, podria ser un problema de pool, tambien podria ser un problema
>> >> de
>> >> red.
>> >> Probaste con aumentar el Timeout?
>> >>
>> >>
>> >>
>> >> Maxi
>> >>
>> >> Buenos Aires - Argentina
>> >> Desarrollador .NET 3 Estrellas
>> >> Microsoft User Group (MUG)
>> >>
>> >> "HPMig" escribió en el mensaje
>> >> news:
>> >> > Desarrollé una apl. telefónica, en C#, muy demandante (cálculo de
> ACD)
>> >> > de
>> >> > un
>> >> > call center que recibe en prom. 9000 llamadas diarias. Su desempeño
>> >> > parece
>> >> > ser bueno en cuanto a uso de memoria y tiempo de proc. Sin embargo,
>> >> > después
>> >> > de un periodo de dos semanas obtengo el siguiente error: "Timeout
>> >> > expired.
>> >> > The timeout period elapsed prior to completion of the operation or
> the
>> >> > server
>> >> > is not responding". Lo extraño es que ocurrió alrededor de las 3:00
> am,
>> >> > cuando el tráfico de llamadas es muy bajo. En mi cadena de conexión
> no
>> >> > inhabilito el "pool", dejo el default de 100 conexiones, ni el
> timeout
>> >> > (30
>> >> > s). ¿podría ser un problema del pool?
>> >>
>> >>
>> >>
>>
>>
>
>