J'ai développé un site en ASP sur IIS5 avec de l'ADO sur du SQL Server 2000.
Il fonctionne très bien mais quant je le test je m'apercois que 80% des
resources processeurs sont utilisées sur le serveur quant je navigue sur le
site (elle retombe à 3% si personne n'est sur le site). Actuellement je suis
seul a le tester mais en productiont il devrais y avoir plusieurs dixaines
de personne dessus presque en permanence. Même si en prod le processeur du
serveur sera plus puissant je suis étonné de ses 80% d'utilisation, avez
vous une expérience de se genre de situation et y a t'il quelque chose à
faire pour minimiser l'utilisation du processeur ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Rachelle
"Eric" écrivait news:c21fph$4b3$:
Bonjour,
j'ai constatée la meme chose mais seulement qq minutes aprés le déploiement ... Une fois le déploiement effectué, je te conseille de faire sur la console d'IIS, noeud de l'ordi, 'Action, toutes les taches, redémarrage d'IIS...' et ensuite tu navigue un peu sur le site histoire qu'il mette les pages en mémoires cache. Les ressources procs vont redescendre assez vite en fait ...
Bonjour,
J'ai développé un site en ASP sur IIS5 avec de l'ADO sur du SQL Server 2000.
Il fonctionne très bien mais quant je le test je m'apercois que 80% des resources processeurs sont utilisées sur le serveur quant je navigue sur le site (elle retombe à 3% si personne n'est sur le site). Actuellement je suis seul a le tester mais en productiont il devrais y avoir plusieurs dixaines de personne dessus presque en permanence. Même si en prod le processeur du serveur sera plus puissant je suis étonné de ses 80% d'utilisation, avez vous une expérience de se genre de situation et y a t'il quelque chose à faire pour minimiser l'utilisation du processeur ?
j'ai constatée la meme chose mais seulement qq minutes aprés le
déploiement ... Une fois le déploiement effectué, je te conseille de
faire sur la console d'IIS, noeud de l'ordi, 'Action, toutes les taches,
redémarrage d'IIS...' et ensuite tu navigue un peu sur le site histoire
qu'il mette les pages en mémoires cache. Les ressources procs vont
redescendre assez vite en fait ...
Bonjour,
J'ai développé un site en ASP sur IIS5 avec de l'ADO sur du SQL Server
2000.
Il fonctionne très bien mais quant je le test je m'apercois que 80%
des resources processeurs sont utilisées sur le serveur quant je
navigue sur le site (elle retombe à 3% si personne n'est sur le site).
Actuellement je suis seul a le tester mais en productiont il devrais y
avoir plusieurs dixaines de personne dessus presque en permanence.
Même si en prod le processeur du serveur sera plus puissant je suis
étonné de ses 80% d'utilisation, avez vous une expérience de se genre
de situation et y a t'il quelque chose à faire pour minimiser
l'utilisation du processeur ?
j'ai constatée la meme chose mais seulement qq minutes aprés le déploiement ... Une fois le déploiement effectué, je te conseille de faire sur la console d'IIS, noeud de l'ordi, 'Action, toutes les taches, redémarrage d'IIS...' et ensuite tu navigue un peu sur le site histoire qu'il mette les pages en mémoires cache. Les ressources procs vont redescendre assez vite en fait ...
Bonjour,
J'ai développé un site en ASP sur IIS5 avec de l'ADO sur du SQL Server 2000.
Il fonctionne très bien mais quant je le test je m'apercois que 80% des resources processeurs sont utilisées sur le serveur quant je navigue sur le site (elle retombe à 3% si personne n'est sur le site). Actuellement je suis seul a le tester mais en productiont il devrais y avoir plusieurs dixaines de personne dessus presque en permanence. Même si en prod le processeur du serveur sera plus puissant je suis étonné de ses 80% d'utilisation, avez vous une expérience de se genre de situation et y a t'il quelque chose à faire pour minimiser l'utilisation du processeur ?
Merci pour vos réponses...
Eric
Je l'ai fait malheureusement ca ne change rien.
Chaque requette sur IIS me prend en moyenne 70% des resources du processeur.
J'ai configuré IIS pour qu'il mettre toutes les pages en cache et n'ai activé la compression http1.1 qu'uniquement sur les fichiers statiques.
Pourtant tout fonctionne bien et assez rapidement, mes pages sont générées en moyenne en 0.35 secondes elle font de 40 à 50 ko avec des appel à une base SQL Server.
Je suis plutôt inquiete, la mise en prod va être problèmatique. Le plus fort c'est que je n'avais rien remarqué avant et je me demande si je n'ai pas changé un réglage quelque part qui a provoqué ce phénomène.
Mais j'ai beau chercher je ne vois rien.
"Rachelle" a écrit dans le message de news:
"Eric" écrivait news:c21fph$4b3$:
Bonjour,
j'ai constatée la meme chose mais seulement qq minutes aprés le déploiement ... Une fois le déploiement effectué, je te conseille de faire sur la console d'IIS, noeud de l'ordi, 'Action, toutes les taches, redémarrage d'IIS...' et ensuite tu navigue un peu sur le site histoire qu'il mette les pages en mémoires cache. Les ressources procs vont redescendre assez vite en fait ...
Je l'ai fait malheureusement ca ne change rien.
Chaque requette sur IIS me prend en moyenne 70% des resources du processeur.
J'ai configuré IIS pour qu'il mettre toutes les pages en cache et n'ai
activé la compression http1.1 qu'uniquement sur les fichiers statiques.
Pourtant tout fonctionne bien et assez rapidement, mes pages sont générées
en moyenne en 0.35 secondes elle font de 40 à 50 ko avec des appel à une
base SQL Server.
Je suis plutôt inquiete, la mise en prod va être problèmatique. Le plus fort
c'est que je n'avais rien remarqué avant et je me demande si je n'ai pas
changé un réglage quelque part qui a provoqué ce phénomène.
Mais j'ai beau chercher je ne vois rien.
"Rachelle" <rwagner@9online.fr> a écrit dans le message de
news:XnF94A07650315DArwagner9onlinefr@212.27.42.73...
j'ai constatée la meme chose mais seulement qq minutes aprés le
déploiement ... Une fois le déploiement effectué, je te conseille de
faire sur la console d'IIS, noeud de l'ordi, 'Action, toutes les taches,
redémarrage d'IIS...' et ensuite tu navigue un peu sur le site histoire
qu'il mette les pages en mémoires cache. Les ressources procs vont
redescendre assez vite en fait ...
Chaque requette sur IIS me prend en moyenne 70% des resources du processeur.
J'ai configuré IIS pour qu'il mettre toutes les pages en cache et n'ai activé la compression http1.1 qu'uniquement sur les fichiers statiques.
Pourtant tout fonctionne bien et assez rapidement, mes pages sont générées en moyenne en 0.35 secondes elle font de 40 à 50 ko avec des appel à une base SQL Server.
Je suis plutôt inquiete, la mise en prod va être problèmatique. Le plus fort c'est que je n'avais rien remarqué avant et je me demande si je n'ai pas changé un réglage quelque part qui a provoqué ce phénomène.
Mais j'ai beau chercher je ne vois rien.
"Rachelle" a écrit dans le message de news:
"Eric" écrivait news:c21fph$4b3$:
Bonjour,
j'ai constatée la meme chose mais seulement qq minutes aprés le déploiement ... Une fois le déploiement effectué, je te conseille de faire sur la console d'IIS, noeud de l'ordi, 'Action, toutes les taches, redémarrage d'IIS...' et ensuite tu navigue un peu sur le site histoire qu'il mette les pages en mémoires cache. Les ressources procs vont redescendre assez vite en fait ...
jbongran
Eric wrote:
Je l'ai fait malheureusement ca ne change rien.
Chaque requette sur IIS me prend en moyenne 70% des resources du processeur.
J'ai configuré IIS pour qu'il mettre toutes les pages en cache et n'ai activé la compression http1.1 qu'uniquement sur les fichiers statiques.
Pourtant tout fonctionne bien et assez rapidement, mes pages sont générées en moyenne en 0.35 secondes elle font de 40 à 50 ko avec des appel à une base SQL Server.
Je suis plutôt inquiete, la mise en prod va être problèmatique. Le plus fort c'est que je n'avais rien remarqué avant et je me demande si je n'ai pas changé un réglage quelque part qui a provoqué ce phénomène.
Mais j'ai beau chercher je ne vois rien.
"Rachelle" a écrit dans le message de news:
"Eric" écrivait news:c21fph$4b3$:
Bonjour,
j'ai constatée la meme chose mais seulement qq minutes aprés le déploiement ... Une fois le déploiement effectué, je te conseille de faire sur la console d'IIS, noeud de l'ordi, 'Action, toutes les taches, redémarrage d'IIS...' et ensuite tu navigue un peu sur le site histoire qu'il mette les pages en mémoires cache. Les ressources procs vont redescendre assez vite en fait ...
Les objets de connexion et les recordsets sont bien fermés et détruits sur chaque page ?
Eric wrote:
Je l'ai fait malheureusement ca ne change rien.
Chaque requette sur IIS me prend en moyenne 70% des resources du
processeur.
J'ai configuré IIS pour qu'il mettre toutes les pages en cache et n'ai
activé la compression http1.1 qu'uniquement sur les fichiers
statiques.
Pourtant tout fonctionne bien et assez rapidement, mes pages sont
générées en moyenne en 0.35 secondes elle font de 40 à 50 ko avec des
appel à une base SQL Server.
Je suis plutôt inquiete, la mise en prod va être problèmatique. Le
plus fort c'est que je n'avais rien remarqué avant et je me demande
si je n'ai pas changé un réglage quelque part qui a provoqué ce
phénomène.
Mais j'ai beau chercher je ne vois rien.
"Rachelle" <rwagner@9online.fr> a écrit dans le message de
news:XnF94A07650315DArwagner9onlinefr@212.27.42.73...
j'ai constatée la meme chose mais seulement qq minutes aprés le
déploiement ... Une fois le déploiement effectué, je te conseille de
faire sur la console d'IIS, noeud de l'ordi, 'Action, toutes les
taches, redémarrage d'IIS...' et ensuite tu navigue un peu sur le
site histoire qu'il mette les pages en mémoires cache. Les
ressources procs vont redescendre assez vite en fait ...
Les objets de connexion et les recordsets sont bien fermés et détruits sur
chaque page ?
Chaque requette sur IIS me prend en moyenne 70% des resources du processeur.
J'ai configuré IIS pour qu'il mettre toutes les pages en cache et n'ai activé la compression http1.1 qu'uniquement sur les fichiers statiques.
Pourtant tout fonctionne bien et assez rapidement, mes pages sont générées en moyenne en 0.35 secondes elle font de 40 à 50 ko avec des appel à une base SQL Server.
Je suis plutôt inquiete, la mise en prod va être problèmatique. Le plus fort c'est que je n'avais rien remarqué avant et je me demande si je n'ai pas changé un réglage quelque part qui a provoqué ce phénomène.
Mais j'ai beau chercher je ne vois rien.
"Rachelle" a écrit dans le message de news:
"Eric" écrivait news:c21fph$4b3$:
Bonjour,
j'ai constatée la meme chose mais seulement qq minutes aprés le déploiement ... Une fois le déploiement effectué, je te conseille de faire sur la console d'IIS, noeud de l'ordi, 'Action, toutes les taches, redémarrage d'IIS...' et ensuite tu navigue un peu sur le site histoire qu'il mette les pages en mémoires cache. Les ressources procs vont redescendre assez vite en fait ...
Les objets de connexion et les recordsets sont bien fermés et détruits sur chaque page ?
Eric
Les Recordset oui mais pas la connexion, si je devais refaire une connexion à chaque page cela necessiterais encore plus de resources, non ?
Les objets de connexion et les recordsets sont bien fermés et détruits sur chaque page ?
Les Recordset oui mais pas la connexion, si je devais refaire une connexion
à chaque page cela necessiterais encore plus de resources, non ?
Les objets de connexion et les recordsets sont bien fermés et détruits sur
chaque page ?
Les Recordset oui mais pas la connexion, si je devais refaire une connexion à chaque page cela necessiterais encore plus de resources, non ?
Les objets de connexion et les recordsets sont bien fermés et détruits sur chaque page ?
jbongran
Eric wrote:
Les Recordset oui mais pas la connexion, si je devais refaire une connexion à chaque page cela necessiterais encore plus de resources, non ?
Les objets de connexion et les recordsets sont bien fermés et détruits sur chaque page ?
Non, car le fait de ne pas le faire à chaque page implique que d'une manière ou d'une autre l'objet de connection est soit dans l'objet Session ou Application, et ça c'est pas bien du tout ;-) D'ailleurs tant qu'on en est aux trucs en asp pour les bases de données, voici ce que j'ai pu constater : L'utilisation des méthodes GetStrings et GetRows et un réél plus pour récuperer des enregs (en gros il n'y a plus d'aller-retour entre le serveur web et la BDD entre chaque enreg), avec l'avantage de pouvoir fermer ET detruire le recordset tout de suite. Utilisation exclusive d'OLEDB Creation, ouverture, utilisation, fermeture et destruction des objets de connection sur chaque page. Une routine traitant et réinitialisant l'objet objDB.Errors peut avoir des effets surprenants (j'imagine que ce doit être en rapport avec l'utilisation de mémoire liée au stockage des messsages qui s'empilent)
Eric wrote:
Les Recordset oui mais pas la connexion, si je devais refaire une
connexion à chaque page cela necessiterais encore plus de resources,
non ?
Les objets de connexion et les recordsets sont bien fermés et
détruits sur chaque page ?
Non, car le fait de ne pas le faire à chaque page implique que d'une manière
ou d'une autre l'objet de connection est soit dans l'objet Session ou
Application, et ça c'est pas bien du tout ;-)
D'ailleurs tant qu'on en est aux trucs en asp pour les bases de données,
voici ce que j'ai pu constater :
L'utilisation des méthodes GetStrings et GetRows et un réél plus pour
récuperer des enregs (en gros il n'y a plus d'aller-retour entre le serveur
web et la BDD entre chaque enreg), avec l'avantage de pouvoir fermer ET
detruire le recordset tout de suite.
Utilisation exclusive d'OLEDB
Creation, ouverture, utilisation, fermeture et destruction des objets de
connection sur chaque page.
Une routine traitant et réinitialisant l'objet objDB.Errors peut avoir des
effets surprenants (j'imagine que ce doit être en rapport avec l'utilisation
de mémoire liée au stockage des messsages qui s'empilent)
Les Recordset oui mais pas la connexion, si je devais refaire une connexion à chaque page cela necessiterais encore plus de resources, non ?
Les objets de connexion et les recordsets sont bien fermés et détruits sur chaque page ?
Non, car le fait de ne pas le faire à chaque page implique que d'une manière ou d'une autre l'objet de connection est soit dans l'objet Session ou Application, et ça c'est pas bien du tout ;-) D'ailleurs tant qu'on en est aux trucs en asp pour les bases de données, voici ce que j'ai pu constater : L'utilisation des méthodes GetStrings et GetRows et un réél plus pour récuperer des enregs (en gros il n'y a plus d'aller-retour entre le serveur web et la BDD entre chaque enreg), avec l'avantage de pouvoir fermer ET detruire le recordset tout de suite. Utilisation exclusive d'OLEDB Creation, ouverture, utilisation, fermeture et destruction des objets de connection sur chaque page. Une routine traitant et réinitialisant l'objet objDB.Errors peut avoir des effets surprenants (j'imagine que ce doit être en rapport avec l'utilisation de mémoire liée au stockage des messsages qui s'empilent)
Eric
Finalement j'ai repris tout mon code et regarder les endroits ou ca coince, j'ai trouvé plein de petit truc a obtimiser et l'ensemble de ces corrections m'a fait gagner énormément de performance je suis maintenant à moins de 21% des resources processeurs sur mon serveur de développement et en prod (que je viens d'installer) je suis à 5% :-)
Une page type est maintenant générée en 0.121 secondes au lieu de 0.350 sur mon serveur de développement et en 0.066 sur mon serveur de prod :-))
Comme quoi on code, on code et puis on ne fait pas attention...
Je me sent mieux maintenant, tiens je remarque que j'avais marqué que j'étais inquiètE dans un message, une faute de frappe, c'est inquiet bien sur.. bon....
Pour l'ADO je vais regarder GetRows ca à l'aire intéressant, pour la connexion je vais tester aussi, mais j'ai peur de perdre en performance, merci pour le tuyau pour objDB.Errors.
A+
"jbongran" a écrit dans le message de news:4048ea16$0$290$
Non, car le fait de ne pas le faire à chaque page implique que d'une
manière
ou d'une autre l'objet de connection est soit dans l'objet Session ou Application, et ça c'est pas bien du tout ;-) D'ailleurs tant qu'on en est aux trucs en asp pour les bases de données, voici ce que j'ai pu constater : L'utilisation des méthodes GetStrings et GetRows et un réél plus pour récuperer des enregs (en gros il n'y a plus d'aller-retour entre le
serveur
web et la BDD entre chaque enreg), avec l'avantage de pouvoir fermer ET detruire le recordset tout de suite. Utilisation exclusive d'OLEDB Creation, ouverture, utilisation, fermeture et destruction des objets de connection sur chaque page. Une routine traitant et réinitialisant l'objet objDB.Errors peut avoir des effets surprenants (j'imagine que ce doit être en rapport avec
l'utilisation
de mémoire liée au stockage des messsages qui s'empilent)
Finalement j'ai repris tout mon code et regarder les endroits ou ca coince,
j'ai trouvé plein de petit truc a obtimiser et l'ensemble de ces corrections
m'a fait gagner énormément de performance je suis maintenant à moins de 21%
des resources processeurs sur mon serveur de développement et en prod (que
je viens d'installer) je suis à 5% :-)
Une page type est maintenant générée en 0.121 secondes au lieu de 0.350 sur
mon serveur de développement et en 0.066 sur mon serveur de prod :-))
Comme quoi on code, on code et puis on ne fait pas attention...
Je me sent mieux maintenant, tiens je remarque que j'avais marqué que
j'étais inquiètE dans un message, une faute de frappe, c'est inquiet bien
sur.. bon....
Pour l'ADO je vais regarder GetRows ca à l'aire intéressant, pour la
connexion je vais tester aussi, mais j'ai peur de perdre en performance,
merci pour le tuyau pour objDB.Errors.
A+
"jbongran" <jbongran@free.fr> a écrit dans le message de
news:4048ea16$0$290$636a15ce@news.free.fr...
Non, car le fait de ne pas le faire à chaque page implique que d'une
manière
ou d'une autre l'objet de connection est soit dans l'objet Session ou
Application, et ça c'est pas bien du tout ;-)
D'ailleurs tant qu'on en est aux trucs en asp pour les bases de données,
voici ce que j'ai pu constater :
L'utilisation des méthodes GetStrings et GetRows et un réél plus pour
récuperer des enregs (en gros il n'y a plus d'aller-retour entre le
serveur
web et la BDD entre chaque enreg), avec l'avantage de pouvoir fermer ET
detruire le recordset tout de suite.
Utilisation exclusive d'OLEDB
Creation, ouverture, utilisation, fermeture et destruction des objets de
connection sur chaque page.
Une routine traitant et réinitialisant l'objet objDB.Errors peut avoir des
effets surprenants (j'imagine que ce doit être en rapport avec
l'utilisation
de mémoire liée au stockage des messsages qui s'empilent)
Finalement j'ai repris tout mon code et regarder les endroits ou ca coince, j'ai trouvé plein de petit truc a obtimiser et l'ensemble de ces corrections m'a fait gagner énormément de performance je suis maintenant à moins de 21% des resources processeurs sur mon serveur de développement et en prod (que je viens d'installer) je suis à 5% :-)
Une page type est maintenant générée en 0.121 secondes au lieu de 0.350 sur mon serveur de développement et en 0.066 sur mon serveur de prod :-))
Comme quoi on code, on code et puis on ne fait pas attention...
Je me sent mieux maintenant, tiens je remarque que j'avais marqué que j'étais inquiètE dans un message, une faute de frappe, c'est inquiet bien sur.. bon....
Pour l'ADO je vais regarder GetRows ca à l'aire intéressant, pour la connexion je vais tester aussi, mais j'ai peur de perdre en performance, merci pour le tuyau pour objDB.Errors.
A+
"jbongran" a écrit dans le message de news:4048ea16$0$290$
Non, car le fait de ne pas le faire à chaque page implique que d'une
manière
ou d'une autre l'objet de connection est soit dans l'objet Session ou Application, et ça c'est pas bien du tout ;-) D'ailleurs tant qu'on en est aux trucs en asp pour les bases de données, voici ce que j'ai pu constater : L'utilisation des méthodes GetStrings et GetRows et un réél plus pour récuperer des enregs (en gros il n'y a plus d'aller-retour entre le
serveur
web et la BDD entre chaque enreg), avec l'avantage de pouvoir fermer ET detruire le recordset tout de suite. Utilisation exclusive d'OLEDB Creation, ouverture, utilisation, fermeture et destruction des objets de connection sur chaque page. Une routine traitant et réinitialisant l'objet objDB.Errors peut avoir des effets surprenants (j'imagine que ce doit être en rapport avec
l'utilisation
de mémoire liée au stockage des messsages qui s'empilent)
