Reprise du message précédent :
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.

Ok on est d'accord

 
 
Salut les gars
 
Bon la c'est le weekend  donc je regarderais le code pour la gestion du context des la reprise du boulot, mais sinon:
 
- Oui j'ai eut la meme sensation que vous que ca peux venir du DbContext qui ne serais pas nettoyer correctement apres chaque appel. On utilise Ninject pour ca, je me souviens plus quel option on a mis sur le Bind. D'ailleurs quelle serais le meilleur scope pour le DbContext (Thread, Request, Transient etc..)
 
- Non pas de transaction dans la SP, ni avant, ni apres. C'est un select oui, mais pas un truc de 1 ligne. Y'a des jointures etc..
 
Mais le simple fait que le probleme ne se soit pas reproduit en remplacant l'appel a la SP par une simple requete LINQ a mon model EF, qu'est ce que ca sous entend ?
La gestion des connections des appels de SP seraient t-il gerer differement par EF ?
 
edit: Ca me donne une petite idee, et si je remplacais le contenu de ma SP par une requete plus legere. Parceque dans ce cas la, si ca continue de foirer c'est que j'ai un probleme avec la gestion des connections, sinon c'est que ma requete ne scale pas

Pour un site web, j'utilise le scope de la requête http pour la durée de vie du dbcontext.

Pour le reste je n'ai pas trop de piste. Je ne vois pas pourquoi il gererait les connexions différemment.

J'ai une question un peu tricky sur IIS et ASP.Net :

Je développe pour une boite qui hoste dans IIS 7 tous ses sites en http (port 80) et qui les sert en https via un load balancer/proxy qui ajoute l'encryption et tout le bordel qui va avec le https (certificats).

Donc l'inconvénient c'est que IIS travaille en http, certains trucs comme HttpContext.Request.IsSecureConnection ne sont donc pas utilisables (évidemment).
Pareil pour les bindings WCF, c'est un peu le bordel (mais je digresse).

Ma question :
Je dois flagger les cookies comme .Secure=true, vu qu'on fait du https du point de vue du client.

Comme toute la partie "serveur" est faite en http, savez vous
- s'il va bien vouloir de mon flag Secure et tout tournera bien ?
- Il n'en tiendra pas compte et continuera de me faire du cookie pas Secure ?
- Ca va me péter joyeusement à la gueule parce que le code demande un truc que le hosting ne pige pas ?

Vu qu'on a aucun moyen de tester ce genre de trucs avant les mise en prod (cette conf bizarre n'existe qu'en prod vu qu'il n'y a que là qu'on a le load balancer, et les MEP sont un processus horriblement long et compliqué géré par d'autres), j'essaye de voir à l'avance si quelqu'un connait ça pour savoir si ça va réagir comme espéré.

Merci

 
Bon on a fini par remplacer la procedure stockee par une requete LINQ (Lambda)
On a remplacer les 3 appels, par un seul qui renvoie un objet qui combine les 3 reponses
 
Et ca a calmer le probleme, sans totalement le resoudre, en gros au lieu d'etre constamment a 4 ou 6sec on est tomber a 2sec, meme si le resultat parfait devrait etre 700-900ms
 
Donc on s'est arreter la, on va monitorer en attendant, en tout cas merci pour vos reponses, et c'est la qu'on voit a quel point l'utilisation d'un ORM peux te mettre dans des situations ou tu ne sais pas ce qui se passe sous le capot

Et encore tu as l'air plutôt vigilant.
J'ai des collègues (en Java) qui ne se posent même pas la question, une confiance aveugle à l'orm, ça peut faire 50 requêtes voir 100 de plus parce la méthode de DAO se trouve dans une boucle. Ils pensent faire de la POO mais derrière ça bombarde la Db..
C'est d'une tristesse.

chez le client où je suis en ce moment, on a des requêtes de plusieurs milliers de lignes générées par NHibernate... Et il s'étonne des problèmes de perf (ahhh, les banques...)

Je trouve que les requêtes générées par l'EF sont en général efficace pourvu qu'elles soient BIEN écrites en respectant quelques règles.
Les requêtes complexes (agrégats, sous requêtes...) sont en général plutôt bien générées et on peut faire énormément de choses (eager loading multi niveau par exemple) moyennant de maitriser l'outil et réfléchir un minimum.
Ca lui arrive de générer de la daube mais en réécrivant la requête autrement on peut arriver à nettement mieux. En règle général il faut essayer d'écrire ses requêtes comme on l'aurait fait en SQL plus que comme en "objets" pour avoir un truc bien.
Genre : http://stackoverflow.com/questions [...] s/32745360
 
NHibernate par contre ...
 
A part ça personne ne sait répondre à ma question IIS ?

+1
J'ai trouvé l'EF pas trop mal fichu. Et couplé à Linq c'est très efficace.
Il "suffit" de bien comprendre quand le serveur de BDD est interrogé et quand il ne l'est pas encore pour avoir de base de bons résultats.
Un peu d'optimisation ensuite et c'est pas trop déconnant pour un ORM.

 
Pour moi je dirais que c'est good.
Le client ne fait que du https du coup le navigateur transmettra ses cookies flaggés comme secure sans se poser plus de question.
 
Après faudra quand même peut-être prévoir un roll-back  
 
Quand je dois mettre en prod une fonctionnalité un peu tricky non testable hors environnement de prod, je rajoute un booléen dans la config qui gère l'utilisation ou non de la fonctionnalité.
Comme ça si c'est KO hop je la désactive et les autres évol restent en place. Et si c'est OK je vire le mécanisme de bypass pour la prochaine livraison.

Ouais c'est le truc évident mais j'avais pas envie de rajouter ça (si tu voyais comme la conf et le code sont déjà bien pourris tu comprendrais). Si j'ai un doute je mettrai un truc du genre "si la clé existe, désactive le bidule, si la clé n'existe pas du tout, fais comme si de rien n'était". Comme ça c'est juste du code, pas de modif de conf.

Honnêtement je ne sais pas concrètement ce que le serveur web fait de ce flag Secure, c'est pour ça que je me demandais ce que ça allait faire .
Merci

Resharper 10 est sorti
http://blog.jetbrains.com/dotnet/2 [...] te-10-rtm/
Et tout ce qui vient avec : dotTrace, dotMemory, dotPeek...
 
En cours de DL

Ma boite ne voudra jamais migrer

Moi j'ai une souscription valide, les MAJ sont incluses même vers les versions majeures tant que c'est le cas.
Par contre leur nouveau système de licence a l'air contraignant, je suis content d'avoir pu profiter de la v10 dans ma période de validité.

edit : install finie à l'instant

Mais c'est même pas un souci d'argent. C'est un problème de paperasserie, d'administratif, de faire la demande à la bonne personne qui doit remonter à qui de droit avec en copie les gens qui faut en précisant le pourquoi on a besoin pour pouvoir passer au service achat qui demande au service audit de ....  
 

 
Tu nous diras ce que t'as trouvé comme nouveautés sympas.

 
Dites nous de quoi vous avez besoin, on vous expliquera comment vous en passer !

Bin les nouveautés sont décrites sur la page et perso je trouve pas ça révolutionnaire.
Je crois qu'on bosse dans la même boîte, on a la 8.2.1 et NCrunch et franchement on peut pas se plaindre. Passer à la 9 serait intéressant, ne serait-ce que pour le support VS 2015 et C# 6, mais j'en ai pas besoin tous les jours Les fonctionnalités cruciales sont là, NCrunch rajoute ce qu'il faut pour tabasser les tests en temps réel, pas besoin de ReSharper 10

Ah c'est clair, d'une version à l'autre y a rarement de révolution. La motivation principale c'est souvent le support d'une nouvelle version de VS lorsque le pb se pose.

Mais y a quand même des boites avec une politique aberrante à ce niveau. Y a deux ans j'ai fait 3 mois à maintenir un truc bien merdique chez un client qui était sous VS 2005 et pas de R#. J'ai fait le forcing pour la migration à VS2008 (ouaaah!!) mais pour R# c'était niet.
Pourtant le truc aurait coûté à l'achat nettement moins que ce qu'ils auraient économisé en charge humaine...

Mais y a appuyé sur tab?

T'aurais au moins pu attendre une minute ou deux que l'édit arrive

burned is burned

Pour l'instant je regrette limite d'avoir upgradé, l'intellisense est devenu inutilisable, car beaucoup trop long à réagir (plusieurs secondes à chaque fois que je tape un truc, sous VS2010 qui tourne sur un i5 avec 8Go de RAM pour un gros projet) là où avant il fonctionnait correctement.

J'aurai du attendre que des cobayes débuggent le truc  

Merci de faire le cobaye pour nous

Déjà que je trouve que la version précédente est gourmande, je ne suis pas spécialement prêt à migrer de suite.

Je vous confirme que vous feriez bien d'attendre.
J'ai fait des reports à jetbrains, on verra bien, en espérant qu'ils ne mettent pas 2 mois à sortir un correctif.
Dans mon cas sous vs2010 l'intellisense est carrément inutilisable sur mon plus gros projet et VS super ralenti + cpu en fusion, donc je ne dois pas être le seul emmerdé...

Resharper 10.0.0.1 dispo : https://www.jetbrains.com/resharper/download/
On va voir si ça devient réutilisable  
Ca a été rapide, mais en tout cas je me souviendrai que Jetbrains utilise clairement ses clients payants pour le bêta test de leurs nouvelle version ...

C'est pas devenu follement rapide, mais apparemment le pire a été fixé, même sur mon mega gros sln où R# était devenu inutilisable il y a quelques jours la situation s'est nettement améliorée .
A peu près du niveau de la 9.
En plus avant j'avais un CSS (genre 7000 lignes, oui un seul fichier ) qui ramait et faisait planter R#, maintenant il se contente de ramer .

bon, je vais m'en passer alors
 
Les outils "qui font gagner du temps" mais qui ralentissent les actions courantes, j'en peux plus....

T'es sur une release précédente ou tu t'en passes totalement ? Moi ça fait bien 8 ans que j'en suis un grand fan. Même si petit à petit VS (et qqes plugins) ont introduit nativement des fonctions à l'origine dans R#, ça reste quand même un super outil.
Sur des projets pas trop énormes c'est très utilisable.

Par contre évidemment faut désactiver les fonctions horribles comme le Wide Solution Analysis.

Ah non mais ReSharper 8 ou 9 c'est ultime, perso je pourrais pas faire sans. J'ai des classes de 8000 lignes, ça rame bien mais sans ça vas-y pour refactorer...

Voilà c'est aussi mon ressenti  
Même si j'essaie d'éviter les classes de 8000 lignes .

Pareil, je suis fan de R#.

Pas mieux, c'est vraiment un vrai + (quand ça fait pas ramer tout le bouzin)

R# 10.0.2 sorti hier : http://blog.jetbrains.com/dotnet/2 [...] te-10-0-2/
Bcp de bugfixes sur des trucs mineurs (hormis la partie tests unitaires, faut dire la marge de progression est importante ), 0 features, donc pas de quoi s'exciter à première vue.

c'est un Datagridview dans un groupebox, dans un spliter, dans une form, mdichild d'une autre form

dés que les controles se retrouvent a en bas de mon ecran j'ai cet effet ( au dela d'environ 850 pixels ), meme chose pour d'autres controles du genre graph ...

Avez vous une idée de la cause ?  

c'est un Datagridview dans un groupebox, dans un spliter, dans une form, mdichild d'une autre form

C'est clair que ce genre de trucs n'aide pas .
En winform j'ai parfois eu des bugs désagréables lorsque que j'avais des contrôles imbriqués d'une façon qui ne lui plaisait pas trop. Dans ce cas j'essayais de simplifier l'arborescence et surtout vérifier que les appels à des trucs comme Application.EnableVisualStyles() étaient bien faits sinon t'as des contrôles qui déraillent sévère .

Tu surcharges les méthodes de dessin de tes contrôles ou tu fais juste du binding ?
Ca le fait sur tous les postes/environnements ou il y a des cas particuliers ?
Si tu sors le DGV du groupbox/ du splitter ça aide ?

https://www.youtube.com/watch?v=MVFWaHFGXi4

Voici une video du pb, je ne fais que du binding. le truc qui n'a aucuns sens est que ca marche entre les pixels 0 a environ 850 ou 900 de l'ecran, et pas au dela
le pb semble etre present que sur les poste ou la reso est en full Hd ou plus.
d'apres mes tests le pb est la que pour les forms child (avec ou sans controles imbriqués, avec ou sans groupbox/splitter)