Reprise du message précédent :
Bien vu !!
RyuJIT c'est plein de belles promesses (que je ne conteste pas !), mais de bugs aussi apparemment, celui-là est sympa. J'imagine le boxon incompréhensible que ça peut te mettre sur une plateforme de production

J'allais le poster  

Des gens ici qui sont déjà sous VS2015 ?  
Des impressions à partager ?
 
De mon côté je n'ai pas encore franchi le pas, je passerai bien au 2015 Community sur une machine où j'ai déjà un 2010 et 2013, mais je préfère attendre les retours sur la RTM (surtout pour ce qui est de la cohabitation, j'ai besoin du 2010 pour bosser et la flemme de passer par le scénario image disque et cie).

Perso j'ai 2010 et 2013 au taf, 2013 à la maison, ça se passe bien. ReSharper + NCrunch au taf, donc pas besoin de 2015 pour l'instant. Peut-être que je le mettrai un de ces 4 sur mon laptop mais pareil, j'attends quelques retours.

Il y a des tas de logiciels et sites en ligne très bien pour tester la sécurité et les optimisations possibles d'un site, mais je viens d'en trouver un très sympa spécialement orienté ASP.Net pour la sécurité : www.asafaweb.com

Pas mal du tout pour voir rapidement les points foireux d'un site web !

C'est génial les datetime en SQL et chez Microsoft.
Comme chacun sait, la valeur "min" change un peu selon le type et le SGBDR.
La constante équivalente en C# est SqlDateTime.MinValue soit le 01/01/1753, qui correspond au -53690e jour avant 1900, qui est pour SqlServer le jour 0.
Jusque là on s'en sort.

Sauf que je découvre que pour CommerceServer, au moins pour la partie Profile, qui ne gère pas les Nullable, la plus petite date est le 01/01/1754 .

Evidemment tous les tests sur SqlDateTime.MinValue font n'importe quoi.

Après décompilation, ça vient de UpmMembershipConstants.SqlMinimumDate.

Merci Microsoft  

Confirmé.
internal static DateTime SqlMinimumDate = new DateTime(1754, 1, 1, 0, 0, 0, 0, DateTimeKind.Local);
 
 

Y en a un qui a dû faire une boulette

On dirait. C'est pas avec ce genre de conneries qu'on me fera cesser de penser que Commerce Server c'est tout pourri
 
Et on s'étonne que le site sur lequel je bosse fasse des trucs bizarres parfois après

De toute façon le DateTime c'est tout pourrave, faut passer sur le DateTime2 (quand c'est possible).

Certes... Quand c'est possible .

Mais quel intérêt de faire du MinValue sur un DateTime ?

Faut croire que c'est l'équivalent du null pour certains, notamment dans le code préhistorique (pour rappel DateTime est un type valeur et le support des Nullable est venu avec .Net 2)

Je pense (j'ai pas d'exemple à proprement parler) que l'intérêt réside quand tu veux utiliser le null comme 3ème état.

Salut les gars
 
Bon j'ai un probleme de performance sur un site en prod et j'arrive pas a trouver le probleme
 
 - J'expose la situation :
Une page est chargee et fait 3 call ajax en get. Retourne le resultat venant d'une procedure stockee avec differents parametres.
Executee directement via SSMS la procedure stockee prend entre 70ms et 250ms
(Stack: MVC + EF6 + SQL Server )
 
 
Procedure de test (En ciblant la meme base de donnee de prod)
 
Site PROD
- Les 3 calls prennent un temps aleatoire entre 4sec et 10sec    
 
Copie du site en Prod sur le meme serveur, mais dans un autre site IIS
- Les 3 calls prennent un temps aleatoire entre 400ms et 700ms
 
Site en integration (Un serveur de test)
- Les 3 calls prennent un temps aleatoire entre 100ms et 300ms
 
Une idee ?
J'ai lancer performance monitor sur le serveur de prod
WebService/Current Connections: entre 50 et 120 (average de 75)
% Processor time: en moyenne 10%
 
 
Je sais plus vraiment ou regarder ou quoi faire.  Le site en lui meme se charge vite, les pages apparaissent vite, mais ces Request en GET prennent des plombes ca n'a aucun sens
 
 
 

Et les dev tools de ton browser (FF ou Chrome), ils disent quoi en termes de perfs ? Y a des erreurs, des requêtes qui sont retentées 150 fois ? Taille des objets qui transitent peut-être ? Typiquement ta proc stock sur ton serveur de test retourne 100 lignes mais sur un jeu de données de prod t'en manges 150 000 -> gros temps de traitement côté serveur + grosse taille de données à télécharger par le client.
Les 10% de CPU sont pas anodins : si ton serveur est un quad-core avec hyper-threading, t'as 8 coeurs logiques. 1 coeur à 100% CPU = 12.5% d'utilisation totale. Donc t'aurais un traitement important côté serveur.

 
- Les temps indiquees viennent de chrome tool et Glimpse (meme resultat) sur des dizaines d'essais en live
- Je target la base de donnee de prod sur les 3 cas, ce qui me permet d'eliminer le facteur DB
 
C'est pour ca que je suis un peu perdu la

J'avais pas fait gaffe au 2ème point. Ba cherche pas, c'est ton IIS qui chie dans la colle. T'as tenté un redémarrage en règle du service IIS ? Tous les application pools seront indispos mais bon. Idem avec un redémarrage du serveur.
Je dis ça j'en sais rien mais bon, ça se tente

 
 
C'est ce que je pensais aussi, c'est pour ca que j'ai creer un autre site sur le meme serveur IIS et deployer l'application dessus
 
Donc en gros sur le meme IIS de prod j'ai SITE1(L'original) et SITE2 (le nouveau)
 
Et bien SITE1 (Accessible par nos utilisateurs), toujours le soucis de requetes qui prennent plusieurs secondes  
SITE2: Requetes rapides mais personne connecter a part moi
 
Tu vois le truc
 
 
 

Ce que je pense, mais je me trompe peut-être:
- tu dois probablement récupérer beaucoup de lignes et faire beaucoup de travail dessus côté applicatif
- Le premier site étant "chargé", il doit faire le taff et gérer les priorités par rapport aux autres requêtes des autres utilisateurs
- Le second site étant "vide", il a le temps de faire le job tranquillou.
 
Tu as les mêmes propriétés de configuration (pool, etc.) sur tes 3 sites ?

 
Oui meme configuration de l'application pool (un pool different par site)
De plus j'utilise la meme connection string pour les 2 sites.  
 
Par contre ce que je ne sais pas, c'est si SQL Server est capable de detecter que les requetes ne viennent pas du meme site, meme en utilisant la meme connection string.

Tes 3 get sont gourmands à la base ?
(c'est pas parce que c'est gourmand que ça ne répond pas vite)

 
Les get font un apelle a une procedure stockee. Quand j'execute la procedure stockee directement via SSMS elle prend 100/150ms environ (d'ou les temps d'executions bas dans les 2 autres cas de figures)
 
Apres peut etre que t'as une autre definition de gourmand, si c'est le cas, pourrais tu preciser ?
 
Merci

Ben elles font quoi tes procédures ?
Çà récupère des éléments ? Si oui, beaucoup ?
Ou bien ça fait juste des actions côté serveur SQL ?
 
Tu fais rien d'autre côté applicatif ?

 
C'est une procedure qui recupere des infos baser sur le profil de la personne connectee:
 
Y'a multiples jointures etc.. ca attaque 4 ou 5 tables avec un filtre de date et au final ca retourne une dizaine de resultat (apres un distinct)
 
C'est pas un select d'une ligne sur une seule table, mais c'est pas non plus une requete de malade.
 
Non le code behind ne fait rien d'autre que recuperer les 10 lignes, les mapper a un business object et retourner ca a la vue (l'objet est petit, 6 ou 7 proprietes)

Je pense que je vais attendre apres le boulot, eteindre le site, bloquer l'acces exterieur et etre le seul sur la plateforme voir si les performances tombe au meme niveau que l'execution local
 
Ca me permettrais au moins de determiner si le probleme, un un probleme de charge

Bon ben comme ça je ne vois pas.
Tu es sûr que ce sont les appels des procédures qui prennent du temps ?
Si tu as SQL profiler tu peux voir ce qui est balancé à SQL et combien de temps ça prend

Gaffe aux jointures, faut les faire sur des champs indexés ou des clés.
DISTINCT c'est mal pour les perfs, essaie de mieux gauler tes joins pour pas avoir de doublons.
 
Si t'as 100 utilisateurs qui accèdent au truc, ba c'est là que tu prends tes 10 secondes (bon je schématise mais c'est l'idée). Mate le plan d'exécution de ta proc, SQL Server est bien foutu pour ça. Si t'as des table scan, c'est probablement un pb d'index ou de clé sur tes joins. Si c'est le sort de ton distinct qui fout la merde, teste la requête sans le distinct. Fais ta requête mieux que ça ; au pire tu feras le distinct en LINQ côté serveur.

Ben il dit utiliser une procédure stockée. Donc s'il balance les même paramètres quelque soit le site et même via ssms, ce n'est pas un souci de la db.

Une proc qui récupère des infos sur le profil d'un user, si t'as 100 users qui la tapent en même temps avec des params différents (ba oui, 100 users = 100 profils différents donc params différents ne serait-ce que l'ID user), ça peut venir de là.
Après j'en sais rien, je donne des pistes. Perso j'avais eu un souci similaire ; une proc qui prenait 300 ms sauf qu'elle était appelé 100 fois lors d'une action "bulk" (la même action sur 100 objets différents) => 30 secondes dans la tronche du user. J'ai ramené le temps de requête à 100 ms et hop, 10 secondes, les mecs étaient contents.
Donc c'est une piste, après il a p'têt que 3 users en prod, on sait pas

Non ça ne peut pas, sinon il aurait le même problème sur l'autre site vu que ce serait SQL le goulot d'étranglement d'après ce que tu dis.

Ah oui merde, t'as raison.

lol vous venez d'avoir la discution qui m'a amener a poster ici
 
Donc j'attend ce soir si jamais une fois seul sur le serveur je tombe a des timing de l'ordre des 200ms ca voudrais dire que ca viens bien d'un probleme de traffic important.
Dans ce cas la, je pense que ca doit venir d'un probleme avec Entity Framework qu dois avoir du mal a gerer les connections, qui les accumule jusqu'a ce qui y'en ai plus assez, donc ca fait un genre de queue
 
Pour l'instant c'est la seule chose que je puisse imaginer

Bon j'ai des news donc j'aurais besoin de votre avis:
 
J'ai fermer l'access au site pour me retrouver seul a seul avec cet enfoirer
 
Je lance une serie de load stress test    qui repete un scenario sur le site, en particulier sur la dite page qui pose probleme.
 
Et la c'est le drame    
 
Au bout d'une minute au fur et a mesure que la charge monte, la dite page ne repond pratiquement plus, ca passe de 4sec a 30sec puis 1min etc.. puis plus rien
Par contre les autres page du site continue de repondre correctement
 
La je me dis ma requete est si pourrie ?
Alors hop en meme temps j'ouvre la copie de mon site hoster sur le meme serveur, et ca fonctionne parfaitement    
 
 
Donc je me dois d'opter pour une seconde strategie:
 
Je remplace la dite procedure stockee par un une requete LINQ toute simple qui renvoie le meme type de donnee dans la meme quantite.
Je relance un stress test encore plus puissant
 
Et la   tout vas bien l'appli et le serveur reponde parfaitement, juste un micro ralentissement qui se ressent a peine
 
 
Donc la je suis un peu paumer:
 
1 - Pendant le 1er load test sur le SITE1 dont la dite page tombe KO en quelques secondes, le SITE2 (copie du site 1 sur le meme serveur) continue a repondre normalement, ainsi que les autres pages du SITE1
=> Ma conclusion la base de donner tiens le coup  
 
2 - Pendant le 2nd load test avec la fausse requete sur le SITE1, tout fonctionne a merveille sur SITE1 et SITE2 tout le long du test
=> Ma conclusion le serveur web ne pose pas probleme
 
=> Donc mon hypothese (et j'en suis pas sur du tout) :  
EF6 aurait du mal a gerer les ouverture/fermeture de connection a la BDD en appellant une procedure stockee complexe provoquant un engorgement des appels ?
Faudrait que je trouve une maniere de pouvoir tester ca et verifier
 
Mais ce probleme commence a bien me faire chier, d'autant plus que la fameuse page problematique est la page d'accueil  

L'ouverture de la connexion à la db se fait pour chaque requête http ou tu la monopolises quelque part ?

Je débarque à la fin de la conversation mais ça sent le problème de concurrence, donc en mono utilisateur ça tourne bien, en multi ça bloque.
Ca peut être à plusieurs niveaux :

Soit tes appels en base ne peuvent se faire que séquentiellement, soit c'est dans le code que ça bloque (si tu as mis en place une gestion de la concurrence, genre pour un cache), soit c'est tes accès à la base.

Questions en vrac :
Ta SP elle fait bien juste un select ?
Pas de transaction foireuse qqe part ?
La SP ne se ramasserait elle pas elle même un lock à cause d'un AUTRE traitement coûteux qui tournerait en // avec une transaction trop longue, qui du coup bloquerait l'accès à la base pour ton select ?
On peut voir ta connection string ?
Tu accèdes comment à tes objets en base (code instanciation EF + appel + dispose) ?
Pas de Close/Dispose oublié dans un coin ?
Comment tu gères le cycle de vie de ton EF context ?
Et de ta connexion (persistante ou pas, etc) ?
N'oublie pas : un DbContext / ObjectContext / DataContext est un objet disposable (enfin, surtout sa connexion), si on ne le liquide pas après traitement, il te pourrit le système.
Si tu peux bidouiller le code tu peux essayer de coller des Stopwatch + log à quelques moment significatifs du traitement ? Notamment juste avant/apres appel à la BdD, et à la réception / réponse de la requête http.
En local avec un outil de web stress genre jmeter tu peux reproduire le pb ? (histoire de ne plus torturer la production).

Ce n'est pas le cas, sinon y aurait le même problème sur les autres sites (la concurrence étant côté DB).

Pour le reste, je suis du même avis que toi, il faut qu'il nous en dises plus sur l'instanciation et le cycle de vie de son context, etc.
Et effectivement, JMeter est un excellent outil de stress.
J'ai aussi pensé au stopwatch, mais s'il ne peut pas modifier son code qui est en prod, autant qu'il essaie d'abord de reproduire via jmeter sur un serveur local.

C'est pour ça que je lui disais de faire ses tests en local si possible pour ne plus bidouiller en prod. Pour ton autres remarque ("il y aurait le même problème....." ) je n'ai peut être pas tout lu attentivement mais si les conditions de tests ne sont pas les même qu'avec des "vrais" utilisateurs c'est possible qu'il n'ait pas mis le souci en évidence lors des autres tests.
Je pense que le goulot est côté DB vu le comportement observé mais on ne l'a pas encore prouvé.
D'où le fait avant tout d'arriver à reproduire le truc et sans impacter la prod.

Tu devrais relire, le goulot n'est pas côté DB

J'ai été ambigu ci-dessus mais je pense que toutes mes questions précédentes sont claires. Juste ci-dessus je voulais dire "côté DB ou accès DB" si tu préfères comme ça. Pas sur la stack http/réseau/client quoi.