IPS Tuning - Wo ansetzen?

Archiv Allgemeine Diskussion (2.x/3.x)
1

Hallo,

ich würde gerne mal einen allgemeinen Thread zum Thema Tuning/ Performance eröffnen und hoffe, dass auch Paresy etwas dazu sagt, denn ich denke, dass das Thema von allgemeinem Interesse ist - das zeigt ein Stück weit die Diskussion um SSD’s mit denen man IPS versuchte schneller zu machen (und im Ergebnis nur ein „leiser“ zu erwarten scheint).

Natürlich kann man sagen, dass ein Supersystem mit 10.000er Festplatte, vielleicht riesen SSD, Speicher und möglichst schnellem Prozessor „alle Probleme beseitigt“.

Andererseits habe ich bis heute zu wenig über die IPS Interna heraus bekommen und bei vielen Benchmarks, die ich gemacht habe, teilweise vor der Mühle sitzend, teilweise per Timer alle paar Sekunden automatisch gefahren, konnte ich mangels der regelmässigen Ausreisser noch immer keine wirkich belastbaren Erkenntnisse gewinnen.

Selbst Scripte mit „echo hello“-Qualität haben bewegen sich im Bereich von 1ms bis 20ms.

Auch bei Versuchen, Daten, die immer gebraucht werden und in einem Array stecken sollen, via Include (Script), INI-Read oder JSON zu laden ergaben nie wirklich belastbare Werte (im Sinne von nachvollziehbar gleich in den Werten) her.

Selbst die Versuche, solche Dateien auf einer Ram-Disk abzulegen und zu laden, haben nicht so richtig was gebracht. Wegen der Streuung der Werte konnte kein eindeutiger Gewinner ausgemacht werden.

Frage also an den Hersteller:

Wo sind denn die Tuning Potenziale (mal von einem einigermaßen vernünftigen Code ausgegangen) für den Betrieb (ich klammere mal den Startup-Prozess aus)?

Arrays vs. Variablen?

Standarddaten (nehmen wir mal 1kB an „Systemparameter“) in Includes / INI’s oder Variablen?

Include vs. IPS_RunScript?

Viele kleine Dateien vs. einer großen (sprich 1k vs. 10k)?

Viele Extensions vs. wenige Extensions?

RamDisk / SSD / Speicher / Taktfrequenz?

Kerninstanten?

Wie wirken sich viele Instanzen aus?

Mehrere Sockets plus Modifikation der IP/Ports durch ein Skript vs. mehrere Socket Instanzen mit „fixen“ Werten?

Vielleicht könnten auch ein paar Hinweise gegeben werden, wie der PHP Server in IPS integriert ist, wie da ein Script Aufruf zustande kommt etc.?

Und natürlich wäre ich für Tipps dankbar, wie am sinnvollsten der eigene Code auf Effizienz getestet werden kann. Denn für „native PHP“ gibt es da ja einiges, aber wie solches in IPS nutzen?

Bin sehr gespannt!
jwka

2

ich stell mal die Frage andersrum:
an welcher Stelle ist IPS zu langsam -> bzw. woran machst Du fest, das es zu langsam ist?

Vielleicht verbirgt sich dahinter auch die Frage: hast Du „ernsthafte“ Performance-Probleme oder „willst Du nur spielen“? :wink:

Vielleicht eine erklärende Anmerkung: ich hatte mir vor einiger Zeit auch die Frage gestellt, ob ich mein IPS überfordere. Am Ende war es aber nur ein „Problem“ zwischen IPS-Dienst und remote geöffneter Konsole -> nur auf der Konsole erschien IPS langsam

3

Also Tuning Potential gibt es natürlich sehr viel.
Vieles hängt natürlich auch von einer durchdachten Programmierung der Skript ab.

Beispiele:

Egal welche Automatisierung geskriptet wird. Je weniger Aktionen (Befehle, Variablen, Abfragen, …) desto besser meist die Performance.

Vermeidung von zyklischen Ereignissen wenn möglich. Besser sind meist bedingte Ereignisse (z.B. nur wenn Statusänderung) da diese in Summe meist weniger häufig ausgeführt werden. Dies ist aber natürlich von Anwendungsfall zu Anwendungsfall unterschiedlich.

Speichern von Zwischenergebnissen in IPS Variablen sollte wenn es irgendwie geht vermieden werden. Hiezu ist es in jedem Fall besser Systemvariaben zu verwenden. Bei vielen Rechenoperationen gibt es hier viel Potential.

… dies nur einige wenige Beispiele.

4

Keep it simple, stupid. (KISS-Prinzip)

Je einfacher die Lösung, desto besser sind diese meistens. Klimmzüge für minimal bessere Performance sind in unserer heutigen Zeit von fast endloser Rechenpower weniger Wert als unsere Zeit.

paresy

PS: Die meisten deiner Fragen gehören in die PHP Mailinglist. Dort sind die PHP-Spezis.

5

@Raketenschnecke:

Das (Latenz tritt nur in der Console auf) hatte auch in Erwägung gezogen, da aber die Auswertungen mittels microtime() bis auf wenige ms mit den angezeigten Werten in der Console übereinstimmten, habe ich diese „Entspannung“ wieder zur Seite gelegt.

Mal ein Konkretes Beispiel:

Ich habe 3000 (theoretische) Werte (Parameter), die beim Eintreten eines Calls auf einem Server Socket ausgewertet werden sollen (30 Anfragetypen x 10 Parameter x 10 Werte). Praktisch sind zur zeit vielleicht 500-600 belegt.

Diese müssen je beim Start des Scripts (ein solcher Event kann u.U. nur 1x am Tag oder auch 20 x je Sekunde eintreten) eingelesen werden, um sie dann in einer Loop/Switch zu verarbeiten.

Hier mit Streuungen zwischen 15 und 150 ms zu arbeiten macht das Vorhersehen, ob die einttrudelnden Requests „in time“ abgearbeitet werden können, zur Lotterie.

@Paresy:
Hmmm. Geht in Richtung meines Satzes: „Superrechren“.

Ein bischen was vom Hersteller zum Thema „wie tut’s“ wäre dennoch hilfreich:

Wie beeinflussen viele Extensions die „systembedingte“ Scriptperformance?

Wie ist das mit den Script-Events genau?

Was wird JE Script-Ausführung an „Preparation Time“ in IPS fällig, was nur einmalig, beim Start von IPS? (z.B. wird je Script eine Shell geöffnet oder beim Start X Endlos-Loops o.ä. gestartet, in die dann Scripte bei Anforderung „eingeklinkt“ werden? Ich habe da keinerlei Ahnung, wie man sich die PHP Einbindung in IPS vorstellen muss.)

Auch der Hinweis auf die PHP Mailing List ist nur bedingt hilfreich, weil ich Fragen, die dann dort kommen, nicht beantworten kann. Z.B.:

kann in IPS ein Cache integriert werden? PHP: APC - Manual

Wie sieht es mit Memcache aus? Nutzbar? Wie?

So stellt sich für mich u.a. die Frage, wie man Arrays über Scriptläufe hinweg „erhalten“ kann, also nicht je Scriptlauf erneut generieren muss. Denn viele meiner Werte werden wieder und wieder in oftmals zwischen Scriptläufen völlig unveränderter Form gebraucht.

Danke für ein paar Sätze.
jwka

6

@mr_cg:

Speichern von Zwischenergebnissen in IPS Variablen sollte wenn es irgendwie geht vermieden werden. Hiezu ist es in jedem Fall besser Systemvariaben zu verwenden. Bei vielen Rechenoperationen gibt es hier viel Potential.

Kannst Du das mal etwas genauer beschreiben? Ist genau eines meiner Themen. Allerdings strukturiert, also Arrays.

jwka

7

berechnest Du den Einfluß der sich verringernden Anzahl der Raucher auf den Klimawandel? … ich dachte, hier gehts um Homeautomation :wink:

8

Hallo,

irgentwie verstehe ich den Sinn des Threas noch nicht - ich weiss nicht wo IPS langsam ist und wo ist mehr Power bräuchte.
Das grösste Problem sind bei mir zu Remote-Zugriff von ausserhalb oder innerhalb des Netzwerks, wenn PowerLan dazwischen ist, aber das hat nichts mit IPS-Tuning zu tun.
Mein Server hingehen langweilt sich ( 1,8 GHz Atom Dualcore mit, Win7 64Bit, 4 GB Ram, SSD ).
Es gibt nur zwei Zeitpunkte am Tag, wo die CPU-Auslastung mal die 10% überschreitet und dann läuft das Backup mit einer Datenkomprimierung…

9

Dazu musst du den Themenersteller verstehen und dich tief ins Forum einlesen :wink:

10

Vielleicht bin ich zu ungeduldig, was die Reaktionszeit eines Systems angeht und der eine oder andere ist durchaus zufrieden, wenn das Licht erst deutlich und merklich nach Drücken des Schalters an- oder ausgeht - Hauptsache überhaupt.

Oftmals ist man vielleicht auch, wenn man etwas selbst entwickelt hat, diesem „etwas“ gegenüber etwas großzügiger, was Erwartungen angeht als ein „fremder Nutzer“.

Das ist so ähnlich wie kreischende Kinder: Die des Nachbarn stören viel mehr als die eigenen und fremde Kinder sind noch mal schlimmer als die vom Nachbarn.

Bei mir ist es allerdings so, dass meine Dinge kritisch hinterfrage (auch, weil ich einiges in Kundenprojekten einsetze) und dass einige der Abläufe - für mich - ab und an einfach zu langsam gehen. Und das ist nicht zwangsläufug schlechter Code, denn derselbe Code geht in vielen Fällen schnell genug. Nur manchmal, da ist er dann viel zu langsam.

Und ratet mal, wann das so ist:

  • Wenn ich gerade eine Demo mache.
  • Wenn ich einem Besucher die Vorzüge von Home Automation nahe bringen möchte.
  • Wenn ich eine Reaktion gerade mal wirklich schnell brauche - z.B. weil das Telefon geklingelt hat

Ich habe schon viele Benchmarks gemacht, und versucht, zu ergründen, woran solches wohl liegen mag und was ich tun kann, um zuverlässigere Zeiten hin zu bekommen.

Leider ist es so, dass die Laufzeiten selbst sehr kurzer Scripte ein paar mal mal 2ms und dann mal wieder 15 oder 20ms dauern. Ein und dasselbe Script, wohl gemerkt. Analog dauern komplexere Scripte schonmal 300ms und da sind wir im Bereich des deutlich merkbaren.

Und dies, OHNE dass auf dem Rechner auffallend größere Prozesse im Hintergrund laufen. Ja, ich habe auf dem Rechner zusätzlich den Media Streamer laufen, aber der hat nicht gerade „geindexed“. Meist war sogar nicht mal ein Stream am laufen. Und. Nein, auch bei den Ausreissern ist im Task Manager eigentlich nur Schlafen der Maschine zu sehen. Ist aber auch kein Wunder, denn die Auflösung der Achsen ist ja so grob, dass zwei Skriptläufe, einer mit 10 und einer mit 100 ms da nicht auszumachen sind.

Nun ist mein IPS Rechner zwar nicht die Superrakete, aber ein ACER mit 2GB RAM, Vista, Dual Core Pentium T2330 mit 2x1,6 GHz ist jetzt auch nicht gerade eine Schlaftablette.

Auch habe ich ganz ähnliche Beobachtungen auf noch deutlich schnelleren (Stand-)Rechnern gemacht, bei verschiedenen Tests.

Weil eben diese Test so breit streuen suche ich nach Tips.

Weiter: Ich will meine Scripte pflegbar schreiben, daher ist viel Doku drin und wo es geht, lagere ich Parameter in INI Dateien oder Includes mit Strukturierten Arrays aus. Ausserdem lade ich ein Framework, welches bestimmte Vorteile bietet aber eben auch Overhead mit sich bringt.

Ich hatte schon den Verdacht, dass die Ladezeiten der Scripte plus Parameter also die reinen DISK-IOs teilweise das Bottleneck sind. Allerdings hat das Einrichten einer Ramdisk nichts gebracht. Da waren die Ergebnisse mitunter sogar schlechter als von der HD. Vermutlich hing das mit dem IO Puffer zusammen, aber so tief kann ich eben nicht reingucken.

Ich komme also zurück zur guten alten Regel: keine Komponente kann schnell genug sein, also frage ich nach.

Ich weiss auch aus einem Projekt mit einem anderen IPS USer, dass z.B. die Geschwindigkeit, eine Variable wegzuschreiben in IPS nicht eben berauschend ist, denn dieser hat eine (PHP-)DLL geschrieben, die dasselbe in deutlich kürzerer Zeit schafft und auch das lesen ging dort nach seinen Aussagen um Potenzen schneller.

Allerdings hat so eine Lösung natürlich den Makel, dass eine gewisse (den Wert mag jeder mit sich selber ausmachen) Wahrscheinlichkeit besteht, dass nach einem Update von IPS da nix mehr geht.

Deshalb suche ich erst einmal nach dem Ausreizen der Bordmittel.

Und wenn ich schliesslich die Diskussion an anderer Stelle über die Verwendung einer SSD lese (die nicht von mir stammt) dann würde ich sagen: Ausser mir machen sich auch andere sich noch Gedanken zur Performance - auch wenn das einige hier gerne als exclusiven Spleen von mir abtun.

jwka

11

ich weis nicht, was diese abstrakte Diskussion (nicht weniger abstrakt als im PHP-Forum, schon deren Experten wussten nicht so recht damit umzugehen) bringen soll. Wenn Du wirklich Hilfe willst und auch konkret an Lösungen arbeitest, schlage ich vor dass Du endlich mal die Katze aus dem Sack lässt und mal konkret aufzeigst, was denn da so unglaublich unperformant ist. Vielleicht ist es Dein Konzept oder Deine Scripte? Schon Pareto sagt: 20% der Probleme verursachen 80% Aufwand (frei übersetzt). Enorm von Vorteil ist, diese 20% möglichst früh zu identifizieren.
Oder hast Du IPS als Echtzeit-Analysetool dem CERN angeboten?
Ich will damit nur sagen: solange IPS innerhalb der Grenzen betrieben wird, für die es gebaut wurde, läuft es völlig ausreichend performant. Solltest Du einen Spezial-Fall haben und wirklich eine Lösung erwarten, wirst Du wohl die Karten auf den Tisch legen müssen. Ansonsten ist das hier eine rein akademisch-theoretische Veranstaltung.

12

Machen wir doch mal ne ABC-Analyse.

BTW: Gibt es die Beiträge auch vorgelesen als mp3? :slight_smile:

13

Sorry, ich bin für unbestimmte Zeit weg. :D:p

14

Die ABC Analyse dient ja dazu, das wesentliche und das unwesentliche zu trennen. Das wäre hier wohl angebracht. :smiley:

15

Ich denke man sollte einen Server, der sich 99,9% der Zeit langweilt nicht mit einem performanten Server gleichsetzen. Was nützt es, wenn er mit < 10% auf Arbeit wartet, wenn er diese dann, wenn er sie bekommt, noch ausreichend schnell ausführt. Und wir reden ggf. von ms, die man im Monitor sicherlich nicht erkennt.
Zumindest mein Wechsel vom Atom auf den i3 hat Server spürbar reaktionsfreudiger gemacht obwohl der Atom nie unter hoher Last lag.

Mir ist aber auch schon aufgefallen, das manche simplen Skripte mal länger, mal schneller laufen.

16

Das ist genau der Punkt. Dies kann ich hier auch leicht nachvollziehen.
Schon alleine beim Öffnen der Konsole.

17

Die Beobachtung mit dem Umstieg auf Core i3 / Windows Home Server 2011 kann ich bestaetigen. Die Reaktionszeiten sind blitzschnell und ich habe „irgendwie“ auch das Gefuehl, dass viel weniger FS20-Schaltbefehle verloren gehen. Mit Messdaten kann ich das aber nicht belegen :slight_smile: