ES2330488T3 - Procedimiento de gestion de carga de un servidor. - Google Patents
Procedimiento de gestion de carga de un servidor. Download PDFInfo
- Publication number
- ES2330488T3 ES2330488T3 ES07731620T ES07731620T ES2330488T3 ES 2330488 T3 ES2330488 T3 ES 2330488T3 ES 07731620 T ES07731620 T ES 07731620T ES 07731620 T ES07731620 T ES 07731620T ES 2330488 T3 ES2330488 T3 ES 2330488T3
- Authority
- ES
- Spain
- Prior art keywords
- server
- request
- terminal
- load
- requests
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 33
- 238000004590 computer program Methods 0.000 claims description 5
- 230000008569 process Effects 0.000 claims description 5
- 230000001960 triggered effect Effects 0.000 claims description 2
- 238000012800 visualization Methods 0.000 claims 1
- 238000004891 communication Methods 0.000 description 14
- 238000012545 processing Methods 0.000 description 7
- 230000008901 benefit Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 238000010586 diagram Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000004913 activation Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000009499 grossing Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000004377 microelectronic Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 238000007619 statistical method Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1012—Server selection for load balancing based on compliance of requirements or conditions with available server resources
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Computer And Data Communications (AREA)
- Information Transfer Between Computers (AREA)
- Telephonic Communication Services (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Hardware Redundancy (AREA)
Abstract
Procedimiento de gestión de carga de al menos un servidor capaz de tratar peticiones emitidas por mediación de una red de telecomunicaciones por una pluralidad de terminales, tal que comprende al menos: - una etapa (S11) de recepción por el servidor de una petición proveniente de un terminal, - una etapa de obtención de un valor de estimación de una carga del servidor, - una etapa (S14, S16, S18) de envío, hacia dicho terminal, de datos capaces de provocar una reemisión automática, por dicho terminal y hacia dicho servidor, de dicha petición en una fecha posterior, en función de una previsión relativa a la carga del servidor, siendo ejecutada dicha etapa de envío si dicho valor de estimación es superior a un valor de umbral.
Description
Procedimiento de gestión de carga de un
servidor.
La invención se refiere a un procedimiento de
gestión de carga de un servidor capaz de tratar las peticiones
emitidas por mediación de una red de telecomunicaciones mediante una
pluralidad de terminales.
En el campo de las redes públicas, los
servidores de tratamiento de datos son dimensionados para ser
capaces de tratar un número importante de peticiones provenientes
de terminales distintos. Es el caso, por ejemplo, de los servidores
de sitio web que son dimensionados en función de una estimación de
la actividad media que genera el o los sitios administrados por
este servidor.
Ahora bien, sea cual sea la capacidad de
tratamiento de un servidor, subsiste sin embargo el riesgo de que
el número de peticiones a tratar sobrepase durante un periodo de
tiempo muy corto la capacidad del servidor. Tal situación conlleva
muy a menudo a un hundimiento de los rendimientos del servidor, no
estando éste ya en condiciones de responder a las nuevas
peticiones. Las peticiones son entonces o bien rechazadas con un
código de error o bien redirigidas hacia un servidor tampón que
devuelve una página de información que indica sin más precisión que
el servidor no puede aceptar una nueva conexión y que sería bueno
que el usuario se volviese a conectar posteriormente.
En otros casos finalmente, los tiempos de
respuesta son tan largos que el internauta efectúa en vano varias
tentativas para acceder a una página del sitio Web, lo que tiene
como consecuencia aumentar el número de peticiones a tratar por el
servidor y, por lo tanto, alargar incluso más los tiempos de
respuesta a una petición de acceso a este sito Web.
Han sido elaboradas diferentes técnicas para
responder a estos problemas, por ejemplo las técnicas de reparto de
carga (o "load balancing" según la denominación
inglesa). En tal aproximación, un equipo de la red se encarga de
repartir la carga entre un conjunto de servidores al que está
asociado:
- o bien adjudica una petición a un servidor
diferente en cada nueva petición, siendo los servidores
seleccionados por turno para esta adjudicación,
- o bien espera a que un servidor alcance un
umbral de carga predefinido para adjudicar las nuevas peticiones al
servidor siguiente en su lista de servidores.
Sin embargo, tales soluciones no permiten, en
caso de sobrecarga global del conjunto de los servidores, garantizar
que una petición sea tratada normalmente, ni tampoco garantizar un
plazo de tratamiento de las peticiones. Además, por razones de
coste, un sobredimensionamiento excesivo de los servidores que
permiten administrar situaciones de carga excepcional raramente es
previsible.
En el documento SURYANARAYANAN K ET AL:
"Performance evaluation of new methods of automatic redirection
for load balancing of apache servers distributed in the internet"
LOCAL COMPUTER NETWORKS, 2000. LCN 2000. PROCEEDINGS: 25TH ANNUAL
IDEEE CONFERENCE ON NOVEMBER 8-10, 2000, PISCATAWAY,
NJ, USA, IEEE, 8 de noviembre de 2000
(08-11-2000), páginas
644-651, XP010527500 ISBN:
0-7695-0912-6, los
autores desarrollan y evalúan cambios en el servidor http Open
source Apache para redirigir automáticamente unas peticiones durante
periodos de fuerte carga hacia un servidor de sobrecarga
especificado previamente.
La invención tiene por objetivo suministrar un
procedimiento de gestión de carga de un servidor capaz de tratar
las peticiones emitidas por mediación de una red de
telecomunicaciones mediante una pluralidad de terminales,
permitiendo administrar a menor coste las situaciones de sobrecarga
puntuales de este servidor, garantizando particularmente la
atención de la petición así como el plazo en el que esta petición
será atendida.
Con este objetivo, la invención tiene por
objeto, según un primer aspecto, un procedimiento de gestión de
carga de al menos un servidor capaz de tratar peticiones emitidas
por mediación de una red de telecomunicaciones mediante una
pluralidad de terminales, comprendiendo el procedimiento al
menos:
- una etapa de recepción mediante el servidor de
una petición proveniente de un terminal,
- una etapa de obtención de un valor de
estimación de una carga del servidor,
- una etapa de envío, hacia dicho terminal, de
datos destinados a provocar una reemisión automática por dicho
terminal y hacia dicho servidor de dicha petición en una fecha
posterior, en función de una previsión relativa a la carga del
servidor, siendo ejecutada dicha etapa de envío si dicho valor de
estimación es superior a un valor de umbral.
Según la invención, está previsto, en caso de
sobrecarga del servidor, aplazar el tratamiento de una petición a
una fecha posterior, provocando la reemisión automática de la
petición en esta fecha posterior. Por ello, es posible garantizar
al usuario emisor de la petición que su petición será atendida
automáticamente y tratada posteriormente, particularmente cuando la
carga del servidor lo permita. Además, el usuario termina
normalmente y sin mensaje de error su sesión de consulta del
servidor.
La invención permite regular la carga de un
servidor mediante un reparto mejor en el tiempo del tratamiento de
peticiones. Así, se anticipan y evitan las sobrecargas puntuales del
servidor. Además, la invención es utilizable en combinación con las
soluciones de regulación de carga conocidas, particularmente con los
mecanismos precitados de reparto de carga entre varios
servidores.
Según un modo de realización particular, los
datos están destinados a provocar el desencadenamiento de una
temporización que tiene una duración correspondiente a una
estimación de un plazo de espera antes de la atención de la
petición, estando esta estimación en función de una previsión
relativa a la carga del servidor, teniendo lugar la reemisión
automática tras la expiración de la temporización.
La fecha de reemisión de la petición se deriva
así de la duración de temporización.
Este método simplifica la programación de la
reemisión de la petición, ya que basta determinar una duración de
espera previsible antes de la atención y el tratamiento de la
petición y desencadenar una temporización que tiene esta
duración.
Según un modo de realización particular, los
datos están destinados a provocar una visualización en dicho
terminal de dicho plazo de espera estimado, siendo desencadenada la
temporización con la condición de aceptación de dicho plazo por un
usuario del terminal.
De este modo, la duración de espera se comunica
al usuario del terminal emisor de la petición. El usuario es así
avisado del problema de carga y de la duración de espera a prever.
Puede por lo tanto o bien aprovechar su plazo de espera para
efectuar otras tareas, o bien renunciar a conectarse.
El internauta puede aceptar o rechazar el plazo
de espera y, cuando acepta, se beneficia de la garantía de ser
reconectado automáticamente.
Según un modo de realización particular, los
datos generados por el servidor comprenden un indicador de emisión
destinado a estar insertado en la petición durante su reemisión por
el terminal.
El indicador de emisión permite al servidor
saber si una petición que recibe es una petición que ya ha sido
emitida precedentemente y que es objeto de una reemisión. La gestión
de las peticiones reemitidas es por lo tanto posible gracias a este
indicador.
Según un modo de realización particular, los
datos generados por el servidor comprenden una información sobre
una fecha de primera recepción de dicha petición, estando destinada
dicha información a estar insertada en dicha petición durante su
reemisión.
La datación de las peticiones permite al
servidor tratar las peticiones reemitidas por orden cronológico
relativamente a la fecha de la primera tentativa de conexión. Esta
información de fecha es así útil para la correcta atención de una
petición con indicador de emisión.
La invención tiene igualmente por objeto un
programa de ordenador que comprende instrucciones de código de
programa para la ejecución de las etapas del procedimiento según la
invención cuando dicho programa se ejecuta en un ordenador.
Según un segundo aspecto, la invención tiene por
objeto un servidor de tratamiento capaz de tratar las peticiones
emitidas por mediación de una red de telecomunicaciones mediante una
pluralidad de terminales, comprendiendo el servidor:
- unos medios para recibir una petición
proveniente de un terminal,
- unos medios para obtener un valor de
estimación de una carga del servidor,
- unos medios para, cuando dicho valor de
estimación sea superior a un valor de umbral, enviar a dicho
terminal unos datos destinados a provocar una reemisión automática,
por dicho terminal y hacia dicho servidor, de dicha petición en una
fecha posterior, en función de una previsión relativa a la carga del
servidor.
\vskip1.000000\baselineskip
Según un modo de realización particular, el
servidor según la invención comprende:
- unos medios para determinar, tras la recepción
de una petición, si ésta contiene un indicador de emisión,
- unos medios para tratar las peticiones que
comprenden un indicador de emisión de manera prioritaria con
respecto a las que no lo contienen.
\newpage
Otros objetivos, características y ventajas de
la invención aparecerán a través de la descripción que sigue, dada
únicamente a título de ejemplo no limitativo, y hecha en referencia
a los dibujos adjuntos en los que:
- la figura 1 comprende un esquema de una
configuración de sistema de telecomunicaciones a la que se aplica la
invención;
- la figura 2 ilustra mediante un diagrama el
funcionamiento y los rendimientos del procedimiento según la
invención;
- la figura 3 comprende un organigrama del
procedimiento según la invención.
El sistema de telecomunicaciones representado en
la figura 1 comprende una pluralidad de terminales 101, 102, 103
capaces de emitir por mediación de la red 300 de telecomunicaciones
unas peticiones hacia un conjunto que forma el servidor 200 que
comprende una o varias máquinas 201, 202, 203 de servidor.
La red 300 de telecomunicaciones es por ejemplo
la red Internet, una red celular de tipo UMTS (Universal Mobile
Telecommunication System), o cualquier otro tipo de red de
telecomunicaciones capaz de transmitir datos en forma de
peticiones.
Los terminales 101, 102, 103 son por ejemplo
ordenadores personales, teléfonos de tercera generación, asistentes
personales (PDA, Personal Digital Assistant) o cualquier otro
tipo de terminal capaz de emitir peticiones hacia un servidor. Estos
terminales acceden a una red 300 de telecomunicaciones.
En el resto de la descripción, la invención es
descrita en un modo de realización en el que los terminales 101,
102, 103 son unos terminales que acceden a la red Internet, siendo
el servidor 200 un servidor de sito web que trata las peticiones
emitidas por los terminales durante las sesiones de consulta del o
de los sitios web asociados al servidor 200.
Las etapas S10 a S34 del procedimiento según la
invención se describen en detalle mediante referencia a la figura
3. Estas etapas son preferentemente puestas en práctica por un
procesador de tratamiento de datos del servidor, procesador que
recurre a programas o subprogramas concebidos para la ejecución de
las diferentes etapas de este procedimiento.
En la etapa S10, el servidor 200 está en espera
por mediación de una interfaz de comunicación de una petición
proveniente de uno de los terminales 101, 102, 103. En la etapa S11,
el servidor 200 recibe una petición.
En la etapa S12, el servidor 200 obtiene una
estimación de la carga. Esta estimación es por ejemplo el número
medio de peticiones recibidas por segundo o el número medio de
nuevas sesiones de usuario abiertas por segundo, el porcentaje de
tiempo de CPU normalmente utilizado, etc. Es por lo tanto relativa o
bien al volumen del tráfico administrado por el servidor, o bien a
una tasa de carga, tasa que se mide por ejemplo comparativamente a
su capacidad de tratamiento. Esta estimación se determina mediante
un módulo lógico de supervisión de la carga del servidor, módulo
puesto en práctica por el propio servidor o por otro servidor que
coopera con el servidor 200.
Si el valor de esta estimación es superior a un
umbral, el servidor 200 ejecuta la etapa S13, si no, ejecuta la
etapa S21. El umbral es definido por ejemplo a partir de la carga
crítica máxima que puede ser absorbida por el servidor por unidad
de tiempo. Esta carga es la carga más allá de la cual el servidor ya
no está en condiciones de trabajar con tiempos de respuesta
satisfactorios. Preferentemente el umbral es inferior a la carga
crítica máxima, con el fin de anticiparse a la aparición de la carga
crítica. El umbral se elige por ejemplo igual al 90% de esta carga
crítica máxima.
En la etapa S13, el servidor comprueba si, en
los parámetros de la petición recibida, se encuentra un indicador
de emisión. La presencia de un indicador de emisión en una petición
permite determinar que se trata de una petición que ya ha sido
emitida, y que es objeto de una reemisión conforme al procedimiento
según la invención. Tal indicador de emisión ha sido generado por
el servidor y transmitido al terminal con el fin de ser insertado
en la petición durante su reemisión.
Un indicador de emisión se presenta en forma de
conjunto de datos. Este conjunto de datos comprende al menos un
identificador de indicador de emisión, preferentemente en forma de
combinación alfanumérica, única y no falsificable.
El indicador de emisión comprende
preferentemente una indicación de un plazo de espera asociado al
indicador de emisión, expresado en segundos o minutos, así como la
fecha en la que la petición ha sido recibida por primera vez por el
servidor.
El indicador de emisión juega de alguna manera
el papel de un tique de espera, que atestigua que una petición ya
ha sido emitida. Permite marcar la petición emitida y da
informaciones sobre la fecha de emisión y el plazo de espera
programado. Permite por lo tanto la gestión de la espera programada
para una petición.
Estos datos son identificables entre los otros
parámetros de la petición por medio de etiquetas, símbolos,
caracteres específicos o palabras clave, tales como los utilizados
en la codificación de los parámetros de las URL. En el ejemplo
siguiente, el identificador del indicador de emisión
"45ft672345FR6" es localizable en la URL por medio de la
palabra clave "ticketweb":
\hskip1cm
http://www.korigan.univ.fr/inscript/ticketweb=45ft672345FR6t
En el equipo lógico de utilización de las URL,
la activación de tal enlace provoca el envío del identificador y de
la palabra clave asociada al servidor web que administra las
peticiones del sitio www.korigan.univ.fr.
El plazo de espera asociado a un indicador de
emisión corresponde al periodo de tiempo necesario en el servidor
para terminar el tratamiento de las sesiones de comunicación en
curso y para tratar las sesiones de comunicación de las peticiones
que tiene, ya puestas en espera. Este plazo se estima en base a una
previsión de la carga del servidor. Esta previsión de carga es por
ejemplo en función del número de sesiones de comunicación en curso,
de la duración media de una sesión de comunicación, del número de
peticiones que ya han sido puestas en espera y de los plazos de
puesta en espera programados para estas peticiones. El servidor
comprende así un módulo de análisis estadístico capaz de calcular
los parámetros pertinentes y de actualizar regularmente estos
parámetros.
Durante la etapa S14 o S15 ejecutada después de
la etapa S13, el servidor estima el plazo de espera para el
tratamiento de la petición en base a previsiones de carga del
servidor.
Si en la etapa S13 la petición no contiene
indicador de emisión, el servidor genera en la etapa S14 un
indicador de emisión para esta petición y después ejecuta la etapa
S16.
Si en la etapa S13 la petición contiene un
indicador de emisión, el servidor continúa hasta la etapa S15 para
la actualización del indicador de emisión, remplazando el plazo de
espera previsto inicialmente por un nuevo plazo. El servidor
ejecuta después la etapa S16.
En la etapa S16, el servidor envía al terminal
en respuesta a la petición recibida un conjunto de datos, en forma
de página HTML, destinada a provocar la visualización en el terminal
de una ventana de diálogo. Esta ventana de diálogo permite a la vez
visualizar el plazo de espera determinado y proponer al usuario del
terminal unas opciones para el tratamiento de la petición:
- una primera opción correspondiente a la
aceptación del plazo de espera combinada con una reemisión
automática de la petición tras la expiración del plazo de
espera;
- una segunda opción correspondiente a la
solicitud de reemisión de la petición en una fecha posterior a
elegir por el usuario;
- una tercera opción correspondiente al abandono
de la tentativa de conexión.
La ventana de diálogo presenta por lo tanto unos
elementos de diálogo, por ejemplo en forma de botones, iconos,
enlaces de hipertexto, etc., por mediación de los cuales el usuario
es invitado a seleccionar la opción elegida. Cuando el usuario
pincha en uno de estos elementos para seleccionar una de las
opciones, una información relativa a la opción elegida es
comunicada al servidor. El servidor analiza esta información, la
memoriza y la tiene en cuenta para sus previsiones de carga.
En la etapa S17, el servidor determina en base a
la información recibida si el usuario ha aceptado el plazo de
espera.
En caso afirmativo, el servidor reenvía al
terminal en la etapa S18 una página HTML que comprende unos datos de
programa, típicamente en forma de script (conjunto de instrucciones
que pueden interpretarse en tiempo real) en lenguaje Java,
destinados a provocar la ejecución de un programa en el
terminal.
En la etapa S19, el script se ejecuta y provoca
el desencadenamiento de una temporización cuya duración corresponde
al plazo de espera estimado para el tratamiento de la petición. Tras
la expiración de la temporización, el script provoca la reconexión
automática en el sito del servidor mediante la reemisión automática
de la petición hacia el servidor, comprendiendo esta petición
reemitida el indicador de emisión nuevamente generado (caso de la
etapa S14) o actualizado (caso de la etapa S15).
El script puede utilizar uno de los dos métodos
siguientes para arrancar la reconexión al sitio:
- o bien envía un comando HTTP de tipo
"redirect" en una URL enriquecida que comprende los datos de un
indicador de emisión,
- o bien envía un comando HTTP de tipo
"post" para reenviar un formulario que contiene los parámetros
del indicador de emisión.
En los dos casos, el procedimiento de reconexión
es transparente para el usuario que se encontrará después del plazo
de expiración automáticamente conectado al sitio de Internet.
Después de la etapa S19, el proceso se termina
en la etapa S20. Después de la etapa S20, el proceso se retoma en la
etapa S10.
En la etapa S31, ejecutada después de la etapa
S17 en caso de que el usuario haya rechazado el plazo de espera, el
servidor determina si el usuario ha solicitado la reemisión de la
petición en una fecha posterior.
En caso negativo, el servidor invita en la etapa
S32 al usuario a reconectarse posteriormente. La sesión de
comunicación entre el terminal y el servidor se termina entonces por
una desconexión HTTP en la etapa S34, lo que tiene por efecto
liberar los recursos del servidor para el tratamiento de otras
peticiones.
En caso afirmativo, en la etapa S33, el servidor
envía un mensaje electrónico con los datos que permiten la
reconexión. Estos datos están preferentemente en forma de URL que
comprende, en los datos opcionales, un indicador de emisión que
comprende al menos un identificador de indicador de emisión. Así,
cuando el usuario solicita una conexión utilizando la URL así
constituida, los datos opcionales se transmiten al servidor con la
petición y el servidor está en condiciones de determinar que se
trata de una petición reemitida. La sesión de comunicación entre el
terminal y el servidor se termina seguidamente por una desconexión
HTTP en la etapa S34.
La etapa S21 se ejecuta después de la
comprobación de la etapa S12 cuando la carga del servidor no
sobrepasa el umbral definido. Durante la etapa S21, el servidor
determina si la petición que acaba de recibir comprende un
indicador de emisión.
En caso afirmativo, el servidor suprime en la
etapa S22 este indicador de emisión y adjudica a la petición un
identificador de sesión de comunicación prioritaria. Tal
identificador se utiliza para indicar que la petición debe ser
tratada con prioridad con respecto a otras peticiones que no
comprenden más que un simple identificador de sesión de
comunicación. En el contexto de la invención, los identificadores de
sesión de comunicación prioritaria se distinguen de los otros por
ejemplo por el rango de valor en el que se encuentran.
En la etapa S23, el servidor determina si la
petición comprende un identificador de sesión y, en caso negativo,
adjudica, durante la etapa S24, tal identificador a la petición.
En la etapa S25, el servidor prosigue el
tratamiento de la petición, según el protocolo normalmente
utilizado. Así, es posible una negociación para determinar si el
resto del tratamiento debe desarrollarse utilizando el protocolo
HTTP (etapa S26) o por mediación de una nueva sesión de comunicación
que implica la utilización del protocolo HTTPS (etapa S27). La
presencia de un identificador de sesión de comunicación prioritaria
no modifica la ejecución de las etapas S25, S26, S27 con respecto a
una situación sin identificador prioritario.
El tratamiento de la petición prosigue después
en la etapa S28, durante la cual el servidor determina en base al
identificador de sesión de comunicación si se trata de una petición
prioritaria o no, y trata con prioridad las peticiones que
comprenden un identificador de sesión de comunicación
prioritaria.
La información de fecha asociada al indicador de
emisión es utilizable de varias maneras.
Según una primera variante, esta información se
utiliza durante el tratamiento de la petición, estando este
tratamiento en función de la fecha de primera conexión. Esta
variante es particularmente útil para operaciones en línea para las
que se impone una fecha límite, por ejemplo una declaración de renta
o inscripción en una universidad. En este tipo de situaciones, se
asiste frecuentemente a una saturación del servidor poco antes de
la expiración de la fecha límite impuesta. La invención permite, por
lo tanto, admitir conexiones posteriores a la fecha límite
impuesta, en la medida en que se trate de una reemisión automática
de una petición que ha sido emitida por primera vez antes de la
fecha límite impuesta. La información de fecha asociada al indicador
de emisión es preferentemente codificada de manera no
infalsificable para evitar cualquier fraude posible.
Según una segunda variante, la información de
fecha asociada al indicador de emisión permite al servidor
administrar las peticiones prioritarias por orden cronológico de
recepción, relativamente a la fecha de primera tentativa de
conexión. En esta variante las peticiones son seriadas en una fila
de espera. Así, cuando la petición de un usuario se coloca en la
fila de espera, el usuario sabe que, al cabo del plazo de espera que
el servidor le ha notificado, tendrá acceso prioritario a los
servicios propuestos por este servidor, siendo efectuada la
reconexión de manera transparente y totalmente automatizada.
La invención permite así escalonar en el tiempo
y planificar las peticiones con destino recibidas por un servidor
mientras que este último alcanza o está cerca de su carga crítica
máxima.
El gráfico de la figura 2 ilustra la eficacia
del sistema de generación de indicador de emisión. Este gráfico
comprende dos curvas C1 y C2 de variación de la carga del servidor
en función del tiempo. La curva C1, obtenida para un servidor que
no pone en práctica la invención, muestra un fuerte pico en la zona
de los valores de carga superior a un valor crítico máximo V1. Este
pico se traduce en una fuerte degradación del servicio.
La curva C2 muestra la variación de carga
obtenida para un servidor que pone en práctica la invención para un
número de peticiones y un reparto idénticos a los de la curva C1. En
este caso, desde que la carga del servidor alcanza el valor V2, el
servidor desencadena el proceso según la invención y la generación
de indicador de emisión. De esto resulta que la curva C2 sobrepasa
a penas el valor V2 de umbral, y nunca alcanza el valor V1 de
umbral crítico. El pico de carga es absorbido en un largo periodo de
tiempo.
Según una implantación preferida, las diferentes
etapas del procedimiento de gestión de carga se ejecutan por medio
de instrucciones de programas de ordenador.
En consecuencia, la invención trata también de
un programa de ordenador sobre un soporte de informaciones, siendo
este programa susceptible de ser puesto en práctica en un ordenador,
comprendiendo este programa unas instrucciones adaptadas a la
puesta en práctica de un procedimiento de gestión de carga tal como
el mencionado anteriormente.
Este programa puede utilizar cualquier lenguaje
de programación, y estar en forma de código fuente, código objeto, o
código intermedio entre código fuente y código objeto, tal como en
un forma parcialmente compilada, o cualquier otra forma
deseable.
La invención trata también de un soporte de
informaciones legibles por un ordenador, y que comprende
instrucciones de un programa de ordenador tal como el mencionado
anteriormente.
El soporte de informaciones puede ser cualquier
entidad o dispositivo capaz de almacenar el programa. Por ejemplo,
el soporte puede comprender un medio de almacenamiento, tal como una
ROM, por ejemplo un CD ROM o una ROM de circuito microelectrónico,
o incluso un medio de grabación magnética, por ejemplo un disquete
(floppy disc) o un disco duro.
Por otra parte, el soporte de informaciones
puede ser un soporte transmisible tal como una señal eléctrica u
óptica, que puede estar encaminada por mediación de un cable
eléctrico u óptico, por radio o por otros medios. El programa según
la invención puede ser en particular telecargado en una red de tipo
Internet.
Alternativamente, el soporte de informaciones
puede ser un circuito integrado en el que el programa está
incorporado, estando adaptado el circuito para ejecutar o para ser
utilizado en la ejecución del procedimiento en cuestión.
La invención permite obtener un efecto de
alisado de la curva de carga. A pesar de un ligero aumento del
número de peticiones a tratar, el reparto en el tiempo de la carga
del servidor se mejora enormemente, siendo absorbidas todas las
variaciones bruscas de tráfico con mucha soltura.
La invención es aplicable a todo tipo de
servidor, sea cual sea el tipo de peticiones tratadas.
Claims (10)
1. Procedimiento de gestión de carga de al menos
un servidor capaz de tratar peticiones emitidas por mediación de una
red de telecomunicaciones por una pluralidad de terminales, tal que
comprende al menos:
- una etapa (S11) de recepción por el servidor
de una petición proveniente de un terminal,
- una etapa de obtención de un valor de
estimación de una carga del servidor,
- una etapa (S14, S16, S18) de envío, hacia
dicho terminal, de datos capaces de provocar una reemisión
automática, por dicho terminal y hacia dicho servidor, de dicha
petición en una fecha posterior, en función de una previsión
relativa a la carga del servidor, siendo ejecutada dicha etapa de
envío si dicho valor de estimación es superior a un valor de
umbral.
2. Procedimiento según la reivindicación 1, en
el que dichos datos están destinados a provocar el desencadenamiento
(S19) de una temporización que tiene una duración correspondiente a
una estimación de un plazo de espera antes de la atención de la
petición, estando dicha estimación en función de una previsión
relativa a la carga del servidor, teniendo lugar dicha reemisión
automática tras la expiración de dicha temporización.
3. Procedimiento según la reivindicación 2, en
el que dichos datos están destinados a provocar una visualización
en dicho terminal de dicho plazo de espera estimado, siendo
desencadenada dicha temporización con la condición de aceptación de
dicho plazo por un usuario del terminal.
4. Procedimiento según una cualquiera de las
reivindicaciones 1 a 3, en el que dichos datos comprenden un
indicador de emisión destinado a estar insertado en dicha petición
durante su reemisión por dicho terminal.
5. Procedimiento según una cualquiera de las
reivindicaciones 1 a 4, en el que dichos datos comprenden una
información sobre una fecha de primera recepción de dicha petición,
estando destinada dicha información a estar insertada en dicha
petición durante su reemisión por dicho terminal.
6. Procedimiento según la reivindicación según
una cualquiera de las reivindicaciones 4 ó 5, en el que:
- el servidor determina (S13, S21), tras la
recepción de una petición, si ésta contiene un indicador de
emisión,
- el servidor trata (S28) las peticiones que
comprenden un indicador de emisión de manera prioritaria con
respecto a las que no lo contienen.
7. Procedimiento según la reivindicación 6, en
el que el servidor trata las peticiones reemitidas que comprenden
un indicador de emisión por orden cronológico de recepción en base a
dicha información de fecha.
8. Programa de ordenador que comprende unas
instrucciones de código de programa para la ejecución de todas las
etapas del procedimiento según las reivindicaciones 1 a 7 cuando
dicho programa se ejecuta en un ordenador.
9. Servidor de tratamiento capaz de tratar las
peticiones emitidas por mediación de una red de telecomunicaciones
por una pluralidad de terminales, tal que comprende:
- unos medios para recibir (S11) una petición
proveniente de un terminal,
- unos medios para obtener un valor de
estimación de una carga del servidor,
- unos medios para, cuando dicho valor de
estimación es superior a un valor de umbral, enviar (S14, S16, S18)
a dicho terminal unos datos destinados a provocar una reemisión
automática, por dicho terminal y hacia dicho servidor, de dicha
petición en una fecha posterior, en función de una previsión
relativa a la carga del servidor.
10. Servidor según la reivindicación 9, que
comprende:
- unos medios para determinar (S13, S21), tras
la recepción de una petición, si contiene un indicador de
emisión,
- unos medios para tratar (S28) las peticiones
que comprenden un indicador de emisión de manera prioritaria con
respecto a las que no lo contienen.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0650639 | 2006-02-24 | ||
| FR0650639 | 2006-02-24 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2330488T3 true ES2330488T3 (es) | 2009-12-10 |
Family
ID=37387276
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES07731620T Active ES2330488T3 (es) | 2006-02-24 | 2007-02-13 | Procedimiento de gestion de carga de un servidor. |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US20090138586A1 (es) |
| EP (1) | EP1987658B1 (es) |
| AT (1) | ATE437522T1 (es) |
| DE (1) | DE602007001679D1 (es) |
| ES (1) | ES2330488T3 (es) |
| WO (1) | WO2007096555A2 (es) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR101221656B1 (ko) * | 2012-03-26 | 2013-01-24 | 에이큐 주식회사 | 대기표 운용 시스템 및 그 운용방법 |
| KR102090493B1 (ko) * | 2013-01-22 | 2020-03-18 | 삼성전자주식회사 | 무선 통신 네트워크에서 http 프로토콜의 전송 지연과 http 서버의 프로세싱 부하를 줄이는 장치 및 방법 |
| US9270617B2 (en) * | 2013-06-05 | 2016-02-23 | Sap Se | Load controller framework |
| US10951690B2 (en) | 2017-09-22 | 2021-03-16 | Microsoft Technology Licensing, Llc | Near real-time computation of scaling unit's load and availability state |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6314565B1 (en) * | 1997-05-19 | 2001-11-06 | Intervu, Inc. | System and method for automated identification, retrieval, and installation of multimedia software components |
| EP1421710B1 (en) * | 2001-08-16 | 2017-11-15 | QUALCOMM Incorporated | Methods, mobile communications device and base station in a communication system having shared communications resources |
| US7003575B2 (en) * | 2001-10-15 | 2006-02-21 | First Hop Oy | Method for assisting load balancing in a server cluster by rerouting IP traffic, and a server cluster and a client, operating according to same |
| US7152102B2 (en) * | 2002-10-31 | 2006-12-19 | Microsoft Corporation | On-line wizard entry point management computer system and method |
| US8082339B2 (en) * | 2003-02-28 | 2011-12-20 | Hewlett-Packard Development Company, L.P. | Electronic device network having graceful denial of service |
-
2007
- 2007-02-13 ES ES07731620T patent/ES2330488T3/es active Active
- 2007-02-13 EP EP07731620A patent/EP1987658B1/fr not_active Not-in-force
- 2007-02-13 WO PCT/FR2007/050795 patent/WO2007096555A2/fr not_active Ceased
- 2007-02-13 DE DE602007001679T patent/DE602007001679D1/de active Active
- 2007-02-13 AT AT07731620T patent/ATE437522T1/de not_active IP Right Cessation
- 2007-02-13 US US12/280,606 patent/US20090138586A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| ATE437522T1 (de) | 2009-08-15 |
| US20090138586A1 (en) | 2009-05-28 |
| DE602007001679D1 (de) | 2009-09-03 |
| WO2007096555A3 (fr) | 2007-10-11 |
| EP1987658A2 (fr) | 2008-11-05 |
| EP1987658B1 (fr) | 2009-07-22 |
| WO2007096555A2 (fr) | 2007-08-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20130269007A1 (en) | Authentication system, authentication server, service providing server, authentication method, and computer-readable recording medium | |
| ES2330488T3 (es) | Procedimiento de gestion de carga de un servidor. | |
| US20040122959A1 (en) | Automatic wireless network login using embedded meta data | |
| WO2011162838A1 (en) | Security model for workflows aggregating third party secure services | |
| US8131810B2 (en) | Reachability realization server, management system, management method and realization program | |
| CN106911714B (zh) | Android设备基于进程间通信的移动应用单点登录方法 | |
| ES2813093T3 (es) | Método para atender solicitudes de acceso a información de ubicación | |
| US20120311674A1 (en) | Method and system for automatic generation of cache directives for security policy | |
| CN105847220A (zh) | 一种认证方法、系统和服务平台 | |
| CN106453396A (zh) | 双令牌账户登录方法及登录验证装置 | |
| CN107979577B (zh) | 一种终端认证的方法及设备 | |
| US7086051B2 (en) | Method and apparatus for just-in-time provisioning application-related information at a communication device | |
| CN105635124B (zh) | 流量控制方法和装置 | |
| CN103560884B (zh) | 用户身份信息的注销方法、系统、认证服务器及客户端 | |
| KR101491845B1 (ko) | 서버측에서 클라이언트와 서버의 백엔드간의 연결을 매개하는 연결 관리 방법 및 시스템 | |
| CN110191203A (zh) | 实现服务器动态访问的方法及电子设备 | |
| JP5398997B2 (ja) | 課金情報管理システムおよび課金情報管理方法 | |
| JP2012003338A (ja) | 認証システム、認証代理サーバ、制御プログラム及び認証方法 | |
| US20140128111A1 (en) | Converged dialog in hybrid mobile applications | |
| JP6164690B2 (ja) | 情報配信装置、方法およびプログラム | |
| JP4902633B2 (ja) | Ｗｅｂシステムおよびリクエスト処理方法 | |
| KR20150028217A (ko) | 서버측에서 클라이언트와 서버의 백엔드간의 연결을 매개하는 연결 관리 방법 및 시스템 | |
| KR101643339B1 (ko) | 사용자 인증방법 및 인증시스템 | |
| CN116095164B (zh) | 基于通信协议的设备连接入网方法、设备及存储介质 | |
| WO2025068628A1 (en) | An apparatus and a method for sharing data usage information of a roaming user equipment |