Hallo,
ich muss gerade eine Django Webseite ans Netz bringen und muss das per Webhsoting tun (ich benötige damit keine Vorschläge für VPS oder Dedicated, um das gleich vorwegzunehmen). Nun habe ich folgende Anbieter gefunden:
http://djangoeurope.com/
http://pyrox.eu/webhosting/
https://www.aditsystems.de/webhosting_basic.php
(Serverstandort ist anscheinend bei allen auch Deutschland)
Von djangoeurope habe ich eigentlich schon gehört, dass es nicht schlecht sein soll. Wie stehts mit pyrox und aditsystems, hat da jemand Erfahrung?
Djangohosting
Pyrox.eu macht ein Freund von mir, der ansich durchaus Ahnung davon hat. In Anbetracht dessen, dass das ganze nur über Email bzw Telefon abgewickelt werden kann, würde ich sagen, dass es ein kleiner aber feiner Anbieter ist, der auch Kundenwünschen nachkommt und bei Problemen ein offenes Ohr hat. Einziger Minuspunkt für mich wäre, dass er kein Trafficlimit ausweist und kein Postgres anbietet (mal fragen warum eigentlich 
)
)-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Tja, Djangohosting tut das schonapollo13 hat geschrieben:ein Postgres anbietet (mal fragen warum eigentlich
Andererseits muss man sich dafür das Python 2.6 selbst kompilieren...My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Ich bin einer der drei Gesellschafter von PYROX und möchte ganz kurz darauf eingehen:apollo13 hat geschrieben:(...) Einziger Minuspunkt für mich wäre, dass er kein Trafficlimit ausweist und kein Postgres anbietet (mal fragen warum eigentlich
1.) Warum kein Trafficlimit?
Das Limit ist versehentlich bei einem Update der Webseite verloren gegangen. 100 GiB/Monat sind inklusive. Ich habe die Seite korrigiert und das Traffic Limit wieder angegeben. Wichtig ist hierbei, dass es sich um ein Soft-Quota handeln. d.h. Wir kontaktieren bei Überschreiten dieser Grenzen unseren Kunden und bitten darum entweder das Datenvolumen zu reduzieren (z.B. entfernen riesiger populärer Downloads), oder mit uns einen neuen Vertrag auszuhandeln, falls dauerhaft mehr Transfervolumen benötigt wird.
Da die Volumen sehr großzügig bemessen sind, sollte keine normale Webseite (Shop, Blog, Fotogallerie, etc.) diese Grenzen sprengen. Falls dies doch einmal passieren sollte (z.B. durch einen Eintrag bei Slashdot), dann ist dies für uns kein Grund nach der Kostenpeitsche zu greifen. Sowas kommt vor und gehört zum Hosting dazu.
Alle Limits, die wir angeben, sind übrigens Soft-Quotas.
2.) Warum kein PostgreSQL?
PostgreSQL bieten wir für das Shared Hosting nicht mehr an, da wir viel Wert auf Redundanz und Ausfallsicherheit legen. PostgreSQL bietet leider bis heute keine Clustering Lösung, die für Shared Hosting tauglich ist (*), so dass wir im Rahmen der Umstellung auf das neue PYROX Clustered Hosting dazu gezwungen waren auf MySQL zu migrieren. Um ACID zu gewährleisten bieten wir als Storage Engine InnoDB an.
Auf Nachfrage bieten wir sehr wohl PostgreSQL an und könnten sogar Clustering bieten. Das ist leider mit den kostengünstigen Shared Hosting Tarifen vom Basishosting nicht machbar.
(*) Ich kann gerne darauf eingehen, warum die verfügbaren Clustering Lösungen von PostgreSQL für Shared Hosting nicht ausreichen, aber das geht dann ein bisschchen Off-Topic.
-
jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Das würde mich schon interessieren, auch wenn es ein wenig Offtopic ist.mp hat geschrieben:(*) Ich kann gerne darauf eingehen, warum die verfügbaren Clustering Lösungen von PostgreSQL für Shared Hosting nicht ausreichen, aber das geht dann ein bisschchen Off-Topic.
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Dito. Wir haben auch ein Offtopic-Forum, dort würde es auch passen.jens hat geschrieben:Das würde mich schon interessieren, auch wenn es ein wenig Offtopic ist.mp hat geschrieben:(*) Ich kann gerne darauf eingehen, warum die verfügbaren Clustering Lösungen von PostgreSQL für Shared Hosting nicht ausreichen, aber das geht dann ein bisschchen Off-Topic.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Wir stellen gerne Test-Accounts zur Verfügung. Hierzu reicht es uns per E-Mail zu kontaktieren.
WSGI läuft z.Zt. wie folgt:
1. Es gibt für jede konfigurierte Domain ein dediziertes /wsgi/ Verzeichnis in das WSGI Dateien abgelegt werden können.
2. Per .htaccess und mod_rewrite können bestimmte Anfragen auf das jeweilige WSGI Script weitergeleitet werden.
Zum Neuladen der Anwendung reicht es das WSGI Script zu touchen. Da wir selbst Django Entwickler sind leisten wir auch gerne Hilfestellung für das Deployment und stellen Beispiele zur Verfügung.
In Zukunft planen wir auch entsprechende Assistenten für die Erzeugung der WSGI Dateien anzubieten. Für die Konfiguration setzen wir die Eigenentwicklung WEBCONF ein, die sich z.T. noch in Entwicklung befindet.
Bzgl. PostgreSQL habe ich unseren Datenbank-Cluster-Spezialisten gebeten kurz zu beschreiben, warum die derzeitigen PostgreSQL Clustering Lösungen für unser Sharer Hosting in Frage kommen. Da ich das selbst nicht so intensiv evaluiert habe kenne ich nicht alle Details so gut.
WSGI läuft z.Zt. wie folgt:
1. Es gibt für jede konfigurierte Domain ein dediziertes /wsgi/ Verzeichnis in das WSGI Dateien abgelegt werden können.
2. Per .htaccess und mod_rewrite können bestimmte Anfragen auf das jeweilige WSGI Script weitergeleitet werden.
Zum Neuladen der Anwendung reicht es das WSGI Script zu touchen. Da wir selbst Django Entwickler sind leisten wir auch gerne Hilfestellung für das Deployment und stellen Beispiele zur Verfügung.
In Zukunft planen wir auch entsprechende Assistenten für die Erzeugung der WSGI Dateien anzubieten. Für die Konfiguration setzen wir die Eigenentwicklung WEBCONF ein, die sich z.T. noch in Entwicklung befindet.
Bzgl. PostgreSQL habe ich unseren Datenbank-Cluster-Spezialisten gebeten kurz zu beschreiben, warum die derzeitigen PostgreSQL Clustering Lösungen für unser Sharer Hosting in Frage kommen. Da ich das selbst nicht so intensiv evaluiert habe kenne ich nicht alle Details so gut.
Wir haben unser Datenbank-Backend Anfang 2008 geplant. Ziel war es jede Kundendatenbank jederzeit mindestens 1x repliziert zu haben. Im Notfall muss also sofort mindestens ein Standby-Server als neuer Master für den Kunden parat sein. Da wir diesen Service "intern" als Bestandteil unseres Notfallplans ansehen sollte das alles möglichst ohne Performance-Verluste und ohne zusätzliche Limitierungen für den Kunden passieren. (Trigger, SP, Views, etc.) Im Hinblick auf Backups brauchen wir weiterhin genug Flexibilität um Kunden-DBs aus verschiedenen Master->Slave Clustern in dedizierten Backup-Systemen zusammenzuführen. Dort können wir Snapshots und Dumps erzeugen ohne den laufenden Betrieb zu stören (Performance und Locking-Probleme). Replikationsketten und Kaskaden machen hier einiges erst möglich...
Nehmen wir nun mal unser typisches SharedHosting Szenario für Kunden mit BasisPaket: Pro Kunde 5 Datenbanken, die Datenbanken können vom Kunden frei benannt, gelöscht oder auch angelegt werden. Schemas sind somit frei editierbar. Täglich kommen User hinzu oder werden gelöscht. Alles in allem ein relativ dynamisches Szenario für das viele Replikations-Lösungen nicht ausgelegt sind. Damals war das der Hauptgrund warum viele (von denen als "stable" / "producion-ready" deklarierte) Postgres Replikations-Lösungen rausgefallen sind. Übrig blieben... "drei Varianten"... von Third-Party Postgres Replikatoren: (1) Interessante Vorschläge mit "proof of concept" Implementierung im Alpha Status, (2) Stabile aber extrem aufwendige Lösungen die eine gewisse Infrastruktur voraussetzen, (3) Mehrere "Bastellösungen", meist von 1-2 Entwicklern gepflegt, quasi ohne Dokumentation und mit der Zusage selbiger 1-2 Entwickler, dass die Sache stabil läuft.
(Zu (2) muss man noch sagen, dass die stabilen Sachen meistens nur mit relativ uralten Postgres Versionen zu gebrauchen waren...)
Wir waren eigentlich von Anfang an pro-Postgres, allerdings muss man sich folgendes vor Augen halten: Während wir also verschiedene dieser Implementierungen unter die Lupe nahmen (und teilweise versuchten aus Code und Code-Kommentaren schlau zu werden...) released Sun MySQL 5.1 GA.
MySQL hat seit geraumer Zeit (...Jahren...) Statement-basierte Replikation integriert. Die Implementierung hat etliche QA-Cycles durchlaufen und hunderte Bugfixes erlebt. 5.1 kommt mit Row-Based- und Hybrid Replikation sowie einigen Features daher, deren Abwesenheit für einen PostgreSQL User eigentlich immer ausschlaggebend war, bei Postgres zu bleiben...
Während wir also veschiedene Postgres Server mit diversen Lösungen im Test haben (und schon einige Rückschläge erlebten was die Recovery angeht) setzte ich zwei MySQL Server (derzeit tatsächlich aus Neugierde) auf. Dank der guten Dokumentation und der guten Integration lief das Setup nach 30 Minuten.
Lange Rede kurzer Sinn... MySQL hat alle unsere Test-Szenarios überlebt. Kompliziertere Replikations-Fehler konnten alle mit den Tools rund um die Binlogs behoben werden (ohne immer wieder einen kompletten Dump neu zu laden).
Das ganze Binlog+Relaylog Design wurde immer klarer und ebenso die riesige Flexibilität die man dazu geschenkt bekommt -- Ganz im Gegensatz zu einigen von den zuvor angetesteten Postgres Lösungen.
Die Entscheidung ist eigentlich erst nach einigen Tagen MySQL Dokumentation lesen gefallen. Man darf nicht vergessen, dass die Datenbank nur ein Puzzle-Teil unseres Hostings ist, und wir müssen als kleines Startup realistisch bleiben. MySQL war mit allen Features und der unschlagbaren Dokumentation zur richtigen Zeit am richtigen Ort, und PostgreSQL war leider enttäuschend. (Dazu kommt, dass Replikation anscheinend ein Hassthema in #postgresql ist...)
Mittlerweile haben wir eine bessere Infrastruktur und könnten uns tatsächlich wieder Gedanken um ein neues Setup machen, bei dem wir auch PostgreSQL anbieten. Ausserdem gibt es ein paar Interessante Projekte und Entwicklungen (Tungsten, http://archives.postgresql.org/pgsql-ha ... g00913.php , Lösungen in Kombination mit DRBD, etc.) die man mal wieder unter die Lupe nehmen könnte. Das wollen wir auch nicht abstreiten...
Auf der anderen Seite haben wir von 100 Kunden maximal 2, die gerne PostgreSQL hätten. Die Beweggründe sind dann meistens sehr Klischee-behaftet aus Zeiten in denen MySQL tatsächlich in einigen Aspekten... sehr fragwürdig war. Ich kann nur jedem raten aktuelle Versionen zu Vergleichen und immer an die verschiedenen Storage Engines zu denken. Sehr oft wird genau das vergessen und es werden falsche Ansprüche an eine Storage-Engine gestellt, die tatsächlich für ganz andere Zwecke optimiert is...
Realistisch gesehen bringt uns PostgreSQL momentan nur Mehraufwand ohne überzeugende Vorteile. Deshalb bieten wir kein PostgreSQL für die BasisPakete. Die geringe Anzahl der Anfragen nach PostgreSQL spricht für sich. Falls sich an dem Verhältnis was ändert sind wir als alte PostgreSQL Fans aber gerne bereit die Sache nochmal zu überdenken.
Nehmen wir nun mal unser typisches SharedHosting Szenario für Kunden mit BasisPaket: Pro Kunde 5 Datenbanken, die Datenbanken können vom Kunden frei benannt, gelöscht oder auch angelegt werden. Schemas sind somit frei editierbar. Täglich kommen User hinzu oder werden gelöscht. Alles in allem ein relativ dynamisches Szenario für das viele Replikations-Lösungen nicht ausgelegt sind. Damals war das der Hauptgrund warum viele (von denen als "stable" / "producion-ready" deklarierte) Postgres Replikations-Lösungen rausgefallen sind. Übrig blieben... "drei Varianten"... von Third-Party Postgres Replikatoren: (1) Interessante Vorschläge mit "proof of concept" Implementierung im Alpha Status, (2) Stabile aber extrem aufwendige Lösungen die eine gewisse Infrastruktur voraussetzen, (3) Mehrere "Bastellösungen", meist von 1-2 Entwicklern gepflegt, quasi ohne Dokumentation und mit der Zusage selbiger 1-2 Entwickler, dass die Sache stabil läuft.
(Zu (2) muss man noch sagen, dass die stabilen Sachen meistens nur mit relativ uralten Postgres Versionen zu gebrauchen waren...)
Wir waren eigentlich von Anfang an pro-Postgres, allerdings muss man sich folgendes vor Augen halten: Während wir also verschiedene dieser Implementierungen unter die Lupe nahmen (und teilweise versuchten aus Code und Code-Kommentaren schlau zu werden...) released Sun MySQL 5.1 GA.
MySQL hat seit geraumer Zeit (...Jahren...) Statement-basierte Replikation integriert. Die Implementierung hat etliche QA-Cycles durchlaufen und hunderte Bugfixes erlebt. 5.1 kommt mit Row-Based- und Hybrid Replikation sowie einigen Features daher, deren Abwesenheit für einen PostgreSQL User eigentlich immer ausschlaggebend war, bei Postgres zu bleiben...
Während wir also veschiedene Postgres Server mit diversen Lösungen im Test haben (und schon einige Rückschläge erlebten was die Recovery angeht) setzte ich zwei MySQL Server (derzeit tatsächlich aus Neugierde) auf. Dank der guten Dokumentation und der guten Integration lief das Setup nach 30 Minuten.
Lange Rede kurzer Sinn... MySQL hat alle unsere Test-Szenarios überlebt. Kompliziertere Replikations-Fehler konnten alle mit den Tools rund um die Binlogs behoben werden (ohne immer wieder einen kompletten Dump neu zu laden).
Das ganze Binlog+Relaylog Design wurde immer klarer und ebenso die riesige Flexibilität die man dazu geschenkt bekommt -- Ganz im Gegensatz zu einigen von den zuvor angetesteten Postgres Lösungen.
Die Entscheidung ist eigentlich erst nach einigen Tagen MySQL Dokumentation lesen gefallen. Man darf nicht vergessen, dass die Datenbank nur ein Puzzle-Teil unseres Hostings ist, und wir müssen als kleines Startup realistisch bleiben. MySQL war mit allen Features und der unschlagbaren Dokumentation zur richtigen Zeit am richtigen Ort, und PostgreSQL war leider enttäuschend. (Dazu kommt, dass Replikation anscheinend ein Hassthema in #postgresql ist...)
Mittlerweile haben wir eine bessere Infrastruktur und könnten uns tatsächlich wieder Gedanken um ein neues Setup machen, bei dem wir auch PostgreSQL anbieten. Ausserdem gibt es ein paar Interessante Projekte und Entwicklungen (Tungsten, http://archives.postgresql.org/pgsql-ha ... g00913.php , Lösungen in Kombination mit DRBD, etc.) die man mal wieder unter die Lupe nehmen könnte. Das wollen wir auch nicht abstreiten...
Auf der anderen Seite haben wir von 100 Kunden maximal 2, die gerne PostgreSQL hätten. Die Beweggründe sind dann meistens sehr Klischee-behaftet aus Zeiten in denen MySQL tatsächlich in einigen Aspekten... sehr fragwürdig war. Ich kann nur jedem raten aktuelle Versionen zu Vergleichen und immer an die verschiedenen Storage Engines zu denken. Sehr oft wird genau das vergessen und es werden falsche Ansprüche an eine Storage-Engine gestellt, die tatsächlich für ganz andere Zwecke optimiert is...
Realistisch gesehen bringt uns PostgreSQL momentan nur Mehraufwand ohne überzeugende Vorteile. Deshalb bieten wir kein PostgreSQL für die BasisPakete. Die geringe Anzahl der Anfragen nach PostgreSQL spricht für sich. Falls sich an dem Verhältnis was ändert sind wir als alte PostgreSQL Fans aber gerne bereit die Sache nochmal zu überdenken.
-
jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Danke für das Statement. Sehr interessant.
btw. ihr solltet euch mal hier eintragen: http://wiki.python-forum.de/Python%20Webspace
btw. ihr solltet euch mal hier eintragen: http://wiki.python-forum.de/Python%20Webspace