PHP Ausführungszeit unter 30 Sekunden, Strato behauptet 120

[Faar]

Ich habe Probleme bei der Installation von Contenido 4.8.18 auf einem Strato-Server.
Contenido-Setup behauptet, die Ausführungszeit von PHP wäre unter 30 Sekunden. Tatsächlich lief die Installation beim ersten mal nicht ganz durch und überhaupt äußerst (!) langsam.
Im Backend funktionierte dann der Wysiwyg Editor nicht richtig.
Erst bei dem nachfolgenden Update lief es durch, wieder langsam.

Der Kunde hat Strato angeschrieben und die behaupten, die max_execution_time wäre 120 Sekunden. Das Setup von Contenido behauptet nach wie vor, es wären unter 30 Sekunden.
Ich weiß von einem anderen großen Hoster, dass die Kunden teils ordentlich beschissen werden, weil die Server hart-codiert höchstens 30 Sekunden haben, egal was in PHP eingestellt ist.
Mein Kunde ist natürlich verunsichert, weil Strato ja bekannt und nicht ganz klein ist, im Gegensatz zu mir.
Dagegen wissen wir Webentwickler, dass es regelmäßig mit diesen Billighostern Probleme gibt. Diese Probleme haben wir nicht bei bei anderen Hostern, die ihre Kunden und ihre Arbeit ernst nehmen und nicht nur die Gewinnmaximierung.

Jetzt fragt sich der Kunde, ob Contenido so ein ressourcenfressendes System wäre?
Und ich frage mich, wie ermittelt das Contenido-Setup die Ausführungszeit von PHP?

Es ist jedesmal die selbe Sch**** mit diesen Hostern und regelmäßig half nur ein Umzug zu einem anderen Hoster.

[Spider IT]

Zur max_execution_time kann ich dir nichts sagen.
Ich hatte aber neulich ein ähnliches Problem bei 1&1, wo die Arbeit im Backend regelmäßig einen "Datenbank-Verbindungsfehler" produziert hat, und erst nach einer gewissen Zeit wieder gearbeitet werden konnte.
Die Auskunft von 1&1 dazu: "bei dem Paket sind max. 17 DB-Verbindungen gleichzeitig erlaubt, mehr geht nur beim vServer".

Was Strato angeht, auch die haben unterschiedliche Pakete, und einige davon sind nicht für CMSe ausgelegt (deshalb so langsam).
Ich empfehle meine Kunden immer OWLweb als Hoster, denn seine Server sind für CMSe und Shops optimiert und er packt weniger Kunden darauf (also weniger Prozessorlast = schneller).
Das gewünschte "Paket" kann man sich sogar selbst zusammenstellen, und die Kosten halten sich dann auch in Grenzen (Konfigurator, Bestelllink).

Gruß
René

[Faar]

Hi René,

bei 1&1 hatte ich auch immer wieder derartige Probleme. Kaum zieht man zu einem anderen Hoster um, sind die Probleme verschwunden. Seltsam? Eher die Regel.
Dieses Strato Paket ist alt, hatte noch PHP 4.4 am laufen. Es gibt zwar Datenbanken aber ich glaube, es war nie für modernere CMS gedacht, sondern eher für einfache "Klick-Zähler" Anwendungen.
Nun möchte der Kunde nicht auf ein teureres Paket upgraden, denn bisher lief es ja auch so.

Leider spinnt nun auch das AMR-Plugin bei der Installation.
Einmal ein falscher Wert in einer Function (wahrscheinlich NULL) und dann einige Warnings wegen in_array(), dass es der Falsche wert sei.
Wenn ich das weiter spinne, könnte die Datenbank nicht vollständig eingerichtet worden sein, denn dann gibts irgendwo keine Werte zum auslesen.
Bei der Installation blieb diese ja kurz vor Schluss hängen und ein Update lief dann endlich mal durch.

Im Zweifel müsste ich Contenido nochmal neu installieren, weil die Datenbank schon stimmen muss. Oder gibt es einfachere Wege?

[Faar]

Scheints stimmt was mit der Datenbank nicht, daher die AMR Warnings:

contenido/plugins/mod_rewrite/install.php?contenido=xxx MySQL error 1146: Table 'xxx.con_plugins' doesn't exist

Vermutlich gibt es noch mehr Überraschungen (die Error-Liste ist voll!).
Die Kundenhotline von Strato behauptete, die max_ecexution_time wäre 120 Sekunden, in deren FAQ steht aber für das kleine Paket nur 30 Sekunden drin.
Wahrscheinlich gibt es noch andere Einschränkungen, die eine Installation schwer machen (und die bieten auch noch Typo3 auf diesem Paket an!!!).
Ich muss das System nochmal komplett neu installieren bis es geht.
Jetzt habe ich wenigstens PHP 5.3 zur Verfügung. 5.5 wäre auch möglich, aber ich weiß nicht ob Contenido 4.8.18 damit fehlerfrei läuft?

[Spider IT]

Bei soviele Probleme schon bei der Installation würde ich woanders installieren, alles übertragen (auch die DB), und dann eine Migration machen.

Gruß
René

[Faar]

Jetzt beim neu Installieren lief alles viel schneller mit PHP 5.3

Jedoch macht das AMR Plugin scheints noch Probleme.
Zwar waren die Warnings dieses mal nicht da aber in der Error-Liste steht alles voll.

contenido/plugins/mod_rewrite/install.php?contenido=xxx MySQL error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TYPE=MyISAM' at line 14

Code: Alles auswählen

           CREATE TABLE con_plugins (
                          idplugin INT(10) NOT NULL default '0',
                          name VARCHAR(60) default NULL,
                          version VARCHAR(10) NOT NULL default '0',
                          author VARCHAR(60) default NULL,
                          idinternal VARCHAR(32) NOT NULL default '0',
                          url TEXT,
                          status INT(10) NOT NULL default '0',
                          description TEXT,
                          install TEXT,
                          uninstall TEXT,
                          date DATETIME NOT NULL default '0000-00-00 00:00:00',
                          PRIMARY KEY (idplugin)
                      ) TYPE=MyISAM

Statt con_plugins steht nun eine con_plugins_20130805 in der Datenbank und diese Tabelle ist leer.
In der Folge kommt natürlich dann wieder "Table 'XXX.con_plugins' doesn't exist in mod_rewrite/install.php on line 182" und "Invalid argument supplied for foreach()" und "in_array() expects parameter 2 to be array, null given in mod_rewrite/install.php on line 191"

Was läuft denn da schief?
Ich ändere den Tabellen-Namen nun manuell auf con_plugins und installiere Mod-Rewrite neu.

[Faar]

Nützt nichts, die Tabelle wird wieder mit angehängtem Datum geschrieben und bleibt leer.

[Faar]

Ich glaube der Fehler liegt darin, dass die Datenbank MySQL 5.5.31 ist und statt Type=MyISAM ein Engine=MyISAM stehen müsste.
Hab das mal umgeschrieben im Quellcode und damit lief es und gab con_plugins sowie einen Eintrag in die Tabelle.

Aber es gibt noch einige Meldungen, auch duplicate entry, vermutlich wegen der Datenbank-Version mit der AMR nicht ganz klar kommt.