Checken: Online-Shop mit Drupal/Übercart, in den User große Datenmengen hochladen können

Dateien liegen bei Drupal im Dateisystem und nicht in der DB.

Entweder hast Du Dich verschrieben oder ich mich verlesen:
- Die Dateien sind im Schnitt 100MB groß
- 128MB (?) sollen reichen?

128MB für jeden einzelnen Apache-Thread. Ja das wäre Ok.
128MB für da gesamte Linux? Vergesse es.

Du musst mal überlegen: Um 100MB-Datei per Post hochzuladen braucht es auf der Serverseite etwa genausoviel RAM für den Apache-Prozess (oder war es doppelt soviel?).
Das hat weder mit Drupal, PHP oder Apache zu tun, sondern liegt schon im HTTP-Protokoll.

Ich glaube bei den Angaben geht einiges durcheinander. Was sollen denn z.B. 32 MB für MySQL sein? 32 MB Datenbankgröße im Filesystem? 32 MB Nutzdaten? 32 MB RAM für den MySQL Deamon? 32 MB für alle Buffer zusammen? 32 MB pro Thread?

...

Hallo narres,

vielen Dank für die schnelle Antwort. Wie groß die Dateien jetzt exakt sind, können wir nicht im Voraus sagen. Es handelt sich um Druckvorstufe-Daten, die naturgemäß sehr groß werden können.

Bzgl. der Skalierung eines Linux-Server habe ich leider keinerlei Erfahrungswerte -- daher sind die Angaben vielleicht auf den ersten Blick unlogisch.

Also, wir haben ein Angebot erhalten, einen Managed Server-Account/Reseller-Account zu mieten, auf dem uns eben (maximal) 128 MByte Arbeitsspeicher zugeteilt wird. Hm ... Scheint also sehr eng zu werden ...

Beste Grüße
web_worker

Die 32 MByte beziehen sich auf den Eintrag der Produktbeschreibung: "PHP-Memory (optional erweiterbar) 32 MByte".

Beste Grüße

Mit einem PHP Memory Limit von 32 MB wirst du nicht weit kommen. Du findest hier genug Posts von Leuten, wo auch 64 nicht reichen. Man kann es aber nicht im Vornherein genau beziffern, weil die Anforderung sich sehr individuell aus eingesetzten Modulen, Theming, etc. ergibt. Man merkt, dass es nicht reicht, wenn der berühmte WSOD, der White Screen of Death auftaucht.

auch schon an der schmalen und meist nicht ohne Probleme erweiterbaren Limitierungen.

Für 100MB hochzuladen braucht es:

- php_value post_max_size 200M
- php_value upload_max_filesize 100M

sonst geht da gar nichts.

100M einfach hochposten ist auch gar nicht so trivial. Bricht beim Hochladen etwas ab oder bleibt wegen Timeout hängen: Dann Ende!

Selbst bei einem 1MBit Upload sind das immerhin noch 1200 Sekunden oder 20 Minuten für 100MB ohne Fortschrittsbalken oder sonstwas. Den User, der da nicht mehrmals STRG-R oder F5 drückt, der muss mir noch begegnen :)
Mit jedem F5 multipliziert sich das für den Server an Ressourcen.
Benutzer mit einer "normalen" Leitung sitzen da dann eine Stunde und wissen nicht, ob sich noch was tut.
Als Drumherum für den Upload und auch für Drupal, gibt es zwar gant nette JavaScript/Flash-Kombinationen, was aber nicht darüber wegtäuschen sollte, dass HTTP nicht zum Austausch größerer Datenmengen konzipiert ist.

Sinnig wäre da ein FTP-Upload und ein Scannen des Folder aus Drupal heraus. Z.B.

Vielen Dank für die Hilfe -- so sehr ich auch googel und rumfrage, aber Erfahrungswerte bzgl. solch eines Shops sind schwer zu finden. Das größte Problem scheint wohl der große Upload zu sein.

Ich versuche mit dem Hoster folgenden (virtuellen) Server auszuhandeln.

- 1 GByte RAM
- ca. 35 GByte Speicher
- php_value post_max_size 200M
- php_value upload_max_filesize 100M

Haben wir uns ehrlich gesagt auch schon überlegt, aber verworfen. Wir möchten den Kunden auch eine Bestellhistorie anbieten, über die sie schon bestellte Produkte nochmals bestellen. Gerade bei Briefpapier, Visitenkarten, Unternehmensbroschüren bietet sich so etwas ja an.

Den Upload werde ich wohl mit einem Übercart-kompatiblen Upload-Modul machen und schauen, dass ich im Upload-Fenster einen Hinweis (Upload dauert länger, bitte nicht F5 drücken) und ein Fortschrittsbalken "irgendwie" einbaue. Also, der Shop ist mittlerweile durchgeplant und ich komme damit auch sehr gut voran.

Nur der Upload und die Server-Anforderungen bereiten mir nach wie vor Kopfzerbrechen. Ich bin daher für weitere Tipps sehr dankbar.

Schau mal http://drupal.org/project/image

Vergiss nicht auch über eine Backup-Strategie nachzudenken...

Hhhm, ich denke mal die

sind der Festplattenplatz insgesamt. Sagen wir mal dovon bleiben 30 GB für Uploads nutzbar.

Meine Rechnung:
5 * 100MB / Bestellung = 0,5GB / Tag
5 * 0,5GB / Tag = 2,5 GB / Woche (Sa + So wird nicht gedruckt :) )
4 * 2,5GB / Woche = 10 GB / Monat
:= nach 3 Monaten ist die Platte voll?

Hallo,

nochmals vielen Dank für eure Hilfe. Bzgl. des Plattenspeichers mache ich mir jetzt noch nciht so viele Gedanken. Sollten wir den Server mieten, können wir relativ kostengünstig Plattenspeicher mit mehreren Hundert GByte nachrüsten. Das Problem ist aus meiner Sicht immer noch der Upload.

Ich habe mir gerade ein paar Gedanken bzgl. der FTP-Lösung überlegt. Das Problem sehe ich hier eher, dass wir eine per FTP hochgeladene Datei nur schwer in einen Übercart-Node integrieren können. Auch habe ich diesbezüglich des Datenschutzes etwas Bauchschmerzen. Nehmen wir einmal an, zwei verschiedene Kunden laden beide ihre Dateien per FTP hoch und sollen dann mit dem Image-Modul ihre Daten in einen node/Übercart zuordnen. Wie kann ich sicher sein, dass die Kunden nur ihre Dateien zu sehen bekommen? Die würden doch dann alle öffentlich hochgeladenen Dateien zu sehen bekommen.

Lösung, bei der ich nicht weiß, ob das logisch überhaupt funktioniert:

- Kunden können mit einem Modul in Drupal im öffentlichen FTP-Root-Verzeichnis ein eigens Unterverzeichnis erstellen. Dieses Unterverzeichnis wird mit einem Passwort geschützt, das der Kunde über sein Drupal-Nutzerkonto erhält. Jeder Kunde erhält so sein eigens passwortgeschütztes FTP-Verzeichnis.

- Das öffentliche FTP-Root-Verzeichnis ist für Gäste(=Kunden) schreibgeschützt. Der Kunde gibt nun sein persönliches Passwort via FTP-Client und erhält damit Zugriff auf sein FTP-Unterverzeichnis.

- Der Kunde lädt seine Daten via FTP hoch.

- Der Kunde kann dann in Drupal mit Image auf sein (und nur auf sein!) FTP-Unterverzeichnis zugreifen.

Hm ... Ob das möglich ist?

Ich bin jetzt offline, aber melde mich auf alle Fälle morgen noch einmal!

Beste Grüße

Ganz grob:

- Jeder User hat einen eigenen FTP-Acc und sieht auch nur den.
- Die weisen dann nach files/user1 bis files/userX
- Aus denen werden die Images importiert und als Image-Node verwaltet
- Die Image-Nodes werden dann mit einem Produkt (eigentlich der Bestellung) verknüpft

Also praktisch der Benutzer besttlt ein T-Shirt (UberCart-Produkt) und wählt als Bild einen Image-Node (technisch als Verknüpfung).

Man müsste mal antesten, ob das IMCE-Modul da nicht besser integriert als das Image-Modul.

Hallo,

Gut, allein schon wegen der FTP-Accounts werden wir wohl einen managed (virtuel) Server mieten müssen. Aber ansonsten ist diese Vorgehensweise wohl die erfolgversprechenste.

==> Kann ich eigentlich auch mit Drupal für jeden neuen User einen FTP-Account anlegen?

Sonst ist meine nicht(!) praxiserprobte Vorgehensweise:

- Neuer User meldet sich via Drupal an und erhält ein neues User-Konto
- Bei einem neuen User-Konto wird über das Modul "actions" ein PHP-Script gestartet. Oder das Script wird über Cron gestartet.
- Das PHP-Script legt in site/files einen neuen Ordner an (Verzeichnisname = Username)
- PHP-Script legt neuen FTP-Account auf dem Server an (FTPuser=DrupalUsername, FTPPass = Drupalpasswort)
- User erhält Daten per Nachricht
- User kann kleiner Daten über Web-Interface, größere Daten per FTP hochladen
- User kann dann mittels Image oder IMCE Daten einer Bestellung zuordnen

Daran grüble ich dann noch ein wenig:

- Cron prüft regelmäßig, ob User sein Passwort geändert hat, falls ja, wird auch das FTP-Passwort geändert

Beste Grüße

Nachtrag: Wird aber wohl ein Kuddelmuddel bzgl. der Rechteverwaltung werden. Die Mitarbeiter (erhalten keine Adminrechte in Drupal und auch nicht auf dem Server) müssen dann ja an die FTP-Daten der USer gelangen. Muss ich mir noch überlegen, wie die Mitarbeiter ohne Root-Rechte an diese Daten kommen können.

Ja, Backup ist eingeplant. So wie es aber aussieht, werden wir wohl einen Server mieten müssen. Dort ist dann ja meist schon eine Backup-Funktion dabei. Ansonsten gibt es dafür ja meines Wissen viele Module.

Beste Grüße

Es gibt zwar oft eien Backup-Option, aber oftmals mauss man sich selbst drum kümmern welche Daten wie und wann gebackupt werden. Auch die Größe des zur Verfügung stehenden Platzes ist oft kleiner als die Festplattenkapazität..

Was die Anbindung an den FTP Server angeht musst du entweder selbst was stricken oder schaust in die Röhre. Vor allem bei Managed Servern hat man als Kunde in der Regel gar keinen Zugang mit entsprechenden Rechten um auf dererlei Konfigurationsdetails Einfluss zu nehmen. Die praktische Umsetzung hängt auch stark von der benutzten Admin-Oberfläche ab. Evtl. kann man darüber anbinden, evtl. muss man auch zu Fuß FTP Accounts erstellen. Das kann Bedeuten System-User anzulegen, das kann auch bedeuten das Ganze über die Datenbank machen zu können. Alles schwer abhängig von den Gegebenheiten auf dem Server.

Klärt vorher ab ob und wie euer Hoster bei dererlei Gepfriemel bei einem Managed Server mitspielt. Diese sind meist so knapp kalkuliert, dass für kundepszifische Einstellungen kein Platz ist.