[François Jehl] : Montée en charge, quelques conseils.

Publié par Fabrice Michellonet sous le(s) label(s) le 27 mai 2009

Dans son billet [SSIS] Montée en charge, quelques conseils. François, nous propose quelques très bon conseils d'optimisation des packages SSIS.

Pour une fois qu'il ne parle pas de Data Mining (quelqu'un comprend ce qu'il raconte au moins sur le DMX), je vais me permettre d'intervenir/compléter sur un point. J'espère que ca ne te dérange pas François.

François à dit :

... SSIS est optimisé en mémoire donc à vous de l'économiser! Déjà, sélectionnez uniquement les colonnes utiles...

Dans les Data Flow Sources, il est effectivement conseillé de ne sélectionner que les colonnes qui seront effectivement utilisées par la suite. Cependant, dans la suite de votre flux de données, certaines transformations (ex : Derived Column, Data Conversion etc...) vont dupliquer les colonnes les premières ne servant vraisemblablement plus.

Une solution souvent mise en place afin d'enlever les colonnes inutiles, est d'utiliser la tache Union All. En supprimant les Output Column inutiles, on pense réduire à juste titre la mémoire utilisée. La pire solution, serait d'utiliser des taches synchrones aggregate ou sort pour supprimer ces mêmes colonnes.

Mais alors si je conviens que cela réduit bel et bien l'utilisation de la mémoire, pourquoi n'est tout de même pas une bonne idée? Tout simplement de par le fait que supprimer une colonne induit la copie des buffers du pipeline vers de nouveaux buffers. Et malheureusement l'expérience prouve que cette action de copie est bien trop couteuse en terme de cycle CPU pour contrebalancer la réduction de la mémoire utilisée.

Darren Green - 10 Mai 2007 à dit :

Something that people, including me get a bit worried about, is the fact that you end up with these big wide buffers. The classic scenario is when you need to convert between string and Unicode string or visa versa. You end up duplicating all your columns, which seems really horrid. Well it may not be great, but the alternative is even worse. Data Conversion and Derived Column transforms can do the conversion, but are synchronous, so we have duplicate columns in effect. Would it be better to have a custom component that worked asynchronously, so you didn't end up with two columns for all your strings? The short answer is no. I wrote a test component, cunningly named DeUnicodeAsynchTestComponent, and simply put it was 2 - 2.5 times slower than a data conversion transform. The cost of copying data between buffers for the asynchronous nature is far more expensive than the extra baggage of the "duplicate" columns.

Voila François, j'espère que cette petite précision intervention ne te dérangera pas trop... promis je te laisse tranquille tant que tu parle de Data Mining.... Quand à moi, je retourne à mon code C#.

Mono.Cecil : la reflexion sous stéroïdes.

Publié par Fabrice Michellonet sous le(s) label(s) le 12:04

Dernièrement en étudiant les possibilités offertes par T4 (un prochain billet y sera consacré), j'ai été confronté une fois de plus a un problème bien connu de la Refection : L'impossibilité de décharger un assembly de l'AppDomain l'ayant chargé; La seule solution étant de décharger tout l'AppDomain.

Dans mon cas, l'AppDomain chargeant l'assembly était hosté par Visual Studio, ma seule solution était donc de fermer Visual Studio 2008... sniff sniff un peu violent!

En fouillant mes bookmarks non traités, je retombe sur Mono.Cecil, un Framework d'introspection écrit par Jean-Baptiste Evain.

Qu'est ce que Mono.Cecil? Je dirais que c'est de la reflexion sous stéroïde car non soumis aux mêmes limitations que la reflexion, et qu'en prime on peut aussi créer/modifier du code CIL avec.

Alors comment choisir entre les deux ? Je vous laisse découvrir l'excellent article Mono.Cecil vs. System.Reflection de Patrick Smacchia un des auteurs de NDepend

Pour ne pas déroger à la règle un petit bout de code afin de mettre le pied a l'étrier.


AssemblyDefinition myLibrary = AssemblyFactory.GetAssembly("MyLibrary.dll");

foreach (TypeDefinition typeDef in myLibrary.MainModule.Types){
if (!typeDef.IsClass)
continue;

Console.WriteLine(typeDef.FullName);
}

Bonne introspection.

SMDBehavior

Publié par Fabrice Michellonet sous le(s) label(s) , le 8 mai 2009

Lors des deux derniers billets, je vous ai présenté les possibilités offertes par le format SMD (simple method description) qui n'est autre qu'un JSON permettant de décrire un service web tout comme wsdl le fait en xml.

Pour rappel, certain Framework Ajax comme Dojo et Yahoo UI, savent interpréter ce JSON et généré automatiquement la classe proxy qui permettra de travailler facilement en Javascript avec les WebService.

Bref, tout ca pour vous annoncer que j'ai dernièrement travaillé sur une extension WCF qui génére automatiquement le SMD de vos services; et que le fruit de ce travail est disponible sur Codeplex à l'adresse suivante : SMDBehavior.

Evidemment, pas besoin de modifier vos services, il suffit d'ajouter quelques lignes de configuration dans le fichier web.config ou app.config pour que cela fonctionne.

Sur le site du projet SMDBehavior vous pourrez télécharger le binaire, une solution de démo et si vous avez un identifiant Codeplex, vous pourrez aussi obtenir les sources. Je ne m'étendrais pas ce soir sur la mise en oeuvre de cette extension WCF, car tout est explique sur la page SMDBehavior.

Happy SMD.