Verwendetes Hosting Paket: LARGE
Vorzüge (v.A. in Bezug auf Contao):
- Unlimitierter Datenverkehr
- Unlimitierte Subdomains
- Multidomainfähig 1
- Unlimitierte Postfächer
- Unlimitierte Emailadressen
- MySQL 5.6
- PHP 5.3 - 7.0 (frei wählbar)
- Apache 2.4
- SSH Shell 2
- Crontab/Cronjobs
Weitere Eigenschaften:
- memory_limit = 256M 3 (soweit getestet auch garantiert)
- max_execution_time = 180
- max_input_time = 180
- post_max_size = 256M 3
- upload_max_filesize = 256M 3
- mod_filter
- mod_deflate
- mod_rewrite
Auf der Suche nach einer Alternative zu günstigen Webhosting Angeboten bei Hostern wie Hetzner, 1&1, Domainfactory und Co. bin ich auf easyname gestoßen - ausnahmsweise mal ein Österreichischer Hoster . Meine Mindestanforderung war ein Hosting Paket mit 256 MiB RAM und SSH Shell Access - und siehe da, gleich ins Auge gefallen ist mir bei easyname letzteres. Auch die restlichen Angaben hörten sich natürlich gut an.
1 Bei easyname kann man außerdem problemlos beliebige Domains auf beliebige Pfade zeigen lassen. Verschiedene DocumentRoots für verschiedene Domains sind also auf jeden Fall möglich. Darüberhinaus können externe, nicht im eigenen easyname Account verwaltete Domains hinzugefügt werden - ohne Aufpreis (bei 1&1 bspw. zahlt man für sowas ja extra...). Beim hinzufügen von externen Domains muss man aber verifizieren können, dass man selbst Zugriff zu dieser Domain hat. Das kann man über drei verschiedene Varianten machen - entweder kurzfristig den Nameserver der Domain ändern, eine spezielle Subdomain anlegen, oder einfach eine bestimmte Datei anlegen, die dann im Root der externen Domain abrufbar ist.
2 Für den Einsatz von Contao im Zusammenhang mit der Composer Paketverwaltung ist der SSH Zugriff natürlich ideal. Über die Shell lässt sich ein composer update problemlos durchführen, wenn bspw. der Speicher über die Backend Funktion nicht reicht, oder bei sonstigen Problemen. Was jedoch schade ist: die PHP Funktion exec() bzw. shell_exec() ist aus Sicherheitsgründen gesperrt. Dadurch funktioniert auch der 'detached' Modus ("In einem eigenen Prozess") der Paketverwaltung nicht. Durch den SSH Zugriff ist das prinzipiell kein Problem, praktisch wäre es aber dennoch, wenn man ein speicherhungriges Composer Update auch über das Backend anwerfen könnte. Mal sehen, vielleicht kann ich die Betreiber noch überreden .
3 Laut Support sind die Werte memory_limit, post_max_size, upload_max_filesize fixiert, eben auf 256 MiB. Ob bspw. die max_execution_time verändert werden könnte habe ich noch nicht getestet. 256 MiB sind für ein günstiges Hosting Paket nicht schlecht - bei einer Website konnte aber selbst mit 256 MiB kein composer update (im 'inline' Modus) durchgeführt werden.
Die Response Time bzw. PHP Processing Time ist eher durchschnittlich. Auf einer Website liegt die Zeit bis zum first byte auf der Startseite zwischen ~1500ms und ~2000ms - pauschal kann da natürlich keine Aussage getroffen weren, da es ja darauf ankommt, wieviele Module und Inhaltselemente etc. für die jeweilige Seite prozessiert werden müssen. Bei aktiviertem Seitencache ist die response time ~150ms.
Vorsicht: by default ist für das Hosting Paket auch ein Varnish Cache aktiv (und auf 3 Minuten gesetzt). Das kann beim PHP debuggen stören. Weitere Tests habe ich damit aber noch nicht gemacht.