THEMA: Turniere erstellen

Danke....
ich habe einige Änderungen in der Konfiguration des Akeeba vorgenommen und es dadurch dazu bringen können, dass es erfolgreich zu Ende läuft. Ich denke nicht, dass deine Änderungen bzgl. robots.txt und Sprachen, einen Einfluß auf das Laufzeitverhalten von Akeeba hatten. Ich kann auch gerne meine Anpassungen in Akeeba zurücknehmen, dann sehen wir das.

Akeeba wird viel eher tangiert, von Bremsen die durch das Webhosting kommen. Ich vermute es ist ein kleineres Webhostingpaket, das zu wenige Sekunden CPU-Laufzeit und eine zu geringe Memorygrösse zur Verfügung stellt. Kann das sein? Dadurch reicht der Platz und die Zeit nicht aus um ein Komplett-Backup einzusammeln und zu zippen.

Ein erster erfolgreicher Schritt auf dem Weg war es, als nach weglassen (exclusion) eines größeren Verzeichnisses (quickstart-simplex - das bringt über 25 MB mit in die Ehe...) das Akeeba-Backup zu Ende lief. Dadurch blieb die Sicherung unter dem magischen Limit von 64 MB. Es fehlte dann aber eben dieses Verzeichnis in der Sicherung.

Eine Begrenzung der einzelnen Laufzeiten und ein Splitten des Archivs (geht alles in der Akeeba-Konfiguration zu machen) half letztendlich - auch ohne weglassen von Dateien und Verzeichnissen - eine Komplettsicherung durchzuführen

Es wäre interessant zu wissen, welche Parameter (max. CPU-Zeit und max. Memory) das jetzige Webhosting-Paket mitbringt und es wäre bei sehr kleinen Werten zu Überlegen ob man nicht vielleicht auf ein etwas größeres Webhosting-Paket wechselt. Das käme wohl auch der dynamischen App zu gute - schnellerer Zugriff, schnellerer Seitenaufbau,... und damit ein besseres Verhalten in den Augen des Benutzer

Hallo Pierre,

max_execution_time 60 Sekunden CPU Zeit, bzw. 120 Sekunden abs. Laufzeit

memory_limit 128 MB

Beste Grüße
Bernd

das hört sich erstmal gut an.
Das Problem: das passt nicht zu den Beobachtungen bei Akeeba.
Erst nachdem ich in Akeeba festlegte dass nach 50 MB gesplittet werden soll, lief Akeeba durch. Ansonsten war immer bei 64 MB Zapfenstreich.

diese Werte (128 MB + 60 CPU-sek.) bietet einerseits der Provider ?
und das ist andrerseits auch so in der php.ini verdrahtet ?
(es reicht nicht in der php.ini etwas stehen zu haben, was der Provider nicht bietet, und andrerseits hilft es auch nicht, wenn der Provider viel bietet, es aber in der php.ini limitiert wird - das hatten wir beides schon... deshalb die Frage)

Laufen in dem Webhosting-Paket ggf. noch andere Auftritte, Domains,... mit denen sich diese App die Kapazitäten teilen muss? Oder ist dies die einzige App?

Hallo Pierre,

nein, das hat schon seine Richtigkeit und Strato ist ja nicht gerade ein NoName Provider.
Wie gesagt, mit Akeeba gab es unter einer früheren CLM Installation auf einer ehemaligen Vereinsseite nie Probleme bei mir.
Hast du schon eine Idee, warum die ganz oben beschriebene Fehlermeldung beim Anklicken verschiedener Menüpunkte kommt (sie kommt ja nicht bei allen, z.B. "Liga erstellen" öffnet sich ganz normal und mit dem CLM 2.5 gab es diese Probleme ja nicht.

Herzliche Grüße und vielen dank für Deine Bemühungen
Bernd

Hallo Pierre,

Ich habe jetzt mal die ganze Jomla Installation wieder entfernt und neu aufgespielt.
Dann den CLM 3.2.1 installiert und ausprobiert und es läuft problemlos.
Auch das Akeeba Backup funzt.
Das Problem lag vermutlich darin, dass ich die Migration zu Joomla 3.4 nicht gelesen hatte.
Stattdessen ging ich völlig falsch so vor :
- Update auf die neueste Joomla-Version
- dann Aufspielen von CLM 3.2.1 über die alte CLM-Version
Als es dann nicht ging, hatte ich zwar den CLM wieder komplett entfernt und neu installiert, aber vermutlich blieb irgendwas noch in der Joomla-Installation hängen, sodass es nicht funzte, also mein Fehler ( Wer lesen kann...).
Also Ende gut alles gut, sorry, dass ich dir unnötige Arbeit machte und herzlichen Dank dafür.
Bernd

Danke. ok...
Zu Akeeba... das geht jetzt. Aber jetzt ist die zu sichernde Datenmenge noch klein. Vermutlich um die 20 MB. Da gibt kaum bis nie Probleme...

Es gibt die Chance, dass es bei einer zu sichernden Datenmenge ab 64 MB wieder zu Abbrüchen bei der Sicherung kommen kann. Dann sollte man sich daran erinnern, dass sich das recht einfach durch 2-3 Konfigurations-Einstellungen in der Akeeba-Komponente justieren lässt, dass die Sicherung wieder durchläuft. (Man kann diese Einstellungen - zumindest was das "split-archive" betrifft, natürlich problemlos auch jetzt schon vornehmen.)

Das wichtigste ist die Spliteinstellung für das Archiv.
Zu finden in der Akeeba-Konfiguration und dort unter "Archiver Engine" - da hinten dran ist ein Button "configure".
Wenn man auf den klickt, gibt es die Möglichkeit "part size for split archives" einzustellen. Es gibt dort vordefinierte Werte. mit etwas unter 50 MB kann man zumeist gut leben. (default ist da ein riesiger Wert von knapp 2 GB (2.047,52 MB) eingestellt, dass eben das Archiv nicht gesplittet wird. )

Das ist die wichtigste und immer wirksame Variante.


Auch noch in der Akeeba Konfiguration, etwas weiter nach unten scrollen, in der Rubrik "Fine Tuning" lässt sich noch etwas tun. Diese Daten werden bei der automatischen Konfigurationserforschung (sollte man unbedingt gleich nach der Installation von Akeeba durchlaufen lassen...) schon mal vorfestgelegt.

Aber bei manchen Providern werden nicht die optimalen Werte erkannt. Wenn es zu Problemen bei der Sicherung kommt, kann man versuchen mit Anpassungen an der minimum und maximum execution time das zu verbessern
viel Erfolg