nicht angemeldet Robert B.
Rolf B
dedlfix
klawischnigg
Robert B.
klawischnigg
MudGuard
Der Martin
dedlfix
Henry
Hallo, alle miteinander!
Ich lerne Programmieren und baue als Übungsobjekt ein kleineres Programm für die Firma.
In diesem Programm habe ich alle möglichen Konstanten, teilweise auch größere Arrays, die ich an verschiedenen Stellen im Programm brauche.
Verpacke ich alle zusammen in eine zu includierende Konstanten-Datei, werden immer alle geladen, auch wenn ich auf der jeweiligen Seite vielleicht nur ein paar davon brauche, schreibe ich sie einzeln rein, sind sie schlecht zu pflegen.
Welche Vorgehensweise ist denn hier (bei prozeduralem Code) lege artis, um gleichzeitig den Speicher zu schonen und gute Pflegbarkeit des Codes zu erreichen?
Danke für Eure Hilfe
Kerstin
Rolf B
Hallo Kerstin,
wie wäre es denn die Konstanten nicht in einer Include-Datei, sondern in mehreren „Modulen“ zusammen zu fassen, also je nach Verwendung. Dann kannst du die Module je nach Bedarf einbinden.
Viele Grüße
Robert
Hallo Robert,
ja, das war mein erster Ansatz. Aber da es kaum Gemeinsamkeiten bei den auf den verschiedenen Seiten benötigten Konstanten/Variablen/Funktionen gab, hing ich plötzlich mit einer immer größer werdenden Anzahl von Modulen da und die Sache wurde sehr unübersichtlich...
Es gibt aber sicher Situationen, wo, ein Programm grundsätzlich anderes aufgebaut ist, wo man das mit Erfolg so machen kann.
Letztlich ist es ja gleiche Problem, das Datenbanken jeden Tag zu lösen haben: Nämlich n:m-Beziehungen aufzulösen. Da ich hier aber mit meinen begrenzten Programmierfähigkeiten keinen Datenbank-Ansatz mit Zwischentabellen aufziehen kann ;-) - fand ich bisher keine wirklich gute Lösung.
Danke und herzliche Grüße
Kerstin
Was man nicht machen sollte ist das Ablegen einer Konfiguration (Deine Variablen) als PHP Code in Dateien die dann mit include oder require eingebunden werden. Begründung folgt.
MFG
Moin,
Was man nicht machen sollte ist das Ablegen einer Konfiguration (Deine Variablen) als PHP Code in Dateien die dann mit include oder require eingebunden werden. Begründung folgt.
wann lege ich schon einmal Einspruch ein – Begründung folgt 😉
Viele Grüße
Robert
Für den Anfänger: Nimm es einfach so hin. Die Begründung würde den Rahmen dieses Threads hier sprengen und ist mir daher einen eigenen Artikel wert.
Bis demnächst.
Für den Anfänger: Nimm es einfach so hin.
Für den Anfänger: Nimm es KEINESFALLS einfach so hin. Von niemandem. Außer vielleicht Du vertraust jemandem zu 100% und stehst unter enormen Zeit-/Lösungsdruck.
Ich bin weder ein Anfänger noch nehme ich irgendetwas einfach so hin – vor allem nehme ich Arroganz nicht hin.
Was man nicht machen sollte ist das Ablegen einer Konfiguration (Deine Variablen) als PHP Code in Dateien die dann mit include oder require eingebunden werden. Begründung folgt.
Hier isse incl. Benchmark.
MFG
Wir reden hier besser von einer Konfiguration. Da hat es sich in meiner Praxis bewährt, die ganze Konffiguration in einer einzigen Datei aufzustellen.
Diese Datei erzeugt ein sog. Deploymentprozess wobei die Inhalte für die aufzustellende Konfigurationsdatei aus verschiedenen Quellen kommen. Editiert werden also lokale Quelldateien und der Deploymentprozess fasst dann alles zusammen in einer Datei.
Wegen der RAM-Gefälligkeit: Es ist kein Problem mit heutiger Servertechnik bei jedem Request eine Konfigurationsdatei von 1MB zu laden, das gibt nur einen Burst den der Cache puffert und das wars. Dafür hast Du die ganze Konfiguration, für die eine zweckmäßige Datenstruktur zu überlegen wäre, im wahlfreien Zugriff.
MFG
Hallo pl,
vielen Dank für Deinen Input!
Da ich nicht vom Fach bin, habe ich nur leider fast gar nichts verstanden von dem, was Du geschrieben hast... Meinst Du, dass dieser Deploymentprozess sich automatisch die benötigten Konstanten etc raussucht und dann nur die benötigten lädt? Und wie erstellt man so einen Prozess?
Gibt es eigentlich grundsätzlich die Möglichkeit, aus einer Datei nur ausgewählte Konstanten/Variablen/Funktionen zu laden?
Herzliche Grüße
Kerstin
Hallo Kerstin,
wenn Du eine Webseite erstellst, hast Du zumindest zwei Webs: Entwicklung und Betrieb (Produktion). Für größere Projekte kommen gerne auch noch Fachtest und Abnahmetet hinzu. Vielleicht auch noch eine Hotfix-Umgebung - da kann man beliebig kreativ werden.
Die Aufgabe einer Deployment-Toolchain ist es, die von den Entwicklern gebildeten Änderungspakete auf die richtigen Webs zu verteilen. Dafür gibt es unterschiedliche Konzepte und Tools, darauf will ich jetzt gar nicht eingehen. Vermutlich ist es für Dich ohnehin zu groß.
Im einfachsten Fall besteht der Deployprozess darin, alle geänderten Dateien des Entwicklungs-Webs ins Produktionsweb zu kopieren. Das kann eine manuelle Tätigkeit sein (FTP Upload) oder ein Script, das das automatisiert.
Eine Verfeinerung ist eine Sourcecode-Verwaltung wie GIT. Da kannst Du sagen: Ich checke diese und jede Änderung ein, und ich sorge mit GIT dafür, dass Änderungspakete von einer Stufe zur anderen kommen. Das gibt Nachvollziehbarkeit und auch die Möglickeit, Änderungen zurückzunehmen (Backout).
Eine andere Verfeinerung sind Scripte, die beim Deployment automatisch anlaufen. Ein solches Script könnte z.B. 7 PHP Dateien mit define Anweisungen darin einlesen und eine große Datei daraus erzeugen. In der Entwicklung hättest Du dann die 7 Teildateien und in Produktion die eine große Datei.
Aber ganz ehrlich - das bringt nicht viel. Wenn Du einen FastCGI Server verwendest, wird geladener PHP Code gecached und es ist dann beinahe egal, ob das erste Laden aus einer, sieben oder siebenundsiebzig Dateien erfolgt.
Interessanter ist die Frage nach der logischen Organisation deiner Konstanten und ihre Abhängigkeit von Funktionen, die Du programmiert hast. Wenn Referenzen auf große Arrays tatsächlich durch das ganze Programm verteilt sind, müsste man fragen, ob hier nicht eine Klasse angebracht ist, die diese Arrays kapselt und die Zugriffe darauf als Methoden bereitstellt.
Rolf
Hallo Rolf,
danke für die ausführliche Antwort!
Aber ganz ehrlich - das bringt nicht viel. Wenn Du einen FastCGI Server verwendest, wird geladener PHP Code gecached und es ist dann beinahe egal, ob das erste Laden aus einer, sieben oder siebenundsiebzig Dateien erfolgt.
Interessanter ist die Frage nach der logischen Organisation deiner Konstanten und ihre Abhängigkeit von Funktionen, die Du programmiert hast. Wenn Referenzen auf große Arrays tatsächlich durch das ganze Programm verteilt sind, müsste man fragen, ob hier nicht eine Klasse angebracht ist, die diese Arrays kapselt und die Zugriffe darauf als Methoden bereitstellt.
Das entnehme ich als Essenz Eurer aller Antworten. Also vielen Dank!
Nicht von Fach? Dann fangen wir mit einer INI-Datei an in welcher eine Konfiguration abgelegt wird. Das Besondere an der INI Datei ist, daß sie einfach zu editieren und seitens PHP einfach zu parsen ist.
Das Deployment besteht in diesem Fall nur darin, die lokal erstellte INI Datei zum Server hochzuladen, also dort aufzustellen.
Und ich denke das war jetzt verständlich. Und wenns ein bischen mehr sein darf: Schreibe ein PHP-Kommandozeilen-Script welches die INI-Datei validiert. Valide ist eine INI-Datei wenn parse_ini_file() keinen Fehler meldet.
Diese Validation vor dem Upload zum Server gehört sozusagen zum Deployment.
MFG
Tach!
Dann fangen wir mit einer INI-Datei an in welcher eine Konfiguration abgelegt wird.
So selbstverständlich, wie du das formulierst, ist es vielleicht in deinem System, aber nicht überall.
Das Besondere an der INI Datei ist, daß sie einfach zu editieren und seitens PHP einfach zu parsen ist.
Das Besondere daran im Gegensatz zu einer PHP-Datei ist, dass diese ini-Datei bei jedem Request erneut geparst werden muss. PHP-Dateien hingegen liegen nach der ersten Verwendung vorgeparst im Opcode-Cache.
Gut, die Daten aus der ini-Datei könnte man auch in einem Cache verwalten, das muss man dann aber selbst und zusätzlich programmieren.
dedlfix.
Hi there,
Da ich nicht vom Fach bin, habe ich nur leider fast gar nichts verstanden von dem, was Du geschrieben hast...
Mach Dir nichts d'raus, ich garantier' Dir, dieses Buzz-Word-Geschwurble haben auch die vom Fach nicht verstanden...
Hat schon jemand Bingo?
Hat schon jemand Bingo?
Kann nicht mehr lange dauern...
Hi,
Hat schon jemand Bingo?
Fast - mir fehlt nur noch "mein Framework". Oder habe ich das verpaßt?
cu,
Andreas a/k/a MudGuard
Hallo,
Wir reden hier besser von einer Konfiguration. Da hat es sich in meiner Praxis bewährt, die ganze Konffiguration in einer einzigen Datei aufzustellen.
hättest du das mal den Entwicklern von Apache gesagt ...
In Apache 2.0 war die Konfiguration noch übersichtlich und komfortabel in einer einzigen Datei, jetzt ist sie in Dutzende von Einzeldateien zersplittert. :-(
Ciao,
Martin
Tach!
In Apache 2.0 war die Konfiguration noch übersichtlich und komfortabel in einer einzigen Datei, jetzt ist sie in Dutzende von Einzeldateien zersplittert. :-(
Bereits in 1.3 gab es die Include- und AccessFileName-Direktiven. Und du kannst nach wie vor die gesamte Konfiguration in eine einzelne Datei schreiben.
dedlfix.
Hallo,
In Apache 2.0 war die Konfiguration noch übersichtlich und komfortabel in einer einzigen Datei, jetzt ist sie in Dutzende von Einzeldateien zersplittert. :-(
Bereits in 1.3 gab es die Include- und AccessFileName-Direktiven.
zu Versionen vor 2.0 kann ich nichts sagen. Dass man in 2.0 schon zusätzliche Dateien includieren konnte, ist mir bekannt. Aber die Default-Configdatei war monolithisch.
Und du kannst nach wie vor die gesamte Konfiguration in eine einzelne Datei schreiben.
Ja. Habe ich bei meinem Indianer auch getan.
Ciao,
Martin
Und du kannst nach wie vor die gesamte Konfiguration in eine einzelne Datei schreiben.
Ja. Habe ich bei meinem Indianer auch getan.
Jaja. Immer diese Sklavenhalter. Machen die eigenen Leute kaputt.
In Apache 2.0 war die Konfiguration noch übersichtlich und komfortabel in einer einzigen Datei, jetzt ist sie in Dutzende von Einzeldateien zersplittert. :-(
Die 5000 Zeilen mit Kommentaren waren auch nicht nur angenehm. Eine der ersten Aktionen war immer:
mv apache.conf apache.original
grep -vP '^\s*#' < apache.original | grep -vP '^\s*$' > apache.conf
um durch das Löschen von Kommentaren und Leerzeilen ein wenig Übersicht zu bekommen. Das geht auch heute noch…
Dafür gibt es jetzt aber auch:
(Soweit die configs für die Hostnamen klug benannt sind!)
Und, bei den Debian-artigen Distiibutionen (SuSE und RedHat bauen da eigenen Mist mit einer irren Skriptwüste) Verzeichnisse in /etc/apache2/ wie
bei welchen in *-available jeweils die config-Dateien sind, die aber unbeachtet bleiben, bis man sie nach *-enabled verlinkt (was die o.g. Skripte nebst ein wenig Fehlersuche auch tun).
Offen gestanden habe ich keinerlei Anlass dem alten 5000-Zeilen-Monster acu nur eine einzige Träne nachzuweinen.
Hallo,
In Apache 2.0 war die Konfiguration noch übersichtlich und komfortabel in einer einzigen Datei, jetzt ist sie in Dutzende von Einzeldateien zersplittert. :-(
Die 5000 Zeilen mit Kommentaren waren auch nicht nur angenehm.
die haben mich nie gestört.
Dafür gibt es jetzt aber auch:
- a2enconf configname
- a2disconf configname
- a2enmod modulname
- a2dismod modulname
- a2ensite hostname
- a2dissite hostname
- a2query
Ja, aber wozu? Das nützt doch nur jemandem, der oft an der Konfiguration seines Apachen herumschraubt. Wer "täglich" umkonfiguriert, hat's damit vielleicht etwas leichter.
Aber wer tut das? - Ich richte mir die Konfiguration einmal ein, und dann ist für Monate Ruhe. Und dann möchte ich die Apache-Config nicht als Baukasten mit einer vorgegebenen Menge an Bauklötzchen, sondern ich möchte sie selbst aus den Einzelteilen bauen.
Und, bei den Debian-artigen Distiibutionen (SuSE und RedHat bauen da eigenen Mist mit einer irren Skriptwüste) Verzeichnisse in /etc/apache2/ wie
- conf-available
- conf-enabled
- mods-available
- mods-enabled
- sites-available
- sites-enabled
bei welchen in *-available jeweils die config-Dateien sind, die aber unbeachtet bleiben, bis man sie nach *-enabled verlinkt (was die o.g. Skripte nebst ein wenig Fehlersuche auch tun).
Ja, auch das finde ich grauslig. Das ist das Motto: Warum einfach, wenn's auch umständlich geht?
Offen gestanden habe ich keinerlei Anlass dem alten 5000-Zeilen-Monster acu nur eine einzige Träne nachzuweinen.
So unterschiedlich sind die Präferenzen.
So long,
Martin
Und, bei den Debian-artigen Distiibutionen (SuSE und RedHat bauen da eigenen Mist mit einer irren Skriptwüste) Verzeichnisse in /etc/apache2/ wie
- conf-available
- conf-enabled
- mods-available
- mods-enabled
- sites-available
- sites-enabled
bei welchen in *-available jeweils die config-Dateien sind, die aber unbeachtet bleiben, bis man sie nach *-enabled verlinkt (was die o.g. Skripte nebst ein wenig Fehlersuche auch tun).
Ja, auch das finde ich grauslig. Das ist das Motto: Warum einfach, wenn's auch umständlich geht?
Einer der vielen Gründe ist, dass die Dateien in
bei Updates überschrieben werden (können). Die Zeilen mit Einträgen für das Laden der Module ändert man auch eher nicht selbst, selbst die für die allgemeine Konfiguration eher selten. Will man sehr spezielle Einstellungen macht man das meistens per Site, also in den selbst erzeugten Dateien unterhalb von /sites-available/.
Bei der alten, monolithischen und fehlerträchtigen Konfiguration sah der Federschmuck des Apache nach Updates oder dem Wechsel der PHP-Version manchmal ganz schön gerupft aus...
Für alles andere gibts:
cd /etc/apache2
grep -Rin 'wasauchimmer' *
Dann kann man mit vi datei +gef. Zeile sehr schnell die Fundstelle ändern.
Warum einfach, wenn's auch umständlich geht?
Ja. Wir werden alle älter. Guck Dir mal systemd und journald an und vergleiche das mit dem gutem alten System V - init (die "neue" Apache-Konfig unter dem Debian-artigen sieht in manchen Aspekten ein wenig nach den alten Tricks aus) bzw. logger. *wegduck*
Warum einfach, wenn's auch umständlich geht?
Ich gebe gern zu, dass genau das auch mein erster Gedanke war, als ich vor ein paar (sind es schon zehn, in Worten: 10?) Jahren erstmals die zerstückelte Konfiguration vorfand.
Da ich aber Seminare halte und (weil ich da auch einen Webserver mitbringe oder weil es just um den Apache geht) habe ich inzwischen bemerkt, dass die neue Konfiguration (mein Beitrag ist ja quasi eine Schnelleinführung) dem Admin das Leben durchaus erleichtert...
Oh je. Hab im Web was gefunden, was nicht nur ein Update braucht.
Tach!
In diesem Programm habe ich alle möglichen Konstanten, teilweise auch größere Arrays, die ich an verschiedenen Stellen im Programm brauche.
Aus welchem Grund hast du die Konstanten alle an einer Stelle zusammengefasst?
Verpacke ich alle zusammen in eine zu includierende Konstanten-Datei, werden immer alle geladen, auch wenn ich auf der jeweiligen Seite vielleicht nur ein paar davon brauche,
Hat das messbare negative Auswirkungen?
schreibe ich sie einzeln rein, sind sie schlecht zu pflegen.
Wer soll die Werte pflegen und wie häufig passiert das? Sind sie lediglich für die Wartung zusammengefasst oder hat das auch fachliche Gründe? Zu klären wäre, ist es für die fachliche Verständlichkeit wichtig, die Werte nahe bei der Verwendung stehen zu haben, oder ist die Pflegbarkeit an einem gemeinsamen Ort wichtiger?
Welche Vorgehensweise ist denn hier (bei prozeduralem Code) lege artis, um gleichzeitig den Speicher zu schonen und gute Pflegbarkeit des Codes zu erreichen?
Wenn du aktuelle Versionen von PHP nimmst, wird der Speicher sowieso belegt, weil diese Versionen einen Opcode-Cache mitbringen.
dedlfix.
Hallo Dedlfix, pl und Martin,
danke für Eure Antworten!
Danke für den Hinweis zum Opcode-Cache. Hab' nachgesehen, was das ist und entnehme als Zusammenfassung all Euren Hilfestellungen, dass es keinen speicher- und performancetechnisch höchstwahrscheinlich - gerade bei meinem kleinen Programm - keinen Unterschied macht, ob ich die Konstanten als Komplettpaket lade oder in jede Seite einzeln reinschreibe, sondern es allein darauf ankommt, wo es für die Programmverständlichkeit besser aufgehoben ist.
Zur Ini-Datei werde ich mich mal schlaulesen und objektorientierte Programmierung ist sowieso eines der nächsten Dinge, in die ich mich wohl mal einarbeiten sollte...
Herzliche Grüße
Kerstin
Welche Vorgehensweise ist denn hier (bei prozeduralem Code) lege artis, um gleichzeitig den Speicher zu schonen und gute Pflegbarkeit des Codes zu erreichen?
Es gibt ein paar Faustregeln der Performace- und Speicher-Optimierung:
Du findest etliche weiterer solcher Aussagen von Informatiker*innen der ganzen Welt. Zum Beispiel dieses Zitat von Donald Knuth – einem der einflussreichsten Informatiker des letzten Jahrhunderts:
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97 % of the time: pre mature optimization is the root of all evil.
Dafür gibt es gute Gründe. Performance-Engpässe konzentrieren sich meistens auf einen sehr kleinen Teil des Codes. Es ist extrem schwierig vorherzusehen, wo diese Engpässe liegen werden, selbst für sehr erfharene Entwickler*innen. Optimiert man auf Verdacht, dann ist es eher unwahrscheinlich, dass man große Erfolge erzielt, weil man im falschen Teil des Codes unterwegs ist. Deshalb sollte man messen, um den kritischen Teil des Codes ausfindig zu machen und dann gezielt optimieren zu können. Das spart Zeit und ist wesentlich effektiver als ins Blaue zu tippen. Es löst aber auch ein anderes Problem: Optimierungen haben häufig einen negativen Einfluss auf die Lesbarkeit von Code. Wenn man also ständig auf Verdacht optimiert, dann leidet die Code-Qualität darunter sehr schnell. Die Wartung des Codes wird schwieriger, zeitintensiver und teurer. Die technischen Schulden erhöhen sich rapide, dadurch sind auch die beteiligten Entwickler*innen unzufriedner und unmotivieter.
Hallo script42,
früher hatte ich auch mal den Drang jedes kleinste Byte zu sparen und solche Möglichkeiten gesucht. Mittlerweile bin ich aber der Überzeugung, dass selbst tausende von ungenutzen Variabeln keinen großen Einfluß auf die Performance hat. Das liegt vor allem daran, weil im Hintergrund sowieso riesige Funktionen/Bibliotheken ihr Werk verichten und daher die eigenen Scripte, selten (für den Normalgebrauch) ins Gewicht fallen. Zumindest zeigen das Performanceauswertungen bisher. Das betrifft natürlich nicht grössere Projekte wie zb. ein ausgfeiltes Warenwirtschaftssystem auf professioneller Ebene oder ähnliches. Aber wenn ich deine Bestrebungen richtig verstehe, dann scheint mir diese Verschlankung unnötig, würde mich aber mal ein Test von dir interessieren bei dem du deine Inkludedateien sogar noch verhundertfachst, ob sich das irgendwie grossartig bemerkbar macht.
Gruss
Henry