Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: Webgamers. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

Fhizban

unregistriert

1

Sonntag, 4. Dezember 2016, 10:46

Wie Daten in PHP handhaben?

Mal wieder eine noob frage meinerseits, eigentlich sind es zwei:

Es geht mir grundsätzlich darum, wie relativ umfangreiche, statische (!) daten in PHP zu verwalten sind.

Dabei dreht sich alles um einen einzigen Aspekt: Geschwindigkeit.

Mir sind Iteration- bzw. Durchsuchkomfort egal.

1. Daten auf Speicherebene
Mit welchem Datentyp/Konstrukt/Objekt verwaltet man am besten grosse, statische (!) datensätze im speicher?

z.B. alle gebäudedaten. ist es besser ein array zu verwenden (welches mehrdimensional und sehr gross werden kann),
oder eine Collection oder gäbe es da noch einen ganz anderen datentyp?

2. Daten auf Dateiebene
Welches dateiformat ist am besten geeignet um umfangreiche, statische (!) daten auf dem server zu speichern?

eine reine textdatei? eine include mit variablendefinitionen, eine XMl, json?

3. Bisherige Lösung:
Eine include mit einem ziemlich umfangreichen array, im speicher somit auch als array. da scheiden sich in manchen
foren und tutorials die geister. andere behaupten das gegenteil.

ja, arrays können in PHP langsam sein, aber im vergleich zu vielen anderen datentypen sind sie doch sehr schnell.

und nichts ist schneller/einfacher als eine include.

Tipps?

Danke!

sinus

Fortgeschrittener

Beiträge: 223

Danksagungen: 55

  • Nachricht senden

2

Sonntag, 4. Dezember 2016, 11:33

Hey Fhizban,

von deinen nennungen würde ich persönlich zur speicherung der daten eine reine json-datei verwenden.
für die iteration/abfrage der daten, wäre ich mit einem objekt am liebsten aufgefahren.

Beispiel:
Abstract

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
<?php

class BuildingAbstract
{
  protected $_data = [];

  protected $_file;

  public function __construct()
  {
    if(!$this->_file) {
      throw new InvalidArgumentException("Configuration file not defined!");
    }
  }

  public function load()
  {
    if(!file_exists($this->_file)) {
      throw new NotFoundException("File '{$this->_file}' not found!");
    }
    try {
      $this->_data = json_decode(file($this->_file));
    } catch(Exception $e) {
      // Log here something ..
      throw $e;
    }

    return $this;
  }

  /* Implementation like http://www.webgamers.de/index.php?page=Thread&postID=17143 */

}


Rathaus:

Quellcode

1
2
3
4
5
6
<?php

class Rathaus extends BuildingAbstract
{
  protected $_file = 'all/my/static/files/rathaus.json';
}


So wäre ich vorgegangen ;)

gruß
sinus
loading ..

BlackScorp

Moderator

Beiträge: 1 235

Wohnort: 127.0.0.1

Danksagungen: 398

  • Nachricht senden

3

Sonntag, 4. Dezember 2016, 18:46

Hey Fhizban,

auf der Arbeit habe ich sehr gute Erfahrung mit reinen PHP Klassen gemacht die ich mittels einer Admin GUI generiere, mit einem Autoloader wird die klasse eingebunden, du kannst andere Klassen davon sogar ableiten und es wird von PHP Intern gecached. Bei statischen Inhalten die sich so gut wie nie ändern, wie etwa Konfigurationen, macht es durchaus Sinn, meiner Meinung nach
Qualität eines Codes misst man in WTF/Sekunde

Sebastian

Schüler

Beiträge: 51

Danksagungen: 27

  • Nachricht senden

4

Sonntag, 4. Dezember 2016, 20:21

Mit welchem Datentyp/Konstrukt/Objekt verwaltet man am besten grosse, statische (!) datensätze im speicher?


Kontanten. Dann wird nur der Speicherplatz benutzt, der wirklich dafür benötigt wird.

Welches dateiformat ist am besten geeignet um umfangreiche, statische (!) daten auf dem server zu speichern?

eine reine textdatei? eine include mit variablendefinitionen, eine XMl, json?



Include der Konstantendefinition :)

Fhizban

unregistriert

5

Sonntag, 4. Dezember 2016, 20:43

Danke für eure Antworten! Das ist gut damit ich mir meine Meinung bilden kann.

Im Moment schwebt mir eine Kombination aus sinus und blackscorps ansatz vor.

aber die idee von sebastian klingt äusserst verlockend.

die neueren PHP versionen können ja auch array konstanten verarbeiten (multi dimensionale arrays weiss ich gerade nicht).

ein bekannter von mir schwört auf konstanten (hat tausende in seinem projekt verbaut).

Ich würde gerne noch einige Meinungen hören, da es einen relativ grossen Umbau am Projekt erfordert.

Danke euch!

Fhizban

unregistriert

6

Dienstag, 27. Dezember 2016, 20:05

Danke nochmal!

Ich hab jetzt Sinus Idee umgesetzt und steige gerade auf JSON dateien um.

das ist flott und praktisch und später besser in einem editor/ einer admin oberfläche einsetzbar.

BlackScorp

Moderator

Beiträge: 1 235

Wohnort: 127.0.0.1

Danksagungen: 398

  • Nachricht senden

7

Mittwoch, 28. Dezember 2016, 23:57

Danke nochmal!

Ich hab jetzt Sinus Idee umgesetzt und steige gerade auf JSON dateien um.

das ist flott und praktisch und später besser in einem editor/ einer admin oberfläche einsetzbar.
Ich weiß nicht, wenn eine JSON datei zu groß wird, kriegst du Probleme mit file_get_contents und json_decode. Außerdem verschwendet JSON sehr viel Arbeitsspeicher weil es arrays benutzt, in PHP sind es nicht die optimalen Möglichkeiten Daten zu speichern.

Wie gesagt, das wirklich simpelste wäre eine Klasse zu erzeugen und dort die Werte usw rein zu schreiben, nachteil wäre, dass diese Datei dann nicht direkt liesbar von anderen wäre(zb JavaScript)

Nur halt nicht zu viel von JSON erwarten ;) auf der Seite von JavaScript ist es top, in PHP nicht wirklich
Qualität eines Codes misst man in WTF/Sekunde

Fhizban

unregistriert

8

Donnerstag, 29. Dezember 2016, 07:46

guter tipp

ich müsste es dann später in mehrere kleinere dateien runterbrechen

das mit der klasse geht nicht und includes möchte ich nicht mehr haben in dem fall, die dateien sollen importierbar, editierbar und portierbar auf einen späteren editor sein

XML wäre noch was gewesen aber da sträube ich mich dagegen da es ziemlichen overhead hat

oder ein TXT system marke eigenbau

Evtl. sollte ich noch hinzufügen:

Pro Datei werden es maximal 200 einträge mit jeweils maximal 16 attributen. manche dateien haben nur 100 einträge max mit ca. 30 attributen.


PS: so wie es jetzt aufgebaut ist, kann ich das dateiformat in kürzester zeit nochmal umstellen, das macht jetzt kaum arbeit

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Fhizban« (29. Dezember 2016, 08:23)


Sebastian

Schüler

Beiträge: 51

Danksagungen: 27

  • Nachricht senden

9

Donnerstag, 29. Dezember 2016, 08:54

Anscheinend haben sich in der Zwischenzeit die Anforderungen geändert.

Im 1. Post steht, dass du dir Geschwindigkeit wünsch und du sprichst von "große, statische Datensätzen" .


Jetzt sprichst du allerdings von veränderbaren Daten (über eine Adminkonsole) - die Daten sind aufeinmal doch nicht mehr so groß und Geschwindigkeit ist dir nicht das wichtigste...
Das ist ok und kann während der Entwicklung passieren - allerdings empfehle ich dir, bevor du jetzt da viel Zeit rein investierst - dir Gedanken zu machen, was du wirklich willst.

Fhizban

unregistriert

10

Donnerstag, 29. Dezember 2016, 09:23

naja ich schreibe ja während laufender entwicklung

1. statische daten im PHP speicher handhaben
an dieser stelle hat sich nichts geändert. auch wenn es jetzt objekte sind anstatt arrays oder konstanten
im speicher bleiben die daten statisch

2. wie kommen die daten in den PHP speicher?
anstatt datenbank werden die daten aus einer datei entnommen, darauf bezog sich der letzte post
geändert werden können dann nur die dateien bevor diese in den speicher geladen werden

auf jedenfall läuft es jetzt sehr gut soweit

es ist in der regel so, das ich durch die antworten selbst auf eine lösung komme, wenn auch nur "über eck" (danke nochmal an sinus!)

treffsichere antworten erwarte ich nicht, dazu ist der code auch viel zu groß und zu komplex

BlackScorp

Moderator

Beiträge: 1 235

Wohnort: 127.0.0.1

Danksagungen: 398

  • Nachricht senden

11

Freitag, 30. Dezember 2016, 00:47

Das Aktuelle Problem sehe ich halt bei der Umwandlung von einem Text in PHP Variablen.

Es spielt keine Rolle ob du nun XML oder JSON oder INI oder YAML oder TXT nimmst. Fakt ist, du musst 1) Die Datei von der Festplatte lesen und 2) das gelesene interpretieren und in interne Variablen umwandeln außerdem kannst du nur bedingt den Arbeitsspeicherverbrauch der Dateien kontrollieren.

Das einzige was FÜR den Format YAML/INI/TXT spricht, wäre die Menschliche Lesbarkeit. Ist aber irrelevant für dich, wenn du ein Tool oben drauf setzt um die Datei zu generieren.

Was ich sagen will. Du kannst dir auch alles sparen und das Ganze noch optimaler gestalten. Alles was du tun musst ist einen kleinen Autoloader einzubauen.

Quellcode

1
2
3
4
5
6
7
spl_autoload_register(function ($class) {
$filePath = realpath( 'config/' . $class . '.php');
if(is_file($filePath){
	require_once $filePath;
}

});


Diesen schnipsel in einer "common.php" oder so aufrufen. Und dann einfach deine Klassen im Ordner config anlegen. Der Schnispel macht automatisch ein include sobald das Wörtchen "new" im Code benutzt wird.

sprich

Quellcode

1
2
3
$buildingA = new BuildingA(); //hier wird automatisch geschaut ob die Datei config/BuildingA.php exestiert, wenn ja, dann wird diese included.

echo $buildingA->name(); //das kann schon in der Datei drin stehen


Ja die Datei ist dann nur "PHP Entwickler lesbar" aber es muss nicht umgewandelt werden in PHP Interne variablen. Außerdem wenn sich die Datei nicht verändert hat, Cached das der PHP Interpreter intern. Sprich nach einem reload der Seite wird der Inhalt nicht wieder von der Festplatte gelesen.

Du schreibst ja auch sonst nicht alle deine Variablen in eine extra JSON Datei ;)

Um die Datei dann zu erzeugen mittels einem Tool und Formular, müsstest du dann sowas machen

Quellcode

1
2
3
4
5
6
7
8
$fileContent = "<?php
class BuildingA extends BaseBuilding{

private $name = '".$_POST['name']."';

}
";
file_put_contents('config/BuildingA.php',$fileContent);



und fertig bist du
Qualität eines Codes misst man in WTF/Sekunde

Fhizban

unregistriert

12

Freitag, 30. Dezember 2016, 07:13

nargh! wenn ich das mit dem cachen von includes gewusst hätte

ok, wieder alles zurückrollen.

aber erst nächstes jahr, jetzt dann erstmal feiern!

BlackScorp

Moderator

Beiträge: 1 235

Wohnort: 127.0.0.1

Danksagungen: 398

  • Nachricht senden

13

Freitag, 30. Dezember 2016, 11:46

nargh! wenn ich das mit dem cachen von includes gewusst hätte

ok, wieder alles zurückrollen.

aber erst nächstes jahr, jetzt dann erstmal feiern!

viele frameworks machen das auch, die haben eine YAML Konfiguration, diese wird dann in ein PHP Script umgewandelt und der PHP Script wird letztendlich verwendet, gerade wegen dem OpCache. Somit hast du quasi ein Hybrid, müsstest aber jedes mal nachschauen ob die YAML Datei neuer ist als die PHP Datei, Invalidierung des Caches ist auch eine unschöne Sache die zu unschönen Ergebnissen führen kann.

Falls es dich interessiert, hier ist es schön und einfach beschreiben https://www.phpmonkeys.de/2010/01/23/opc…e-beschreibung/
Qualität eines Codes misst man in WTF/Sekunde

fkrauthan

Schüler

Beiträge: 96

Wohnort: Vancouver

  • Nachricht senden

14

Donnerstag, 5. Januar 2017, 01:40

Naja BlackScorpe was fiele Frameworks dagegen machen ist im dev modus zu checken und dynamisch neu generieren und im prod modus musst du ein Kommando aufrufen damit es neu generiert wird. Um genau dieses problem aus dem weg zugehen. Da Datei zugriff in der regel sehr langsam ist.

ulle

Fortgeschrittener

Beiträge: 228

Danksagungen: 65

  • Nachricht senden

15

Donnerstag, 5. Januar 2017, 09:42

Dateizugriff ist langsam im Verhältnis zu was ?

BlackScorp

Moderator

Beiträge: 1 235

Wohnort: 127.0.0.1

Danksagungen: 398

  • Nachricht senden

16

Donnerstag, 5. Januar 2017, 09:49

Dateizugriff ist langsam im Verhältnis zu was ?

file_get_contents ist langsamer als include, weil include in OpCache die Klasse speichert.

Es ist also eine voraussetzung die Config als eine Klasse zu hinterlegen. Die geschwindigkeit ist aber nicht sonderlich relevant, mehr der arbeitsspeicherverbrauch und selbst der ist nur relevant bei sehr großen json files
Qualität eines Codes misst man in WTF/Sekunde

Fhizban

unregistriert

17

Donnerstag, 5. Januar 2017, 10:07

Ist jetzt etwas Offtopic, aber mich hätte mal interessiert ob das cachen von "mini templates" sinn macht.

Es passt sogesehen zur Performance/Zugriff Diskussion

Nehmen wir an, es gibt hunderte von solchen Template Dateien, die im grunde nur aus 2 dingen bestehen:

1. ein fixes HTML layout
2. ein oder zwei tokens die eingeparst werden (z.b. Name und Link)

Ohne cachen wird die datei gelesen, geparst und ausgegeben.

mit cachen muss erst geprüft, dann die cache datei eingelesen und anschliessend ausgegeben werden (ohne parsen).

frage mich ob das in der praxis sinn macht.

anders wäre es, wenn die datei so aufgebaut wäre:

1. ein fixes HTML layout
2. HUNDERTE von tokens die eingeparst werden müssen

liege ich da richtig?

Carpenter

Schüler

Beiträge: 83

Wohnort: München

Danksagungen: 19

  • Nachricht senden

18

Donnerstag, 5. Januar 2017, 11:09

ich denke schon. Caching ist auch ein Thema für sich wo man tief eintauchen kann.
Da gibts viele Möglichkeiten etwas zu tun. Wie du schon sagtest kann man die dynamischen Parts aus seinem Template raus brechen und den Rest cachen, wenn die Daten stets aktuell sein müssen.
Wenn nicht, kann manauch das ganze Tpl mit dem dynamischen Content für zB ne Stunde cachen.
Wir haben mehrere Systemrelevante Teile die stets aktuell sein müssen. Dort lassen wir die html page immer dann neu generieren wenn sich etwas ändert.

Fhizban

unregistriert

19

Donnerstag, 5. Januar 2017, 17:35

so, jetzt hab ich mich heute mittag mal hingesetzt und etwas zusammengehackt.

kann das mal einer der experten hier beurteilen?

wie immer gehts mir um

1. simple solution
2. ein schneller "hack" ist mir lieber als ein wissenschaftliches dokument
3. ich verwende kein framework, lernen kann ich nur wenn ich (fast) alles selbst mache
4. nein, auch kein smarty - ist alles "verboten"!

hier ist das codestück welches sich um die templates sowie um das caching kümmert:
(die eigentlichen templating funktionen fehlen hier, weil unötig)

http://pastebin.com/4qQWnMVY

und das ergebnis sieht nun so aus:

nach dem start ist der templates folder gut gefüllt...


https://dl.dropboxusercontent.com/u/1828…s/tplfolder.png


...und besteht aus snippets wie diesem (rot markiert die geparsten tokens):


https://dl.dropboxusercontent.com/u/1828…ots/minitmp.png


und zwar aus hunderten von dieser sorte, vor allem mit mehr spielern online werden es
in kürze sogar tausende werden. aber das ist wohl nicht so schlimm.

zu guter letzt, ein auszug aus dem log, welcher beweisen soll das es auch so läuft
wie ich mir das grundsätzlich dachte:


https://dl.dropboxusercontent.com/u/1828…hots/cproof.png


die frage ist jetzt nur: ist das so halbwegs korrekt umgesetzt?

fkrauthan

Schüler

Beiträge: 96

Wohnort: Vancouver

  • Nachricht senden

20

Freitag, 6. Januar 2017, 01:56

Nein das ist garnicht gut. Dateisysteme haben riesen Probleme mit einer riesigen anzahl an dateien in einem Ordner. Du wirst da bald deinen kompletten server lahmlegen.

Ausserdem ist es normalerweise nicht noetig jede einzelne gerenderte Seite zu speichern fuer jeden user. Das macht den cache unoetig gross und braucht dann jedes mal tausende an filesystem zugriffen um das zu laden (sehr schlecht). Wie schon einige gesagt haben baue lieber eine Template Engine die nach PHP umgesetzt wird und dann include templates damit sie im OpCache sind. Zusaetzlich kannst du solltest du schwere calculationen haben (lange rechenzeit brauchen) diese mit hilfe von redis oder memcache in den memory zwischenspeichern.

Ähnliche Themen

Social Bookmarks

Thema bewerten