[Visitors] Version 3.6.0

[BugBuster]

Eine neue Version ist online.

• Erkennung von Windows 10 und Browser Edge
• Erkennung von Samsung Galaxy S4, S5, S6 inkl. jeweils Active, Mini, Zoom und Edge/Edge+ bei S6

[soweit_ok]

Sehr cool, danke!

[Znrl]

Kann sein dass die Botdetection jetzt (>4) ziemlich viel speicher braucht?

Ich habe auf einem 1und1 Webspace mit etwas über 80MB memory_limit Visitors, efg und eine Metamodels-auswahl (also kein Bundle) per Composer installieren und updaten können.
Das funktioniert jetzt nicht mehr.
Genauer ist es nicht direkt Botdetection sondern largebrowsercap oder so.
Ich hab das dann eben lokal geupdated und hochgeladen.
Allerdings ist jetzt auch der Botdetection Ordner unter system/modules dank dem botdetection/cache Ordner, der irgendwie 60MB+ verbraucht (auch browsercap) fast ein drittel der gesamten Contaoinstallation.
Das macht bei meiner DSL 2000er Leitung (zum Glück bald mehr) spaß beim uploaden :P.

Stellt sich mir nur die Frage ist das so gedacht? Soll das so sein?

[BugBuster]

Ja leider, der Platzverbrauch ist enorm gestiegen. Nach dem ersten Aufruf bzw. durch die runonce wird dann noch ein Cache generiert der nochmal soviel Platz braucht bzw. auch massenweise Dateien generiert. Vorteil dadurch ist aber die sehr schnelle Suche in den Signaturen.

Aber RAM Verbrauch sollte nicht das Problem sein. Maximal durch erzeugen des Caches. Aber da Composer allein schon 80-100 MB braucht, zumindest bei mir, sollte das kein Problem sein, denn das generieren des Caches erfolgt erst anschließend. (crossjoin/browscap ist eine externe Klasse die über Composer nachgeladen wird als Abhängigkeit)

Ich hatte auch schon überlegt den generierten Cache mitzuliefern, aber das wäre der Wahnsinn bei den Massen von Dateien.
Daher liefere ich nur die ini Datei mit, woraus der Cache generiert wird.

[BugBuster]

Versuch wäre, composer als Unterprozess laufen zu lassen (System -> Einstellungen -> Composer-Einstellungen)
inkl. "Enable profiling".
Dort wird als Parameter ja der RAM Wert mit angegeben.

[BugBuster]

zur Auslieferung könnte ich natürlich die ini Datei Zippen, das wären dann nur 2 MB statt 44 MB.
Und dann per runonce / Modul auspacken.

[Znrl]

Im Eigenständigen unterprozess funktioniert es auch nicht ((allocated 85196800) (tried to allocate 20 bytes))
Bei einer andern Installation bin ich jetzt auch erstmal beim alten Botdetection geblieben, da ich hier sowieso kein Composer installiert hab.

Im Xampp gibt die gleiche Konfiguration
[65.6MB/34.67s] Memory usage: 65.63MB (peak: 91.33MB), time: 34.67s (die Dauer liegt an der schlechten Internetverbindung nehme ich an)
aus.
Mir stehen da eben nur offiziell 81MB zur verfügung, was mich auch schon länger nervt.

Das mit dem zippen ist aber ne gute Idee das spart im Upload einiges an Zeit.

[BugBuster]

Versuche da mal einen höheren RAM Wert anzugeben.

[Znrl]

?
Bei 1und1 geht das nicht, das ist halt bei dem Hostingpaket so, da ich das nicht zahle kann ich da auch nichts machen. Wenn dann würde ich eh zu nem andern Anbieter.

Lokal im Xampp funktionierts ja (habs dort glaub ich auf 512MB), das zeigt nur dass es vergleichsweise knapp ist. Die Botdetection Änderungen, mit mehr Abhängigkeiten könnten schon diese ~10MB ausmachen, wegen dem es jetzt nichtmehr geht. Es war vorher auch schon knapp. Meine Hoffnung liegt bei Metamodels stable^^.

Hab gesehen, dass du das ja auch in nem Issue selbst anmerkst, dass das dadurch deutlich mehr Speicher braucht.
Diverse hoster hängen beim memory_limit halt nen paar jahre hinterher.

Ich mach die Updates jetzt halt lokal und sync dann auf den Server... ist sogesehen eh besser/sicherer :P.

[BugBuster]

Hab ne Möglichkeit gefunden die largebrowscap.ini von 44MB auf 820 KB zu verkleinern, ohne zu zippen.
Den RAM Verbrauch von Composer senkt das zwar nicht aber das Paket wird deutlich kleiner und der Cache generiert nicht mehr in 7 Sekunden sondern <1 Sekunde.