florianh78 10 Geschrieben 12. März 2012 Melden Teilen Geschrieben 12. März 2012 Hallo zusammen, auch wenn die im Titel gelisteten Scripting-Technologien natürlich unterschiedlich mächtig sind, so würde mich doch mal ein Vergleich von Performance (Laufzeit) und Ressourcenverbrauch einer Lösung X interessieren. Anders und grober formuliert: Sind mit der Mächtigkeit dieser Technologien auch Ressourcenverbrauch und Laufzeit gestiegen, gleich geblieben oder sogar gesunken? Die Frage ist natürlich sehr unspezifisch, weshalb es vielleicht nur subjektive Meinungen/Erfahrungen zu berichten gibt - Aber auch das wäre hilfreich! Hintergrund meiner Frage ist die Implementierung diverser Monitoring-Checks, also von Skripten, deren zyklisches Anlaufen einen möglichst geringen Einfluß auf das Gesamtsystem haben sollte. Bringt hier die Wahl von Batch-Skripten einen nennenswerten Vorteil, der es rechtfertigen würde, sich auf diese beinahe Assembler-artige Codestruktur einzulassen? ;) Bin gespannt! Viele Grüße Florian Zitieren Link zu diesem Kommentar
PowerShellAdmin 169 Geschrieben 13. März 2012 Melden Teilen Geschrieben 13. März 2012 Also ich hatte per ps verschiedene Schleifen und adsi Aufrufe, nach dem ich die Ad-Attribute nativ per Ps ausgelesen hatte war das ganze Faktor 30 schneller ( bei 2000usern). Generell sind die Cmdlets von der Performance sehr angenehm. ich setze nicht mehr auf Batchs- die Signierung ist ebenfalls einweiterer Vorteil in grossen Firmen und bietet mehr Sicherheit. So ganz vergleichen kann man es nicht, da die ps ein Admin Werkzeug ist und man vieles per Batch so nur umständlich oder nicht kann. Grüße Admin Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 13. März 2012 Melden Teilen Geschrieben 13. März 2012 Moin, so pauschal kann man das selbstverständlich nicht beantworten. Es hängt immer davon ab, was man konkret macht und wie man das tut. Grundsätzlich wird eine Aktion mit einem Allzweck-Werkzeug tendenziell weniger "sparsam" sein, weil das Werkzeug ja nicht vorab weiß, was es tun soll und welche Daten dafür tatsächlich nötig sind. Gerade die PowerShell etwa erzeugt in manchen Fällen sehr umfangreiche Objekte, auch wenn es nur einen Brruchteil von deren Daten braucht. Da kann der Aufruf z.B. eines binären (bzw. gezielt entwickelten und kompilierten) Tools, das tatsächlich nur die gewünschten Daten nutzt, wesentlich schlanker sein. Solche Fragen stehen beim Scritping i.d.R. aber auch nicht im Vordergrund, weil es da ja gerade um maximale Flexibilität und schnellen Aufbau einer Lösung geht. Gruß, Nils Zitieren Link zu diesem Kommentar
Dukel 454 Geschrieben 13. März 2012 Melden Teilen Geschrieben 13. März 2012 Wir haben ein selbst entwickeltes Monitoring auf Powershell Basis. Um keine Probleme während der Laufzeit mit Anwendungen zu bekommen starten wir das Script mit der niedrigsten Priorität. Wenn es um Laufzeit und Ressourcenverbrauch geht ist, wie schon geschrieben, eher eine Programmiersprache sinnvoll und keine Scriptsprache. Zitieren Link zu diesem Kommentar
PowerShellAdmin 169 Geschrieben 14. März 2012 Melden Teilen Geschrieben 14. März 2012 Und da liegt eben nicht der Anwendungsbereich, PowerShell ist grundlegend ein administratives Werkzeug. Allerdings kann man hier mit z.B. einfache Monitoringlösungen, oder auch umfangreiche Skripte schreiben um Windowsbenutzer einzurichten. Im Regelfall sind das alles aber auch Ausführungen, die bei Bedarf stattfinden, können aber auch ohne großen Umstand als Routine geschrieben werden - hier muss man die Skriptstruktur einfach entsprechend lösen. Microsoft wird die Powershell perspektivisch auf allen Produkten zum vollständigen Management führen, so wie es ein Anfang mit dem Exchange 2010 war.Zusätzlich gibt es mittlerweile eine Fülle an Modulen von Drittanbietern. Das heißt man hat dann folgenden Aufbau Management setzt vollständig auf PS Befehle und gibt so indirekt die Einstellungen an das eigentliche Programm weiter. PowerShell führt die Aufrufe aus Core Derzeit deckt die PS bei den meisten MS Produkten nur ein Teil des Cores ab. Der Exchange Server entspricht aber z.B. den obigen Aufbau. Es ist meiner Meinung nach auch keine Konkurrenzfrage zu Batch, die PowerShell hat diese nun einmal abgelöst, sollte man keine komplexeren Skripte benötigen kann man natürlich noch ausweichen .... aber meistens ist es per PS einfacher. Ich möchte auch nochmal den Sicherheitsaspekt ansprechen, man kann PowerShell Skripte mit einem Code3 Zertifikat signieren. Der Vorteil: Soweit die Clients Ausführungsrichtlinien richtig konfiguriert haben, wird der Skript nur ausgeführt, solange der Zertifikatsanbieter vertrauenswürdig, das Zertifikat gültig und der PowerShellcode noch original ist. Gerade für strenge Richtlinien sehe ich das zumindest als erhebliche Verbesserung- ich weiß aber an der Stelle nicht ob das auch so einfach mit einer Batch oder VBS geht, ist mir nicht bekannt. Ein Beispiel: Wir haben ein WorkflowTool in dem neue Mitarbeiterdaten gesammelt werden, diese werden in eine entsprechende SQL Datenbank geschrieben. Dort haben wir entsprechende Tabellen. Die PS schaut alle 15Minuten per Windowstask ob hier ein neuer Mitarbeiter angelegt werden soll. Die SQL Abfrage ansich kostet nahezu 0 Rechenleistung, erst das anlegen (soweit der Flag aktiv ist) führt zum eigentlichen Vorgang. Der Skript ist am Ende 600Zeilen lang und kostet trotzdem nicht allzuviel Zeit. Viele Anforderung lassen sich EINFACH per PowerShell lösen und es ist kein komplexe Entwicklung notwendig. Gerade der AD Zugriff per Shell ist zügig, da ist Adsi kein Vergleich. viele Grüße Admin PS: Mit Windows 8 Server wird sich da auch einiges Ändern, hier kommt die Power Shell Version 3, außerdem wird der 8er Server bestenfalls per Core verwaltet. Daher ist die Shell damit womöglich dort ein fester Standard - gibt leider noch keine Bücher bzgl. WinServer 8 Administration - best Praxis... warte aber schon gespannt drauf :) PPS: Und bitte nicht den Remotezugriff vergessen, der ebenfalls Bestandteil der PS ist Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.