Speicherverbrauch PHP Anwendungen

Chance

Chance

Member
Um es mal als eigenständige Diskussion zu eröffnen.

Zur Zeit braucht mein CMS 0.013 sec. zur Generierung und Verbraucht 1 bis 2 Megabyte Speicher.
WIe sieht es mit anderen Anwendungen aus, hat da jemand erfahrung ?
 
auf was willst du damit raus?
ist doch recht Unterschiedlich was da benötigt wird und kann eigentlich nicht verglichen werden

die frage ist doch was stellst du dar und was hat es für einen Vorteil etwas im Speicher zu behalten, eine Seitenausgabe mit echo dürfte weniger brauchen als wenn du die komplette Seite in $output pufferst und dann erst ausgibst, ob das eine oder andere für dein skript vorteilhaft ist muss man selbst wissen

ebenso macht caching auch nur Sinn wenn die Erstellung der Daten mehr zeit braucht als den cache auszulesen und ggf teile davon zu aktualisieren

XML Verarbeitung soll soweit ich das gehört hab gerne viel verbrauchen (Sprachfiles beim Import bei IPB z.b. 😀)
 
Eine typische vBulletin-Seite braucht zwischen 2 und 6 MB RAM, je nach dem. Aber das ist gepuffert, weil ich GZip eingeschaltet habe.
 
rellek' schrieb:
Eine typische vBulletin-Seite braucht zwischen 2 und 6 MB RAM, je nach dem. Aber das ist gepuffert, weil ich GZip eingeschaltet habe.
Zum Vergrößern anklicken....
Was du ansprichst ist relativ gleich, da die GZip-Kompremierung in vielen Fällen nur den Datenstrom beeinflußt, der zum Benutzer geht, aber nicht das Skript an sich und den Verbrauch, denn dies an Arbeitsspeicher hat.

Zum Verbrauch selbst ist zu sagen: Der Arbeitsspeicherverbrauch hängt von der Komplexität des Programms ab. Wie verschachtelt sind Klassen, wie groß werden Arrays, wie viele Variablen nutzt du, löscht du Variablen die du nicht mehr brauchst, was lädst du an Daten vor, lädst du große Blöcke vor (Sprachdatein) oder hast du diese Blöcke feiner gegliedert usw. Auch wie Groß die Daten sind, die du aus einer Datenbank holst spielt dabei eine Rolle.

Und 2MiB-Verbrauch von RAM und 0.013Sec für die generierung des Inhaltes sind keine schlechten Werte, hier etwas Sinnlos zu optimieren kann mehr Arbeit bedeuten, als es lohnt. Zudem ist eine Optimierung so nicht möglich, die beides zu gleichen Teilen oder stark verbessert, da man Geschwindigkeit eben bekommt, weil man viel vorlädt, oder den RAM-Verbrauch sengt, wenn man immer nur das holt was man gerade braucht. Fazit ist: Wenn du etwas stark verbessern willst, also Geschwindigkeit oder RAM Verbrauch, wird es irgendwann dazu führen, dass das andere wieder ansteigt.
 
@IT Corporation
Mit memory_get_usage()

@GameR:
Ein bischen Performance steigern und Speicher senken geht noch, da habe ich schon ein paar Ideen.
 
du solltest dein CMS halt mal mit ner ordentlichen Menge Content füllen (10.000 User, 100.000 Artikel in zahreichen Rubriken, Kategorien mit massig keywords und was das teil sonst noch verwaltet) dann siehst du ob dein Speicherverbrauch exorbitant ansteigt oder deine PGT dann plötzlich 10 Sekunden und mehr beträgt 😉
 
Das glaub ich nicht, das System sollte für diese Last geeignet sein.
Da bereits viele Optimierungen integriert sind.
 
glauben heisst nix wissen! 😉
war auch nur ne Empfehlung das mal zu testen, da Du so am ehesten siehst _ob_ Probleme auftreten - Optimierungen die beim leeren CMS schön aussehen, müssen sich unter Last nicht als solche herausstellen sondern können IMO auch gewaltig nach hinten losgehen
 
Das System ist bereits so konzepiert, das das meiste an Inhalt bereits fertig zur Ausgabe ist, d.h. BBCode wird selbstverständlich bereits beim absenden umgewandelt. etc.
Der Rest ist zwar dynamisch, aber z.T. auch so weit es geht gecacht.

Was mir nur sorgen mach, ist diw WIO funktion...
Aber auch da hab ich ne Idee ^^ 🙂 .
 
Cachen von BBCode ist manchmal sinnvoll, aber es verbraucht meist doppelt soviel Speicher, da du für das sichere bearbeiten ja die Daten vorbehalten musst.

Wie gesagt, du wirst an einem Punkt kommen, wo du entweder dein System auf wenig Arbeitsspeicherverbrauch trimmen wirst, oder auf Zeit. Lernt man relativ schnell in den ersten Vorlesungen.
 
Prinzipiell ist eine geparste Version zu cachen keine dumme Idee, denn im Verhältnis zum Bearbeiten (wo die BBCode-Version gebraucht würde), ist das Anzeigen (wo die geparste gebraucht wird) deutlich öfter. Im Regelfall wird ein Artikel ja nur einmal erstellt, vielleicht 2-3x aktualisiert und dann n mal angezeigt. Im Grossen und Ganzen fallen die paar mal, in denen die intensiveren BBCode-Versionen gebraucht und neu geparst werden müssen, in der Praxis unter den Tisch.
 
@Chance
ich denke wir reden etwas aneinander vorbei
schönes Beispiel ist hier zu lesen http://community.woltlab.com/forum/index.php?page=UserBlogEntry&entryID=12
hatte selbst schon skript die zwar relaitv leer augenscheinlich super fix waren, sobald aber eine durchaus normale Anzahl an Daten vorhanden war unendlich eingebrochen sind oder vollkommen ausgestiegen. dabei waren es teilweise nur geringeste Änderungen an einem Query oder einfach konzeptionelle Dümmlichkeiten - die durch mehrere Faktoren dann aber zum Totalaustieg führten in letzter Konsequenz

ich will dir hier auch gar nichts unterstellen, nur solltest du es (halt als tip meinerseits) mal probieren und nicht aus Gott gegebener Weisheit einfach ausschließen
 
rellek' schrieb:
Prinzipiell ist eine geparste Version zu cachen keine dumme Idee, denn im Verhältnis zum Bearbeiten (wo die BBCode-Version gebraucht würde), ist das Anzeigen (wo die geparste gebraucht wird) deutlich öfter. Im Regelfall wird ein Artikel ja nur einmal erstellt, vielleicht 2-3x aktualisiert und dann n mal angezeigt. Im Grossen und Ganzen fallen die paar mal, in denen die intensiveren BBCode-Versionen gebraucht und neu geparst werden müssen, in der Praxis unter den Tisch.
Zum Vergrößern anklicken....
Je nach System und Art ist es unterschiedlich. HTML zurück parsen zu BBCode ist sehr schwer, also müssten die Daten zwei mal vorliegen, also eine Redundanz. Zudem sind die meisten BBCodes mit einem Linearen-Arbeitsaufwand, es ist ja keine komplexe Berechnung.

Viele System speichern also einen Text in zwei Formen nur dann ab, wenn er oft frequentiert ist, ein Text der pro Tag vielleicht 1 - 2 mal aufgerufen wird macht kaum Sinn und das Kostennutzendverhältnis muss dann abgeschätzt werden. Zudem wäre es sogar eventuell ganz praktisch neben BBCode auch richtiges HTML zu erlauben für die Seiten, gute HTML-Editoren für die Benutzer gibt es ja auch und eine einfache Prüfung ob alle Texte geöffnet oder geschlossen sind, ist ebenso möglich.

Effektiv würde ich mir um Optimierungen erst Gedanken machen, wenn das System fertig ist und es dann mal in ruhe Testen. Zudem sollte man mal Blindtexte verfassen, die einige Dinge ab prüfen. Ich hab aktuell bei der WCP-Entwicklung mehrere Blindtexte bis zu einer Größe von 100 000 Zeichen usw.

Fazit ist aktuell bei deiner Seite und den Daten => Es sind normale Werte, das hatte ich sogar bei einfachen Auslesen von Daten und Ausgabe, ohne komplexe Berechnungen.

Entwickle erst mal dein System soweit fertig, dass man es dann testen kann.
 
Der Speicher und Geschwindigkeits Hauptpunkt ist das Forum im CMS, dort werde ich mal die Funktion zum Stresstest mal nutzen ^^ 😀 .

Das Rückparsen sollte eigentlich immer gehen... sonst verzichte ich lieber auf eine BBCode funktion.
Das ausführen des Parsers für den BBCode kostet ja auch Zeit...
 
Zurück parsen ist sehr schwer. Wir haben ja mit Marcel bereits öfters drüber gesprochen. Im CMS selbst würde ich eher nur HTML-Seiten ermöglichen, im Forum kannst du das BBCode System soweit nutzen das er die ersten 7 Tage und häufig aufgerufen Themen halt zwischen speichert.
 
Warum ist das zurückparsen schwierig ?
Alles folgt doch Regeln, oder ?

@IT Corporation:
Ja, aber auch an jeder Stelle, wo du es messen möchtest.
 
Chance' schrieb:
Warum ist das zurückparsen schwierig ?
Alles folgt doch Regeln, oder ?

@IT Corporation:
Ja, aber auch an jeder Stelle, wo du es messen möchtest.
Zum Vergrößern anklicken....
Es folgt Regeln, nur von BBCode zu HTML ist einfacher, als HTML nach BBCode.
 
Also ich würde - und das ist schon im zweiten Semester dran 😛 - nach der Grundlage gehen, dass man davon ausgeht, dass Festspeicher unbegrenzt vorhanden ist. Demzufolge würde ich in der Tabelle für den Content die Rohversion sowie die geparste (gecachte) speichern. Dann gewinnt man Effizienz auf Kosten des Speicherplatzes, aber das ist in dem Fall zu verschmerzen.

Generell würde ich aus der BBCode-Version immer die HTML-Version generieren, aber nur, weils nur in eine Richtung geht. Ein regulärer Ausdruck von A nach B wird auch von B nach A funktionieren, es sei denn, jemand doktert nach dem Hinweg daran herum oder es wird ein wesentlicher Teil gelöscht beim RegEx.

Beispielsweise:
[bold]Fetter Text[/bold]
sähe im RegEx ja etwa so aus:

/\[bold\](.+)\[\/bold\]/ => \\1

Daraus würde dann:
Fetter Text

Und der Rückwärtsgang sähe so aus:
/(.+)<\/b>/ => [bold]\\1[/bold]

Das aber klappt nur, wenn keiner nachträglich am HTML gefummelt hat ohne dass es ihm zusteht.
 
einen aktualisierten BBCode (weil z.b. Youtube sein Format umstellt) oder was ähnliches von [YP]*ID[YP] neu cachen ist sicher leichter als eine rule zu schreiben die aus <embed .....> dann [YP]*ID[YP] und wieder *neuer Code* macht

so lässt sich auch kurzerhand ein player austauschen oder was auch immer

man sollte nicht nur von [y] == <y> ausgehen, sondern auch von [hide] == *komplexer code*

BBcode => html halte ich für einfacher zu handeln außerdem kommen evtl irgendwann noch unterschiedliche Versionen per Stil vor, willst du diese dann on the fly nachparsen?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben