Festplattenconfig für Server für Webshop

Was heisst ganz viele? Für manche sind 10 Anfragen schon ganz viele (bspw wenn das Produkt eine Maschine für 2Mio ist und jede 5. Anfrage zum Verkauf führt). Für manche sind 100.000 ein verd.. besch.. Tag. bspw, wenn das Produkt nur 10€ kostet und die Marge bei 1% liegt.

So far, viel zu definieren (oder definieren lassen).

Dann ist es egal, solange Du nicht spezifizierst, was für Dich "viel" heißt.

lks

Und ich würde noch hinzufügen das es noch ein paar weitere Parameter gibt die relevant sind - u.a. der Speicher... DA würde ich das grössere Augenmerk drauf legen - grad Linux nutzt den ja eh als Cache wenns geht... Und wenn du nur 1000 Zugriffe parallel abfackeln willst brauchst du ja erst mal genug RAM um das zu schaffen... Dann kommts aufs Backend an - sind das statische Seiten oder laufen da noch div. Datenbanken hinter? Wie sind die ausgelegt - alles auf einem Server (bei nem Server mit "ganz vielen" Anfragen eher unwahrscheinlich) oder wie sind die Server untereinander verbunden?

Aber natürlich ist die Frage "was ist viele" ganz klar eine der wichtigsten... und dann ggf. noch WAS wird angezeigt? Ne Grafik-Agentur mit hochauflösenden Bildern direkt im Webshop braucht ggf. mehr als der reine "text-only" shop im Darkweb für nen bisserl Gras oder andere Konsumgüter :D

Ich schätze es so ein, der Dell ist oversized - außer, die Einrichtung ist ...

Sofern du es logst, ja.


Nein, Es fehlt die Angabe, wieviele Anfragen pro Zeiteinheit anfallen.

Solange die 60 Benutzer nicht dauernd neue Anfragen generieren, d.h. ganz viele pro Sekunde, ist das eher unter der Katgeorie "Langweilen der CPU und Platten" einzuordnen. Nach Deiner Rechnung sind das bei einer Anfrage pro Sekunde im Höchstfall 60x4MB =240MB pro Sekunde aber eher deutlich darunter.

lks

Ok - es hängt halt immer noch davon ab was dahinter läuft... aber generell sind 20-60 Besucher keine grosse Sache... Ich habe hier ne Software die über Webservices läuft da sind immer so 60-80 Systeme dran die Daten austauschen (dabei ist es ja egal ob es nen Mensch ist der klickt oder lustige XML-Files durchgejagt werden). Dafür reicht der "alte" Gebraucht-Server von Hetzner locker aus - ohne das es da nennenswerte Probleme gibt.

Von daher dürfte die Anforderung von jedem System bei Hetzner locker abgefackelt werden - ich würde da eher auf Support-Level gucken und ggf. überlegen ob alles auf einem Server läuft oder ob man da was macht. Ein Server würde die leistungsmässig wohl locker schaffen - nur wenn der ausfällt is halt aus... Das ist aber einfach eine Frage die nur du beantworten kannst - wie kritisch ist es wenn die Webseite mal ne Stunde oder nen paar Stunden weg ist? Bei mir wäre das ganze eben recht unkritisch - das was da an Infos ausgetauscht wird ist hauptsächlich Statistik/Monitoring, dann fehlen halt nen paar Werte... Am Ende brauch ich auch dann nicht das Monitoring - ich merke ja schon das was kaputt ist ;)

ok - das Problem an der Kiste ist -> das ist eher eine Budget-Frage... die "beste" erhälst du logischerweise wenn du nen paar dicke Load-Balancer davor packst und pro Anfrage 1 oder mehrere Server hinstellst... Dahinter dann noch nen netten DB-Cluster und du bist schon gut dabei. ABER wenn du das deinem Chef vorschlägst kann ich mir dessen "responsivness" vorstellen... Hat was mit seinem Fuss und dem Teil auf dem du normalerweise sitzt zu tun ...

Bei den Mengen von denen du da sprichst ist erst mal aufgrund der Beschreibung einfach JEDER Server ausreichend. 6-7 MB pro Minute? Selbst ne alte 3,5"-Diskette hält da mit... Selbst bei den Werten mit 60 Nutzern -> 6-7 MB/s? Da pass eher auf das du keinen Rost auf die Leiterbahnen bekommst, is ja nix drauf los...

Bei der Latenz kannst du bei den Werten auch gemütlich die Augen zu machen und schlafen. Ob du nun 5 oder 15 ms hast ist da relativ egal (es sei denn deine 6-7MB/sec setzen sich aus 1000den kleinen Dateien zusammen). Aber von den Werten die du angibst macht es einfach nichts für den Endanwender wirklich merkbares aus - der hat ja auch noch ne Datenleitung dazwischen. Ich denke nicht das es da einen Unterschied macht ob die Seite jetzt in 1 oder 2 sek aufgebaut ist... Zumal es ja nicht immer gesagt ist das der Besucher auch schon ne 100er Leitung hat - und bei 20 oder 50 mBit (oder noch weniger) brauchen die 4 MB nunmal schon ne Sekunde...

Wenn du normal von "sehr viele" redest dann dürfte dir klar sein das die meisten hier anfangen ab 1000+ Zugriffe... Du kannst natürlich die grösste Rakete hinstellen die du findest -> damit machst du erst mal nix falsch, aber du wirst halt ne Menge Geld einfach verschwenden...

Dann zähle die IOPS, die Du brauchst. Aber auch da dürfte es egal sein, weil die IOPS Von SSDs weit über Deinem Bedarf liegen. Schau danach, warum der Load hoch ist. Wenn iowait auf 0 ist, wartet die Kiste auch nicht auf die HDD/SSD. Schau mal was die NIC und was die CPU macht. Wie seid Ihr überhaupt angebunden?

lks

"Gleiche Software" ist ne Frage... Da hängt ja noch nen Unterbau, nich nur eure Seite... Wenns nen Linux ist können da z.B. Kernel-Treiber, Applikationen usw.. sein. Nicht zu vergessen das alles was neu ist auch erst mal schneller "wirkt" - und natürlich auch eine neue CPU die Applikationen auch schneller abarbeitet...Deshalb ja der Hinweis mit dem Budget -> du kannst auch nen Cluster hinstellen - du wirst merken das die Anfragen direkt erledigt sind - ABER das Zahlst du halt auch weil du mehrere Server hast...

Aber wenn er über eine Buckelpiste fahren muß, nützt auch es auch nichts, vom Golf auf einen Porsche oder Ferrari umsteigt.

Wenn die "Responsiveness" und der Load hoch ist, tippe ich mal eher auf die "Anwendung" die das Problem ist.

Dann prüfe mal Deine Datenbank, die hinter der Anwendung hängt. Die meisten DB-Anwendungen die ich kenne sind miserabel programmiert, weil die Entwickler/Hersteller sagen "kauf Dir eine größere Kiste" statt Gehirnschmalz in die Anwendung zu stecken.


Latenz von SSD ist ganz einfach: Die IOPS geben die Zugriffsgeschwindigkeit, vulgo Latenz an. d.h. bei 25.000 IOPS und mehr kannst du mindestens 100MB/s durch die Gegend jagen, selbst wenn die Dateien so defagmientiert sind, daß Du keine zwei Blöcke sequentiell lesen kannst!

Bei Deinem Anwendungsfall ist es egal, ob Du die NVME- oder SATA-SSDs nimmst. Die Bremse ist in Deiner Anwendung (vermute ich).

lks

Hallo,

bitte auch immer an die Verfügbarkeit und Skalierbarkeit denken.

Wenn so ein Server aufgrund eines Hard- oder Software-Defektes ausfällt steht halt der ganze Shop.
Das muss man gegenrechnen was das kostet.

Und bei Hetzner bekommst Du nicht innerhalb von 5 Minuten einen neuen Server.
Besonders wenn der alle 24h mal abstürzt. Kann ja auch Deine Software sein.

Bei AWS/Profitbrickts, etc kann man das alles ausblenden.

Magento, eher Apache2/NGINX skallieren mit vielen Kernen nur bis zu einem bestimmten Punkt wirklich gut.
Irgendwann kommt der Punkt wo 2 Server mit je halb so vielen Kernen schneller sind als ein Dicker.
Auch kann bei mehreren Server mit LB immer mal einer ausfallen oder gewartet werden.

Virtuelle Server kann man hoch- und runterstufen.

Bei den meisten Magentos versucht man mit brute force Konfigurations/Design-Schwächen zu kompensieren.
Ein FPC und eine optimierte Apache2/NGINX-Config ist meist viel effektiver.

Magento is a bitch.
Unheimlich hardware fordernd ohne FPC.
M1 mit Mirasvit, M2 hat schon einen FPC eingebaut.

Stefan

Wie ich schon sagte: Die Entwickler (nicht nur bei Magento) sind Stümper, die nicht wissen, wie man ressourcenschonend programmiert.

Früher (in den 80ern und 90ern) hat man als Programmierer noch gelernt, wie man optimiert oder effizienten Code schreibt, der die Hardware schont, bzw auch mit der Hardware skaliert. Irgendwann kam dann das Paradigma auf, daß das Optimieren "zuviel kostet" und doch einfach schnellere Hardware kaufen kann.

lks

Ich glaube, die Sache ist eher andersherum, es stand so viel Power zur Verfügung, dass ein singlethread immer gut lief, wenn es dann aber mehr wird, dann bricht das konstrukt. zu dem können die meisten doch gar nicht mehr Hardwareschonend programmieren. Egal ob off oder online...

Ohh ja, der war zum Teil wirklich effizient:
1978 Im Programmcode eines der ersten computergesteuerten Jagdflugzeuge, der F-16 der USA, befand sich im Algorithmus ein Vorzeichenfehler bei der Berücksichtigung der geographischen Breite. Beim Überfliegen des Äquators stellte sich das Flugzeug auf den Kopf (Zum Glück wurde der Fehler in der Simulation gefunden).
- 1980 Der Testpilot eines F/A-18 Jagdflugzeuges (US-Navy) feuerte eine Rakete ab. Der Computer öffnete daraufhin den Raketenbehälter und gab die Rakete frei, schloss ihn aber wieder zu früh. Als folge zündete die Rakete und schoss das Flugzeug steuerlos
- 1982 Bei dem Bau eines Lockheed F-117 Tarnkappenbombers wurde die Steuerung des Höhenruders mit der des Seitenruders vertauscht. Dieser triviale Softwarefehler führte zum Absturz des Flugzeuges!

--> Zumindest was die Kampfflieger angeht definitiv effizient... Immerhin 2/3 Fälle bei denen wirklich nen Vogel vom Himmel geholt wurde. Zwar der eigene aber hey, DAS stand nich in der Spec WELCHER Vogel das sein soll :D

Sind natürlich nur einige ;) Wobei das Problem heute wohl nicht den Programmierern geschuldet ist - wenn man in dem Bereich mal war sieht man wie oft die Software beim Kunden bereits als "Fertig" mit nem Liefertermin verkauft wird der bestenfalls lächerlich ist - noch bevor irgendein Entwickler überhaupt weiss das so ne Funktion überhaupt geplant ist... Zeit kannst du aber nur an 2 Stellen sparen: Weglassen von Tests und programmieren "so das es Funktioniert" - explizit nur funktioniert nicht "schön", "wartbar" oder "effizient" funktioniert. Üblicherweise hörst du dann "das machen wir wenns geliefert wurde, dann räumen wir den Kram auf" - allerdings (überraschung): Kaum bist du fertig mit einem Teil kommt wieder "Hey Leute, wir haben da nen tolles Feature überlegt... is auch schon verkauft... baut das bitte mal eben ein". Da ist eben damals auch der Vorteil gewesen -> compiler anwerfen hat idR. schon einige Minuten bis Stunden gebraucht (und idR. nix mit echtzeit-syntax-check...), da musste man sich die Zeit nehmen. Heute dauert das grad mal Sekunden - also "Try & Error".. (is aber nich nur in der SW-Entwicklung so - da nur etwas extremer weils eben oft "nachträglich" gefixt werden könnte)