9
LDAP Last generieren
Tool das wie ein Lastgenerator funktioniert
Hallo zusammen,
ich suche ein Tool oder eine einfache Lösung die es mir erlaubt n/LDAP anfragen pro Stunde zu machen um einen Server zu Testen. Es handelt sich hierbei nicht um einen Windowsserver sondern um eine Telefonanlage mit integriertem LDAP. Kennt jemand so etwas oder hat eine Idee wie man etwas in der Art machen kann?
Gruss
Jean-Pierre
ich suche ein Tool oder eine einfache Lösung die es mir erlaubt n/LDAP anfragen pro Stunde zu machen um einen Server zu Testen. Es handelt sich hierbei nicht um einen Windowsserver sondern um eine Telefonanlage mit integriertem LDAP. Kennt jemand so etwas oder hat eine Idee wie man etwas in der Art machen kann?
Gruss
Jean-Pierre
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 123317
Url: https://administrator.de/contentid/123317
Printed on: April 19, 2024 at 18:04 o'clock
9 Comments
Latest comment
wenn du da nen script einsetzen kannst mache das doch einfach in deiner bevorzugten Programmiersprache...
Zuerst einmal alle Daten auslesen und diese in nen Array speichern... Danach beliebig oft ein Element aus diesem Array rausziehen - und das dann nochmal abfragen...
Die Frage ist: Was möchtest du damit testen? Wenn die Anlage nen bisserl gut ist dann hat die nach nen paar Anfragen die LDAP-Daten eh im Cache -> und du fragst nur noch den Cache ab...
Zuerst einmal alle Daten auslesen und diese in nen Array speichern... Danach beliebig oft ein Element aus diesem Array rausziehen - und das dann nochmal abfragen...
Die Frage ist: Was möchtest du damit testen? Wenn die Anlage nen bisserl gut ist dann hat die nach nen paar Anfragen die LDAP-Daten eh im Cache -> und du fragst nur noch den Cache ab...
Danke für deine rasche Antwort.
Das grösste meiner Probleme liegt darin das ich leider über keine Kenntnisse irgendeiner Programmiersprache verfüge.
Das mit dem Cache ist nicht so ein Problem da ich das zu Testzwecken deaktivieren kann so das er immer sucht.
Das grösste meiner Probleme liegt darin das ich leider über keine Kenntnisse irgendeiner Programmiersprache verfüge.
Das mit dem Cache ist nicht so ein Problem da ich das zu Testzwecken deaktivieren kann so das er immer sucht.
Moin,
wofür möchtest du das machen? (Sorry aber bevor ich da nicht einen SINNVOLLEN Grund sehe werde ich keine weitere Hilfestellung leisten können -> wer sagt mir denn das du nicht einfach nen Angestellter bist der grad mal die TA nen bisserl "provozieren" bzw. plätten möchte?). Ich denke wenn du der Admin bist wirst du es nachvollziehen können das man nicht jedem die Lösung geben möchte wie man ein Bauteil unter Action setzt...
Und die Anfrage ans LDAP durch Telefone o.ä. wird kaum die Anlage ins Schwitzen bringen - nen paar 100 bis 1000 Anfragen / Sek. sollte das ding locker bewältigen... Und SO schnell können dann die User auch nich tippen ;)
wofür möchtest du das machen? (Sorry aber bevor ich da nicht einen SINNVOLLEN Grund sehe werde ich keine weitere Hilfestellung leisten können -> wer sagt mir denn das du nicht einfach nen Angestellter bist der grad mal die TA nen bisserl "provozieren" bzw. plätten möchte?). Ich denke wenn du der Admin bist wirst du es nachvollziehen können das man nicht jedem die Lösung geben möchte wie man ein Bauteil unter Action setzt...
Und die Anfrage ans LDAP durch Telefone o.ä. wird kaum die Anlage ins Schwitzen bringen - nen paar 100 bis 1000 Anfragen / Sek. sollte das ding locker bewältigen... Und SO schnell können dann die User auch nich tippen ;)
Also, das ist so ...
Ich arbeite in einer Firma welche ich jetzt hier nicht näher benennen möchte die Telefonanlagen herstellt. Ich bin Teil des Testteams (eines sehr kleinen Teams) und wir sind alle keine IT Leute den wir Testen die Integrierten Features von Hand oder in meinem Fall mache ich Limittests und Loadtests um zu sehen wie sich so ein System unter Last verhält.
Also, die Entwickler haben da was in die TK Anlage eingebaut um einen LDAP Server laufen zu lassen. Ich wurde nun gefragt wie wir das in den Test integrieren können um auf dieser Komponente Last zu erzeugen durch LDAP Anfragen an unser TK System (ev. Crasht es ja nach n/anfragen)...
Ich habe mich hier im Forum gemeldet weil ich schon so manche brauchbare Antwort bekommen habe.
PS: Eigentlich brauch ich eben grad einen Mechanismus zum "plätten" ... leider.
Ich arbeite in einer Firma welche ich jetzt hier nicht näher benennen möchte die Telefonanlagen herstellt. Ich bin Teil des Testteams (eines sehr kleinen Teams) und wir sind alle keine IT Leute den wir Testen die Integrierten Features von Hand oder in meinem Fall mache ich Limittests und Loadtests um zu sehen wie sich so ein System unter Last verhält.
Also, die Entwickler haben da was in die TK Anlage eingebaut um einen LDAP Server laufen zu lassen. Ich wurde nun gefragt wie wir das in den Test integrieren können um auf dieser Komponente Last zu erzeugen durch LDAP Anfragen an unser TK System (ev. Crasht es ja nach n/anfragen)...
Ich habe mich hier im Forum gemeldet weil ich schon so manche brauchbare Antwort bekommen habe.
PS: Eigentlich brauch ich eben grad einen Mechanismus zum "plätten" ... leider.
Hallo,
gut, dass du die Firma nicht angibst (wobei die Homepage aus deinem Profil einer großen Firma aus dem Bereich gehört) - wenn keiner der Tester einer Anlage programmieren kann ist das peinlich. Allerdings kann ich maretz nicht ganz zustimmen: mit einem einfachen Skript wird man nicht auf mehr als 1 Verbindung auf einmal kommen, wobei die Anzahl paralleler Verbindungen durchaus testwürdig ist (dafür schafft das Skript mehrere sehr schnell nacheinander, was ja auch interessant ist). Aber die Lösung ist ganz einfach: Wende dich an eure Entwickler uns sag, sie sollen was beibringen um das ordentlich zu testen. (eine Multi-Threaded-Anwendung die mal eben 1000 Anfragen parallel macht ist auch recht flott beisammengeschrieben)
Gruß
Filipp
gut, dass du die Firma nicht angibst (wobei die Homepage aus deinem Profil einer großen Firma aus dem Bereich gehört) - wenn keiner der Tester einer Anlage programmieren kann ist das peinlich. Allerdings kann ich maretz nicht ganz zustimmen: mit einem einfachen Skript wird man nicht auf mehr als 1 Verbindung auf einmal kommen, wobei die Anzahl paralleler Verbindungen durchaus testwürdig ist (dafür schafft das Skript mehrere sehr schnell nacheinander, was ja auch interessant ist). Aber die Lösung ist ganz einfach: Wende dich an eure Entwickler uns sag, sie sollen was beibringen um das ordentlich zu testen. (eine Multi-Threaded-Anwendung die mal eben 1000 Anfragen parallel macht ist auch recht flott beisammengeschrieben)
Gruß
Filipp
Moin,
stimmt, die Script-Möglichkeit würde nur 1 Verbindung aufrecht erhalten (es sei denn man öffnet & schliesst die immer wieder und prüft so ob der Server die Verbindungen auch schnell genug wieder schließt).
Aber ich sehe das genauso wie du - wenn es wirklich um den TA-Test des Herstellers geht dann sollten hier die Entwickler auch fähig sein eine Testroutine zu bauen... Weiterhin muss ich sagen das mir für eine genaue Anweisung wie man das testen kann die Aussage ehrlich gesagt deutlich zu dürftig ist (man bedenke das ein solches Script auch ggf. die Firmen-TA belasten könnte). Denn: Jemand der eine Software testen sollte müsste auch grob wissen wie man sowas baut - wie möchte man sonst den Erfolg/Mißerfolg bewerten? Wenn über eine offene Verbindung 500 Abfragen/Sek. laufen - ist der Test dann erfolgreich oder nicht? Wenn in 10 Sek. 200 Verbindungen auf- und abgebaut werden - ist das dann nen gutes Ergebnis oder nicht? Wie sieht es aus wenn die Abfragen von verschiedenen Systemen *gleichzeitig* kommen?
Von daher kann ich mich dem Filipp nur anschließen -> geh zur Entwicklungsabteilung und DIE sollen dir die nötigen Tools zusammenbauen... Für die sollte nen kleines Shell-Script kein Problem sein - und falls gleichzeitige Abfragen simuliert werden sollen können die dir ggf. auch nen Multi-Thread-Programm schustern (sollte nicht mehr als 1-2 Std. kosten). Ansonsten ist für mich ein Test von Leuten die solche Grundlagen nicht können ehrlich gesagt zimlich unnötig und Zeitverschwendung - die TA-Software mal eben "wild" mit nen paar Anfragen zu behaken dürfte nicht Aussagekräftig sein...
stimmt, die Script-Möglichkeit würde nur 1 Verbindung aufrecht erhalten (es sei denn man öffnet & schliesst die immer wieder und prüft so ob der Server die Verbindungen auch schnell genug wieder schließt).
Aber ich sehe das genauso wie du - wenn es wirklich um den TA-Test des Herstellers geht dann sollten hier die Entwickler auch fähig sein eine Testroutine zu bauen... Weiterhin muss ich sagen das mir für eine genaue Anweisung wie man das testen kann die Aussage ehrlich gesagt deutlich zu dürftig ist (man bedenke das ein solches Script auch ggf. die Firmen-TA belasten könnte). Denn: Jemand der eine Software testen sollte müsste auch grob wissen wie man sowas baut - wie möchte man sonst den Erfolg/Mißerfolg bewerten? Wenn über eine offene Verbindung 500 Abfragen/Sek. laufen - ist der Test dann erfolgreich oder nicht? Wenn in 10 Sek. 200 Verbindungen auf- und abgebaut werden - ist das dann nen gutes Ergebnis oder nicht? Wie sieht es aus wenn die Abfragen von verschiedenen Systemen *gleichzeitig* kommen?
Von daher kann ich mich dem Filipp nur anschließen -> geh zur Entwicklungsabteilung und DIE sollen dir die nötigen Tools zusammenbauen... Für die sollte nen kleines Shell-Script kein Problem sein - und falls gleichzeitige Abfragen simuliert werden sollen können die dir ggf. auch nen Multi-Thread-Programm schustern (sollte nicht mehr als 1-2 Std. kosten). Ansonsten ist für mich ein Test von Leuten die solche Grundlagen nicht können ehrlich gesagt zimlich unnötig und Zeitverschwendung - die TA-Software mal eben "wild" mit nen paar Anfragen zu behaken dürfte nicht Aussagekräftig sein...
Über Sinn und Unsinn könnte man sicher Seitenlang diskutieren. Na gut ich wollt eigentlich nur einen Lösungsansatz... ein paar nützliche Tipps,links oder eine Idee. Ich hab von niemand verlangt mir irgendetwas zu programmieren.
Danke an alle beteiligten.
Danke an alle beteiligten.
Hallo,
wir haben dir doch einen super Lösungsansatz genannt: Frag' die Entwickler!
Im Ernst: ich kenne kein Tool speziell für sowas. Aber ein Programmierer (und ein solcher sollte der Enwickler sein) kann da ziemlich flott ein Programm schreiben (LDAP-Bibliotheken für die Mainstream-Sprachen werden auch zu finden sein). Wichtig ist es, Testkriterien zu definieren - im Sinne der Arbeitsteilung ist das dann wohl deine Aufgabe. Und bestimmt kennst du den Markt, und weißt, was für Kenngrößen es gibt, und welche Werte andere Hersteller hier in welchem Segment erreichen.
Gruß
Filipp
wir haben dir doch einen super Lösungsansatz genannt: Frag' die Entwickler!
Im Ernst: ich kenne kein Tool speziell für sowas. Aber ein Programmierer (und ein solcher sollte der Enwickler sein) kann da ziemlich flott ein Programm schreiben (LDAP-Bibliotheken für die Mainstream-Sprachen werden auch zu finden sein). Wichtig ist es, Testkriterien zu definieren - im Sinne der Arbeitsteilung ist das dann wohl deine Aufgabe. Und bestimmt kennst du den Markt, und weißt, was für Kenngrößen es gibt, und welche Werte andere Hersteller hier in welchem Segment erreichen.
Gruß
Filipp
Einen Lösungsansatz hast du ja bekommen - im grunde genommen sogar 3! Ich fasse kurz zusammen:
a) Du nimmst ein Script welches zuerst alle LDAP-Einträge in einen Array liest und dann für "for ($x=0;$i<=...;$x++)" durchläufe sich immer ein Zufallselement aus dem Array zieht und dieses aus dem LDAP abfragt. Nachteil hier: Der Cache von der TA sollte die Daten nach wenigen Sekunden eh vorrätig haben - du machst also wenn überhaupt nen kleinen Last-Test für die Reaktionszeit...
b) Du nimmst ein Script welches mit mehreren Threads arbeitet - und behakst den Server damit. Jetzt hast du $x Verbindungen gleichzeitig offen - und siehst wie der Server auf viele Anfragen nahezu gleichzeitig reagiert (d.h. er kann nicht wie in a eine Abfrage beantworten und bekommt die nächste - jetzt passiert es das er noch mit der Antwort auf eine Anfrage beschäftigt ist und schon die nächste Anfrage ansteht).
c) Du nimmst ein Script - z.b. das aus a und baust den Verbindungsauf- und Abbau in die for-schleife mit rein. Jetzt weisst du wie sich der LDAP-Server verhält wenn er sehr oft nacheinander die Verbindungen auf- und abbauen muss und ob der die sockets auch richtig schliesst (d.h. auch wieder verwenden darf).
Das sind schonmal 3 Ansätze die unabhängig voneinander laufen können und von nem Entwickler in zusammen in max. 2 Std. geschrieben werden sollten...
a) Du nimmst ein Script welches zuerst alle LDAP-Einträge in einen Array liest und dann für "for ($x=0;$i<=...;$x++)" durchläufe sich immer ein Zufallselement aus dem Array zieht und dieses aus dem LDAP abfragt. Nachteil hier: Der Cache von der TA sollte die Daten nach wenigen Sekunden eh vorrätig haben - du machst also wenn überhaupt nen kleinen Last-Test für die Reaktionszeit...
b) Du nimmst ein Script welches mit mehreren Threads arbeitet - und behakst den Server damit. Jetzt hast du $x Verbindungen gleichzeitig offen - und siehst wie der Server auf viele Anfragen nahezu gleichzeitig reagiert (d.h. er kann nicht wie in a eine Abfrage beantworten und bekommt die nächste - jetzt passiert es das er noch mit der Antwort auf eine Anfrage beschäftigt ist und schon die nächste Anfrage ansteht).
c) Du nimmst ein Script - z.b. das aus a und baust den Verbindungsauf- und Abbau in die for-schleife mit rein. Jetzt weisst du wie sich der LDAP-Server verhält wenn er sehr oft nacheinander die Verbindungen auf- und abbauen muss und ob der die sockets auch richtig schliesst (d.h. auch wieder verwenden darf).
Das sind schonmal 3 Ansätze die unabhängig voneinander laufen können und von nem Entwickler in zusammen in max. 2 Std. geschrieben werden sollten...
