[fogel]

Hallo zusammen,

kurz zum aktuellen Status: Ich betreibe ein ziemlich datenbanklastiges CMS. In den letzten Wochen sind die Userzahlen stark angestiegen und damit auch die Ladezeiten der Seiten. (25-40k IPS/Tag)
Mein aktueller Server (Opteron,2 x 1.800 MHz, 2GB RAM) ist läuft schon ziemlich am Limit. (250 gleichzeitige Anfragen an den Servre = Maximum)

Angebote meines derzeitigen Hosters bzgl. eines zusätzlichen Servers, der rein als MySQL-Server fungieren soll sind mir zu kostspielig. Dort würde man mir ein in meinen Augen ziemliches High-End System zusammenstellen .. was sich für mich allein wegen der hohen Einrichtungskosten nicht lohnt.

Jetzt hab ich andere Anbieter für managed Server aussgemacht, wo ich die selbe Hardware für weniger Geld bekomme und monatlich kündigen kann.
Da mein Projekt nicht kommerziell ist, will ich mich nicht lange binden .. dafür müsste ich bei meinem jetztigen Hoster eben draufzahlen.


Lange Rede kurzer Sinn:
Macht es Sinn, den aktuellen Server weiter als MySQL-Server, und einen neuen Server bei einem anderen Anbieter als reinen File-Server zu verwenden?
Oder wird durch die "grössere" Entfernung der beiden Server die Kommunikation untereinander zu sehr gebremst, so dass ich daduch kaum einen Vorteil hätte?


Hoffe jemand kann mir ein paar Tipps geben

Grüsse
fogel

Dieser Beitrag wurde von fogel bearbeitet: 19. Januar 2008 - 01:13

[ph030]

Hast du MySQL schonmal ein bisschen getuned? Etwas ala

set-variable	= query_cache_size=200M

? Das würde 200MB der meist gefragten Querries im RAM hinterlegen, was einen enormen Boost mit sich bringen kann - bei 2GB RAM könntest du das auch ev. noch höher stellen.

Ansonsten, möglich wäre es auch noch, den Server anderweitig zu entlasten, z.B. der Verzicht von Logs bzw. deren Beschränkung auf das Wesentliche, Variablen cachen, etc. pp.

Wenn das alles nichts bringt und du kein Verbindungslimit setzen willst, bleibt wohl nur ein weiterer Server übrig, von wo dürfte relativ egal sein, aber natürlich ist es umso besser, je näher die beiden sich sind.

Dieser Beitrag wurde von ph030 bearbeitet: 19. Januar 2008 - 09:57

[fogel]

Danke schonmal für die Tipps .. obs was bringt die logs zu deaktivieren, weiss ich nicht .. ma probiern

query cache size 268.435.456
..hab ich schon ..denke viel höher sollt ich den Wert nicht setzen


Variablen cachen habich schonmal ohne grossen Erfolg versucht.

Ich denk ich werd um den 2ten Server nicht herumkommen .. aber wenn nichts dagegen spricht, dass die Server bei verschiedenen Hostern stehen, ist das schon okay.

[[Elite-|-Killer]]

Was genau meinst du eigentlich mit "File-Server"?

Also einen Server der statische Daten wie Bilder etc. bereit stellt?

[fogel]

Zitat ([Elite-|-Killer]: 19.01.2008, 13:49)

Was genau meinst du eigentlich mit "File-Server"?

Also einen Server der statische Daten wie Bilder etc. bereit stellt?

Jawoll .. dort sollen alle php, html, Bilder und sonstige statische Files drauf .. auf den anerden nur die Datenbank.

[Yalamand]

Zitat (fogel: 19.01.2008, 01:12)

kurz zum aktuellen Status: Ich betreibe ein ziemlich datenbanklastiges CMS. In den letzten Wochen sind die Userzahlen stark angestiegen und damit auch die Ladezeiten der Seiten. (25-40k IPS/Tag)
Mein aktueller Server (Opteron,2 x 1.800 MHz, 2GB RAM) ist läuft schon ziemlich am Limit. (250 gleichzeitige Anfragen an den Servre = Maximum)

Ich gehe einfach mal davon aus das du mit der üblichen Apache/PHP-Lösung arbeitest. Der Server sollte mit gutem Aufbau und Caching an eigentlich locker 1k-2k Anfragen pro Minute schaffen. Wenn du 250 Anfragen an den Server gleichzeitig hast liegt das Problem wahrscheinlich an anderen Komponenten die es nicht schnell genug schaffen die Anfragen zu beliefern.

Generell würde ich hier folgende Tipps geben:
1) KeepAlive für den Apache abschalten oder sehr weit runterdrosseln ("blockiert" zuviele Slots auf dem Apache. Es sei denn du hast mehrere Apaches im Balancing
2) Mit Tools wie JMeter oder ähnlichen schauen welche Seiten die längste Antwortzeiten haben und anfangen dort zu optimieren.
3) GZIP oder Deflate-Komprimierung über den Apache aktivieren (nicht PHP) um die Bandbreite zu verringern und den möglichen Output zu steigern (sollte bei einem Opteron nicht zum Problem werden, aber evtl wäre hier ein Quad besser)
4) Besser cachen... Falsches oder ungenügendes Caching macht meist den Unterschied zwischen 100 Anfragen pro Minute mit 200 SQL-Abfragen und 2000 Anfragen mit 10 SQL-Abfragen pro Minute aus.
5) Nicht mysql_pconnect verwenden

Zitat

Angebote meines derzeitigen Hosters bzgl. eines zusätzlichen Servers, der rein als MySQL-Server fungieren soll sind mir zu kostspielig. Dort würde man mir ein in meinen Augen ziemliches High-End System zusammenstellen .. was sich für mich allein wegen der hohen Einrichtungskosten nicht lohnt.

Generell zum Thema MySQL-Server-Upgrade: Sicher, den MySQL-Server dediziert zu halten ist immer ein guter Rat. Aber es ist immer zu beachten das sowohl der Web- als auch der MySQL-Server immer im gleichen Netz sein sollten und am besten direkt via einem oder mehrere Netzwerkkabel verbunden sind. Eine Abfrage über "weitere" Strecken ist zwar Möglich, macht aber nur im Sinne der Replikation Sinn. Nicht um Anfragen zu beschleunigen.

Zitat

Lange Rede kurzer Sinn:
Macht es Sinn, den aktuellen Server weiter als MySQL-Server, und einen neuen Server bei einem anderen Anbieter als reinen File-Server zu verwenden?
Oder wird durch die "grössere" Entfernung der beiden Server die Kommunikation untereinander zu sehr gebremst, so dass ich daduch kaum einen Vorteil hätte?

Effektiv hättest du keinerlei Vorteile. Auch Dinge wie der Query-Cache sind mit Vorsicht zu genießen, als auch zuviele oder falsche Indizes auf dem MySQL-Server. Der Query-Cache mag zwar helfen wenn viele gleiche Anfragen kommen, aber ganz ehrlich, das sollte dein PHP-Caching übernehmen. Das braucht weniger Rechenleistung und den Query-Cache zu erneuern kostet den MySQL-Server auch Zeit, ebenso das neue aufbauen der Indizes. Ebenso ist es nicht gerade ein toller Sicherheitsaspekt wenn dein MySQL nach außen geöffnet werden müsste, bedeutet auch Aufwand die Firewall auf beiden Rechnern richtig einzustellen etc. Auch würde ich das slow-query-log vom MySQL aktivieren und schauen welche Anfragen dort landen... diese Queries genau anschauen mit EXPLAIN, warum sie langsam waren. Kann sein das der Query okay ist, aber meistens sind genau diese der Ursprung von vielen Performance-Problemen.

Auch würde ich eine Performance-Messung für PHP einbauen um zu schauen wie lange PHP braucht um eine Seite zu erstellen. Dauert es 0.5 oder mehr Sekunden um eine Seite aufzubauen gilt es hier zu optimieren. Ziel wäre es auf 0.05 oder kleiner zu kommen, es sei denn es sind wirklich Abfragen auf SQL notwendig (da ist 0.2 oder mehr nicht zu vermeiden).

Auch würde ich dir wirklich raten das Caching zu überprüfen (es ist wirklich nicht schwer), dann andere "Beschleuniger" zu testen wie z.B. den PHP-APC. Aber generell... wenn deine Startseite bei einem Besuch eines Gastes erstmal 1-10 SQL-Abfragen machen muss ist was falsch gelaufen. SQL-Abfragen sollten nur dann kommen wenn ein Inhalt sich geändert hat (was effektiv extrem selten ist) und niemanden interessiert ob das was er sieht nun top-aktuell ist oder 5 Minuten alt. Außnahmen bilden natürlich Live-Ticker oder Foren... aber selbst hier gilt die Devise: Schreiben bei Änderungen, nicht bei Anfragen. Wenn 100 Benutzer das Forum aufrufen ist genau eine SQL-Abfrage notwendig um den Inhalt des Forums darzustellen. Erst wenn einer der 100 Posted muss erneut eine SQL-Abfrage gestartet werden um den Inhalt neu darzustellen. Das wären dann 2 SQL-Abfragen in 100 Besuchern.

Generell würde ich auch nur die statischen Dateien abspalten um sie auf einen dedizierten Server zu legen. Grafiken, PDFs und sonstiges gerne immer auf einen eigenen Server (der auch weit weg stehen kann) und über Subdomains verlinken. Die PHP-Dateien aber immer auf dem eigentlichen Host lassen. Auf dem statischen Server kannst du auch ruhig testweise mal Keep-Alive erlauben, aber auch mit niedrigen Einstellungen. Damit werden die Grafiken gut und schnell geladen, aber der eigentliche Server unter Last muss nur eine PHP-Datei zusammenstellen und ausliefern ohne das weitere Slots blockiert werden.

Dieser Beitrag wurde von Yalamand bearbeitet: 26. Januar 2008 - 15:22