J'ai developpé en C# un webservice d'interrogation de base de données
qui fonctionne correctement sauf lors de la première requete : le délai
d'attente pour la réponse est très longue (temps de réponse *4)... Cette
première requête effectuée, toutes les autres ont des délais d'attente
raisonnable (qq dizaine de ms). Le problème se reproduit après un
certain délai de non utilisation.
Il ne s'agit pas d'un problème de requete, cela se produit quelque soit
la requete et les paramètres sélectionnés.
Le seul paramètre (IIS6.0 sous 2k3 SP1) qui semble correspondre est le delai d'expiration de session. S'agit-il bien de celui-là ?
Non, sous IIS 6.0 il y a une option explicite. Je ne me souviens plus de sa localisation...
Peut-on forcer le webservice a toujours être chargé en mémoire ?
Oui, cf. autres posts.
Le serveur ne fait apparaitre aucun processus ASPNET_WP sous .Net 1.1.4322, est-ce normal ?
Sous dotnet 1.1, j'avais le processus ASPNET_WP...
-- Delf Do not use this email in Cc! L'alcool tue lentement. On s'en fout. On n'est pas pressé.
Arnaud CLERET
Dans le cadre de IIS 6.0 la gestion du process d'exécution de votre application se fait dans les pools d'application. Vous pouvez configurer le recyclage en fonction de différents paramètres comme le délais, le nombre de requêtes ... Vous pouvez aussi paramétrer le nombre de worker process exécutant votre application. En générale, la règle consiste à attribuer 1 worker process par CPU. Donc si 2 CPU = 2 worker process
D'autres optimisations liés à ASP.NET et les Web Services sont aussi possible au niveau de machine.config (voir httpRuntime et ProcessModel).
Le principe de recyclage de l'application est important et permet de garantir la stabilité dans le temps.
Le processus exécuter dans le cadre de IIS 6 est "w3wp.exe"
-- arno - http://www.dotnetguru2.org/acleret/
"Stephane" a écrit dans le message de news: uO%
Bonjour,
Le seul paramètre (IIS6.0 sous 2k3 SP1) qui semble correspondre est le delai d'expiration de session. S'agit-il bien de celui-là ? Peut-on forcer le webservice a toujours être chargé en mémoire ?
Le serveur ne fait apparaitre aucun processus ASPNET_WP sous .Net 1.1.4322, est-ce normal ?
Merci pour votre aide Stéphane
Delf a écrit :
Stephane a écrit :
Comment peut-on modifier ce paramétrage ? Le principal client du web service étant un service de diffusion, il ne peut pas attendre une réponse aussi longtemps ?
Au niveau de la configuration de IIS (dans sa version 6.0) ou dans le fichier machine.config (dans le répertoire Microsoft.NET) pour la 5.0
Dans le cadre de IIS 6.0 la gestion du process d'exécution de votre
application se fait dans les pools d'application. Vous pouvez configurer le
recyclage en fonction de différents paramètres comme le délais, le nombre de
requêtes ...
Vous pouvez aussi paramétrer le nombre de worker process exécutant votre
application. En générale, la règle consiste à attribuer 1 worker process par
CPU. Donc si 2 CPU = 2 worker process
D'autres optimisations liés à ASP.NET et les Web Services sont aussi
possible au niveau de machine.config (voir httpRuntime et ProcessModel).
Le principe de recyclage de l'application est important et permet de
garantir la stabilité dans le temps.
Le processus exécuter dans le cadre de IIS 6 est "w3wp.exe"
--
arno - http://www.dotnetguru2.org/acleret/
"Stephane" <no.spam@merci.com> a écrit dans le message de news:
uO%23Ed0MTGHA.1688@TK2MSFTNGP11.phx.gbl...
Bonjour,
Le seul paramètre (IIS6.0 sous 2k3 SP1) qui semble correspondre est le
delai d'expiration de session. S'agit-il bien de celui-là ?
Peut-on forcer le webservice a toujours être chargé en mémoire ?
Le serveur ne fait apparaitre aucun processus ASPNET_WP sous .Net
1.1.4322, est-ce normal ?
Merci pour votre aide
Stéphane
Delf a écrit :
Stephane a écrit :
Comment peut-on modifier ce paramétrage ? Le principal client du web
service étant un service de diffusion, il ne peut pas attendre une
réponse aussi longtemps ?
Au niveau de la configuration de IIS (dans sa version 6.0) ou dans le
fichier machine.config (dans le répertoire Microsoft.NET) pour la 5.0
Dans le cadre de IIS 6.0 la gestion du process d'exécution de votre application se fait dans les pools d'application. Vous pouvez configurer le recyclage en fonction de différents paramètres comme le délais, le nombre de requêtes ... Vous pouvez aussi paramétrer le nombre de worker process exécutant votre application. En générale, la règle consiste à attribuer 1 worker process par CPU. Donc si 2 CPU = 2 worker process
D'autres optimisations liés à ASP.NET et les Web Services sont aussi possible au niveau de machine.config (voir httpRuntime et ProcessModel).
Le principe de recyclage de l'application est important et permet de garantir la stabilité dans le temps.
Le processus exécuter dans le cadre de IIS 6 est "w3wp.exe"
-- arno - http://www.dotnetguru2.org/acleret/
"Stephane" a écrit dans le message de news: uO%
Bonjour,
Le seul paramètre (IIS6.0 sous 2k3 SP1) qui semble correspondre est le delai d'expiration de session. S'agit-il bien de celui-là ? Peut-on forcer le webservice a toujours être chargé en mémoire ?
Le serveur ne fait apparaitre aucun processus ASPNET_WP sous .Net 1.1.4322, est-ce normal ?
Merci pour votre aide Stéphane
Delf a écrit :
Stephane a écrit :
Comment peut-on modifier ce paramétrage ? Le principal client du web service étant un service de diffusion, il ne peut pas attendre une réponse aussi longtemps ?
Au niveau de la configuration de IIS (dans sa version 6.0) ou dans le fichier machine.config (dans le répertoire Microsoft.NET) pour la 5.0
Stephane
Merci à tous pour vos réponses qui devraient me permettre de résoudre mes problèmes. J'ai effectivement toutes les options nécessaires au niveau de la configuration du pool d'application. A ma charge de bien les exploiter
Arnaud CLERET a écrit :
Dans le cadre de IIS 6.0 la gestion du process d'exécution de votre application se fait dans les pools d'application. Vous pouvez configurer le recyclage en fonction de différents paramètres comme le délais, le nombre de requêtes ... Vous pouvez aussi paramétrer le nombre de worker process exécutant votre application. En générale, la règle consiste à attribuer 1 worker process par CPU. Donc si 2 CPU = 2 worker process
D'autres optimisations liés à ASP.NET et les Web Services sont aussi possible au niveau de machine.config (voir httpRuntime et ProcessModel).
Le principe de recyclage de l'application est important et permet de garantir la stabilité dans le temps.
Le processus exécuter dans le cadre de IIS 6 est "w3wp.exe"
Merci à tous pour vos réponses qui devraient me permettre de résoudre
mes problèmes. J'ai effectivement toutes les options nécessaires au
niveau de la configuration du pool d'application. A ma charge de bien
les exploiter
Arnaud CLERET a écrit :
Dans le cadre de IIS 6.0 la gestion du process d'exécution de votre
application se fait dans les pools d'application. Vous pouvez configurer le
recyclage en fonction de différents paramètres comme le délais, le nombre de
requêtes ...
Vous pouvez aussi paramétrer le nombre de worker process exécutant votre
application. En générale, la règle consiste à attribuer 1 worker process par
CPU. Donc si 2 CPU = 2 worker process
D'autres optimisations liés à ASP.NET et les Web Services sont aussi
possible au niveau de machine.config (voir httpRuntime et ProcessModel).
Le principe de recyclage de l'application est important et permet de
garantir la stabilité dans le temps.
Le processus exécuter dans le cadre de IIS 6 est "w3wp.exe"
Merci à tous pour vos réponses qui devraient me permettre de résoudre mes problèmes. J'ai effectivement toutes les options nécessaires au niveau de la configuration du pool d'application. A ma charge de bien les exploiter
Arnaud CLERET a écrit :
Dans le cadre de IIS 6.0 la gestion du process d'exécution de votre application se fait dans les pools d'application. Vous pouvez configurer le recyclage en fonction de différents paramètres comme le délais, le nombre de requêtes ... Vous pouvez aussi paramétrer le nombre de worker process exécutant votre application. En générale, la règle consiste à attribuer 1 worker process par CPU. Donc si 2 CPU = 2 worker process
D'autres optimisations liés à ASP.NET et les Web Services sont aussi possible au niveau de machine.config (voir httpRuntime et ProcessModel).
Le principe de recyclage de l'application est important et permet de garantir la stabilité dans le temps.
Le processus exécuter dans le cadre de IIS 6 est "w3wp.exe"
Delf
Arnaud CLERET wrote:
Vous pouvez aussi paramétrer le nombre de worker process exécutant votre application. En générale, la règle consiste à attribuer 1 worker process par CPU. Donc si 2 CPU = 2 worker process
J'ai remarqué que si j'active 2 process ASP.NET sur un mono-CPU, j'ai des problèmes de variables de Session...
-- Delf Do not use this email in Cc! L'homme n'est que poussière. La femme est aspirateur.
Arnaud CLERET wrote:
Vous pouvez aussi paramétrer le nombre de worker process exécutant votre
application. En générale, la règle consiste à attribuer 1 worker process par
CPU. Donc si 2 CPU = 2 worker process
J'ai remarqué que si j'active 2 process ASP.NET sur un mono-CPU, j'ai
des problèmes de variables de Session...
--
Delf
Do not use this email in Cc!
L'homme n'est que poussière. La femme est aspirateur.
Vous pouvez aussi paramétrer le nombre de worker process exécutant votre application. En générale, la règle consiste à attribuer 1 worker process par CPU. Donc si 2 CPU = 2 worker process
J'ai remarqué que si j'active 2 process ASP.NET sur un mono-CPU, j'ai des problèmes de variables de Session...
-- Delf Do not use this email in Cc! L'homme n'est que poussière. La femme est aspirateur.
Delf
Arnaud CLERET a écrit :
Le principe de recyclage de l'application est important et permet de garantir la stabilité dans le temps.
Stabilité dans le temps ? Une application stable n'a pas besoin d'être recherger non ?
-- Delf
Arnaud CLERET a écrit :
Le principe de recyclage de l'application est important et permet de
garantir la stabilité dans le temps.
Stabilité dans le temps ? Une application stable n'a pas besoin d'être
recherger non ?
Le principe de recyclage de l'application est important et permet de garantir la stabilité dans le temps.
Stabilité dans le temps ? Une application stable n'a pas besoin d'être recherger non ?
-- Delf
Arnaud CLERET
En effet, dans l'aboslue une application écrite dans les règles de l'art et sans aucune faille ne devrait pas avoir besoin d'être recyclée.
Par contre, dans le cas où cette même application est installée sur un serveur mutualisé, une autre application peut perturber son fonctionnement (utilisation mémoire) si les pools ne sont jamais recyclés.
L'autre possibilité est de paramétrer le pool pour qu'il ne se recycle qu'en cas de dépassement mémoire ce qui dans le cadre d'une application "parfaite" ne déclenchera jamais le recyclage mais permet d'avoir un garde fou au cas où.
-- arno - http://www.dotnetguru2.org/acleret/
"Delf" a écrit dans le message de news: 4422d210$0$12885$
Arnaud CLERET a écrit :
Le principe de recyclage de l'application est important et permet de garantir la stabilité dans le temps.
Stabilité dans le temps ? Une application stable n'a pas besoin d'être recherger non ?
-- Delf
En effet, dans l'aboslue une application écrite dans les règles de l'art et
sans aucune faille ne devrait pas avoir besoin d'être recyclée.
Par contre, dans le cas où cette même application est installée sur un
serveur mutualisé, une autre application peut perturber son fonctionnement
(utilisation mémoire) si les pools ne sont jamais recyclés.
L'autre possibilité est de paramétrer le pool pour qu'il ne se recycle qu'en
cas de dépassement mémoire ce qui dans le cadre d'une application "parfaite"
ne déclenchera jamais le recyclage mais permet d'avoir un garde fou au cas
où.
--
arno - http://www.dotnetguru2.org/acleret/
"Delf" <none@none.org> a écrit dans le message de news:
4422d210$0$12885$626a54ce@news.free.fr...
Arnaud CLERET a écrit :
Le principe de recyclage de l'application est important et permet de
garantir la stabilité dans le temps.
Stabilité dans le temps ? Une application stable n'a pas besoin d'être
recherger non ?
En effet, dans l'aboslue une application écrite dans les règles de l'art et sans aucune faille ne devrait pas avoir besoin d'être recyclée.
Par contre, dans le cas où cette même application est installée sur un serveur mutualisé, une autre application peut perturber son fonctionnement (utilisation mémoire) si les pools ne sont jamais recyclés.
L'autre possibilité est de paramétrer le pool pour qu'il ne se recycle qu'en cas de dépassement mémoire ce qui dans le cadre d'une application "parfaite" ne déclenchera jamais le recyclage mais permet d'avoir un garde fou au cas où.
-- arno - http://www.dotnetguru2.org/acleret/
"Delf" a écrit dans le message de news: 4422d210$0$12885$
Arnaud CLERET a écrit :
Le principe de recyclage de l'application est important et permet de garantir la stabilité dans le temps.
Stabilité dans le temps ? Une application stable n'a pas besoin d'être recherger non ?
-- Delf
Patrice Manac'h
Bonjour,
une application n'a pas besoin d'être tout le temps chargée en mémoire. Par exemple, pour un site de commerce français, entre 3 heures et 5 heures matin, l'activité n'est en général pas très soutenue :) Si vous envisagée d'héberger sur la même machine un site pour un pays sur un aurte fuseau horaire, vous pouvez alors mutualiser la machine pour plusieurs sites...
Cdt,
Patrice Manac'h MCS France
"Arnaud CLERET" a écrit dans le message de news:
En effet, dans l'aboslue une application écrite dans les règles de l'art et sans aucune faille ne devrait pas avoir besoin d'être recyclée.
Par contre, dans le cas où cette même application est installée sur un serveur mutualisé, une autre application peut perturber son fonctionnement (utilisation mémoire) si les pools ne sont jamais recyclés.
L'autre possibilité est de paramétrer le pool pour qu'il ne se recycle qu'en cas de dépassement mémoire ce qui dans le cadre d'une application "parfaite" ne déclenchera jamais le recyclage mais permet d'avoir un garde fou au cas où.
-- arno - http://www.dotnetguru2.org/acleret/
"Delf" a écrit dans le message de news: 4422d210$0$12885$
Arnaud CLERET a écrit :
Le principe de recyclage de l'application est important et permet de garantir la stabilité dans le temps.
Stabilité dans le temps ? Une application stable n'a pas besoin d'être recherger non ?
-- Delf
Bonjour,
une application n'a pas besoin d'être tout le temps chargée en mémoire. Par
exemple, pour un site de commerce français, entre 3 heures et 5 heures
matin, l'activité n'est en général pas très soutenue :) Si vous envisagée
d'héberger sur la même machine un site pour un pays sur un aurte fuseau
horaire, vous pouvez alors mutualiser la machine pour plusieurs sites...
Cdt,
Patrice Manac'h
MCS France
"Arnaud CLERET" <arnaud.cleret@gmail.antispam.com> a écrit dans le message
de news: O3cNzTrTGHA.4080@TK2MSFTNGP10.phx.gbl...
En effet, dans l'aboslue une application écrite dans les règles de l'art
et sans aucune faille ne devrait pas avoir besoin d'être recyclée.
Par contre, dans le cas où cette même application est installée sur un
serveur mutualisé, une autre application peut perturber son fonctionnement
(utilisation mémoire) si les pools ne sont jamais recyclés.
L'autre possibilité est de paramétrer le pool pour qu'il ne se recycle
qu'en cas de dépassement mémoire ce qui dans le cadre d'une application
"parfaite" ne déclenchera jamais le recyclage mais permet d'avoir un garde
fou au cas où.
--
arno - http://www.dotnetguru2.org/acleret/
"Delf" <none@none.org> a écrit dans le message de news:
4422d210$0$12885$626a54ce@news.free.fr...
Arnaud CLERET a écrit :
Le principe de recyclage de l'application est important et permet de
garantir la stabilité dans le temps.
Stabilité dans le temps ? Une application stable n'a pas besoin d'être
recherger non ?
une application n'a pas besoin d'être tout le temps chargée en mémoire. Par exemple, pour un site de commerce français, entre 3 heures et 5 heures matin, l'activité n'est en général pas très soutenue :) Si vous envisagée d'héberger sur la même machine un site pour un pays sur un aurte fuseau horaire, vous pouvez alors mutualiser la machine pour plusieurs sites...
Cdt,
Patrice Manac'h MCS France
"Arnaud CLERET" a écrit dans le message de news:
En effet, dans l'aboslue une application écrite dans les règles de l'art et sans aucune faille ne devrait pas avoir besoin d'être recyclée.
Par contre, dans le cas où cette même application est installée sur un serveur mutualisé, une autre application peut perturber son fonctionnement (utilisation mémoire) si les pools ne sont jamais recyclés.
L'autre possibilité est de paramétrer le pool pour qu'il ne se recycle qu'en cas de dépassement mémoire ce qui dans le cadre d'une application "parfaite" ne déclenchera jamais le recyclage mais permet d'avoir un garde fou au cas où.
-- arno - http://www.dotnetguru2.org/acleret/
"Delf" a écrit dans le message de news: 4422d210$0$12885$
Arnaud CLERET a écrit :
Le principe de recyclage de l'application est important et permet de garantir la stabilité dans le temps.
Stabilité dans le temps ? Une application stable n'a pas besoin d'être recherger non ?
-- Delf
Delf
Patrice Manac'h a écrit :
une application n'a pas besoin d'être tout le temps chargée en mémoire. Par exemple, pour un site de commerce français, entre 3 heures et 5 heures matin, l'activité n'est en général pas très soutenue :)
Oui mais s'il faut attendre 20s que le site se charge à 4h du mat'... c'est scandaleux =) L'acheteur risque d'aller voir ailleurs :)
-- Delf
Patrice Manac'h a écrit :
une application n'a pas besoin d'être tout le temps chargée en mémoire. Par
exemple, pour un site de commerce français, entre 3 heures et 5 heures
matin, l'activité n'est en général pas très soutenue :)
Oui mais s'il faut attendre 20s que le site se charge à 4h du mat'...
c'est scandaleux =) L'acheteur risque d'aller voir ailleurs :)
une application n'a pas besoin d'être tout le temps chargée en mémoire. Par exemple, pour un site de commerce français, entre 3 heures et 5 heures matin, l'activité n'est en général pas très soutenue :)
Oui mais s'il faut attendre 20s que le site se charge à 4h du mat'... c'est scandaleux =) L'acheteur risque d'aller voir ailleurs :)
