Wieviele Seitenaufrufe schafft mein Server?

S

Subsonix

New Member
Hallo,

ich habe einen dedizierten Rootserver mit folgenden Eckdaten:

Opteron 1210 HE (Dual-Core)
1GB RAM
SuSE 10.1
Apache/2.2.0

Hat jemand Erfahrungswerte wieviele Seitenaufrufe pro Monat so ein Server ungefähr schaffen kann?

Damit meine ich typische HTML-Seiten, die aus PHP mit MySQL Datenbankzugriff generiert werden (ohne Caching). Ich weiss, dass es sich nicht genau sagen lässt und sehr von der Anwendung abhängt, aber nur einen groben Richtwert? 1 Mio., 10 Mio., 100 Mio., PIs?

Gibt es eine Möglichkeit, dass irgendwie zu messen oder zu ermitteln?

Evtl. kann mir jemand mit einem vergleichbaren Server auch sagen, was dieser Server so "aushält".

Gruß,
Subsonix
 
Ausser meiner Kristallkugel kann niemand dir eine Antwort geben ;)
Nichtmal ein grober Richtwert.

Du hast nicht einmal Festplatte/Anbindung/PHP+MySQL Versionen/Konfiguration spezifiziert.
Es wird dir nichts anderes übrig bleiben, als deine Website laufen zu lassen und dann nach und nach zu tunen. Sollte es immer noch zu langsam sein fragst du hier.

Zum Messen: Für die Server Auslastung empfehle rrdtool. Und für die Aufrufe kannst du jedes Auswertungstool nehmen, wie z.B. webalizer.
 
Von der reinen CPU-Leistung hält die Kiste einiges aus. Wenn du allerdings eine Datenbank mit 2 GB Workingset hast, hast du ein Problem, dann fährst du die Maschine mit I/O an die Wand.
 
Erstmal vielen Dank für die Anregungen.

Hier noch ein paar Details:

250 GB Festplatte (7.200 U/min)
Apache 2.2.0 mit mod_php
PHP Version 5.1.2
MySQL 5.0.18

Das ganze ist eine ziemliche Standardkonfiguration von Strato, ich habe keine Optimierungen vorgenommen.

Der Server steht im Strato Rechenzentrum mit 100Mbit/s Anbindung.

Wäre gut, wenn sich jemand mit vergleichbarer Maschine melden könnte.
 
Last edited by a moderator:
1 Seitenaufruf/Sekunde wird der Server wohl schaffen. Könnten aber auch 2 oder 4 sein.

1 x 60 x 60 x 24 x 30 = ~2,5 mio Seitenaufrufe/Monat oder ~ 85.000/Tag

Reine HTML Seiten sind nicht das Problem, da schafft der Server 400.000/Tag.
 
Last edited by a moderator:
noto said:
1 Seitenaufruf/Sekunde wird der Server wohl schaffen.
1 x 60 x 60 x 24 x 30 = ~2,5 mio Seitenaufrufe/Monat oder ~ 85.000/Tag
Click to expand...

Ich würde zugerne wissen wo dir diese Antwort eingefallen ist...

Also wenn du eine kompetente Antwort willst, mach selbst einen Test mit "ApacheBench" kurz "ab". Den Benchmark hast du in den apache2-utils dabei und starten kannst du ihn lokal sowie remote (z.b. kleine Debian VM daheim, anderer Server).

Eine Testsyntax wäre
Code: 
ab -n 1000 -c 10 http://www.serversupportforum.de/
Das wären 10 simultane und insgesamt 1000 Requests.

Der Benchmark zeigt dir, wie lange die Requests brauchen. Ein ungetunter Apache sollte schnell in die Knie gehen (10000ms und mehr).
 
Der Test gibt bei mir aus:

Concurrency Level: 10
Time taken for tests: 11.543779 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 47975000 bytes
HTML transferred: 47523000 bytes
Requests per second: 86.63 [#/sec] (mean)
Time per request: 115.438 [ms] (mean)
Time per request: 11.544 [ms] (mean, across all concurrent requests)
Transfer rate: 4058.46 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 3.4 0 40
Processing: 19 113 71.2 96 721
Waiting: 8 75 56.9 62 626
Total: 19 114 71.5 96 721

Percentage of the requests served within a certain time (ms)
50% 96
66% 118
75% 139
80% 148
90% 191
95% 236
98% 340
99% 388
100% 721 (longest request)
Click to expand...

Das heißt 10 simultane Requests verkraftet er? Das wären dann nach noto's Rechnung 10x mehr, will heißen 25 Mio. PI pro Monat (bei gleichmäßiger Verteilung, Lastspitzen nicht berücksichtigt). Könnte das in etwa hinkommen?
 
Du hast jetzt nichts anderes gemacht als 1000 mal deine Webseite aufgerufen, wobei maximal 10 gleichzeitige Verbindungen aufgemacht werden und dann hast du eine schöne Übersicht bekommen wie lange die Aufrufe gedauert haben. Die Rechnung ist absoluter Blödsinn. Umso mehr Verbindungen, umso mehr Speicher, umso mehr Auslastung, umso langsamer, bis die Seiten nicht mehr "flüssig" ausgeliefert werden. Klar kannst du auch mit dem Benchmark schauen, wann der Server an die Grenzen kommt. Du musst dafür aber die Anzahl der gleichzeitigen Aufrufe erhöhen.
 
Subsonix said:
Das heißt 10 simultane Requests verkraftet er? Das wären dann nach noto's Rechnung 10x mehr, will heißen 25 Mio. PI pro Monat (bei gleichmäßiger Verteilung, Lastspitzen nicht berücksichtigt). Könnte das in etwa hinkommen?
Click to expand...

Der Benchmark muss natürlich richtig angewendet werden.
Nehmen wir an du hast 1 Website auf dem Server die schätungsweise "300 User online" im Counter anzeigt.
Die gängigen Counter liefern die IPs der letzten 5min und je nach Website (viel/wenig zu lesen, AJAX, Flash) entspricht das in der Praxis 20-30 gleichzeitigen Connections. Dies testest du nun mit ApacheBench und wenn die Requests zu lange dauern musst du optimieren.
Um an Erfahrungswerte heranzukommen eignet sich wie bereits erwähnt rrdtool.

Aber bitte rechne das nicht hoch. Es ist unrealistisch anzunehmen, dass eine Website konstant frequentiert wird. Es gibt je nach Zielgruppe und -land gewisse Stoßzeiten, die für dich interessant sind und genau da hilft der ApacheBench das Maximum zu bestimmt und zu erhöhen.
 
Subsonix said:
Der Test gibt bei mir aus:

Percentage of the requests served within a certain time (ms)
50% 96
66% 118
75% 139
80% 148
90% 191
95% 236
98% 340
99% 388
Click to expand...
Click to expand...

Nicht schlecht, ich hab letzthin solche Tests auf einer Testumgebung gefahren, meine 98% lagen im besten Fall bei 2.8 Sekunden. Und keine parallelen Anfragen. Und stärkere CPUs.

(Zugegeben: Die abgerufenen Seiten waren etwas komplexer ...)

Subsonix said:
Das heißt 10 simultane Requests verkraftet er? Das wären dann nach noto's Rechnung 10x mehr, will heißen 25 Mio. PI pro Monat (bei gleichmäßiger Verteilung, Lastspitzen nicht berücksichtigt). Könnte das in etwa hinkommen?
Click to expand...

Nein, überhaupt nicht. Du misst nur die Startseite. Das ist sicherlich in keiner Weise repräsentativ.

Weiterhin solltest du definieren, was für dich erträgliche Abrufzeiten sind (2 Sekunden vielleicht). Dann kannst du solange die Anzahl der parallelen Requests hochdrehen, bis die 99% bei ungefähr 2 Sekunden steht.
 
mein benchmark (rootDS, 500 Mhz, 256 MB RAM)

ab -n 1000 -c 15 http://www.domain.com

HTML Seite mit PHP Script (Zend Optimizer) benötigte 99% 336 ms (CPU load ~ 1,35)

und bei Wordpress Blog mit MySQL 99% 3728 ms! (CPU load ~ 3,8)

Das ist 11 mal länger. :(
 
Last edited by a moderator:
1000 Requets pro Verbindung ist viel zu viel - zumindest bei meinen Seiten.

Seite hatt HTML Datei, 40 JPG Bilder, 1 x PHP Counter Script + 1 x schreiben in MySQL, 1 x PHP Script welches paar mal in TXT Dateien schreibt. Dürften zusammen ~ 50 - 100 Requests/Verbindung sein.

hab nun ~ 25 mal ab -n 100 -c 200 gemacht 99% mit ~ 800 ms und dann kam 'no buffer space available'

Lasse ich ab -n 100 -c 100 auf meinen Wordpress Blog los 99% ~ 5000 ms, sind die privvmpages im roten Bereich! Laut Tuning-Primer Script, hat MySQL den max zugeteilten RAM (87 MB) verwendet.

Hab jetzt ab -n 100 -c 50 mit max_connection = 50 und key_buffer, sort_buffer, read_buffer wesentlich verkleinert. 99% 8000 ms, privvmpages weit über roten Bereich. rofl

!

und nochmal mit ab -n 100 -c 50, keine reduzierten buffers, aber weniger max_connections = 5 und habe nun 99% ~ 2200 ms, privvmpages im grünen Bereich! (key_buffer + sort_buffer + read_buffer) x max_connections = RAM)

mein rootDS rockt :)
 
Last edited by a moderator:
Und wie kriegt man raus, wie viele User im normalfall etwa bei dem DS3000 von Hetzner gleichzeitig laufen ?

Würde Apache 2.2, PHP 5.2.2 ( als fastcgi wahrscheinlich, da ispCP ( The home of IspCP Omega a VHCS fork ) das normalerweise so handhabt ) und mySQL 5.0.32 laufen bzw. halt die letzte stable dann.

Also 200 User gleichzeit beispielsweise, ist das realistisch ?
 
Kommt auf die Seite drauf an. Eine statische HTML Seite wird er sicherlich geschmeidig ausliefern. Bei Web 2.0 Anwendungen oder anderweitig rechenintensive Seiten (Heavy-Load PHP, Datenbankzugriffe etc.) kommt es eben drauf an, wie gut die gecodet sind.
 
httpd.conf (Apache) + my.cnf (MySQL) Variables würde ich erstmal leicht optimieren. my.cnf mittels tuning-primer.sh Script.

Dann CPU u. RAM Auslastung beobachten und schauen wie sich der Server im täglichen Betrieb verhält.

Solange genug RAM vorhanden ist, ist es kein problem die my.cnf Variables zu erhöhen (grössere buffers, caches, mehr max_connections). Wenn der RAM knapp wird, dann würde ich httpd.conf und my.cnf weiter optimieren u. anpassen.

mit
Code: 
top
sieht man ja ob httpd CPU o. RAM überlastet. Wenn httpd Prozesse den RAM o. CPU überlasten, würde ich Apache optimieren.

Wenn Forum o. Blog immer noch langsam ist, würde ich my.cnf Variables (MySQL) optimieren (siehe auch tuning-primer.sh Script). Zuerst würde ich Buffers u. Caches erhöhen, wenn RAM knapp wird, max_connections verkleinern.

Apache u. MySQL Performance Tuning

100 Seitenaufrufe mit max 2000 ms wird dein Server wohl schaffen, vielleicht auch 200. Kannst ja selbst testen mit
Code: 
ab -n 100 -c 200 http://www.name.de/
in den letzten Zeilen vom Benchmark sollte 99% < 2000 ms sein.

200 Seitenaufrufe : 2000 ms (2 s) = 100 Seitenaufrufe pro Sekunde x 60 x 60 = 360.000 pro Stunde rofl

mein Vorschlag:

httpd.conf Konfiguration
Code: 
Timeout 30
KeepAlive On
MaxKeepAliveRequests 1000
KeepAliveTimeout 2

in die my.cnf schreibst du
Code: 
key_buffer = 24M
sort_buffer_size = 4M
read_buffer_size = 8M
query_cache_size = 2M
thread_cache = 8
table_cache = 512

max_connections = 15
long_query_time = 2
log_slow_queries=/var/log/mysqld.slow.log
MySQL nimmt sich dann bis zu ~ 540 MB RAM. Wenn tuning-primer.sh Script sagt, key_buffer ist zu gross, dann würde ich den natürlich kleiner machen! Also, immer schon schauen was tuning-primer.sh sagt.

Formel ist
Code: 
key_buffer + (sort_buffer + read_buffer) x max_connections = RAM
wichtig ist, dass tuning-primer.sh Script nicht über zu kleine Buffers, Caches ect. meckert.
 
Last edited by a moderator:
Zusammenfassung:

1. httpd.conf optimieren

2. my.cnf näherungsweise optimieren

3. tuning-primer.sh Script laufen lassen und my.cnf Variables optimieren/anpassen

MySQL z.B. 512 MB RAM zur Verfügung stellen.

Formel:

max_connections = (RAM - key_buffer) : (sort_buffer + read_buffer)

max_connections = 512 M - 24M : (4M + 4M)

max_connections = 488 : 8

max_connections = 61
 
Last edited by a moderator:
Ich will jetzt nicht klugscheissen, sondern nur der Verständlichkeit halber nochmal nachfragen.

Zwei mal würde Punkt vor Strichrechnung gelten, also würde aus
max_connections = RAM - key_buffer : (sort_buffer + read_buffer)
Click to expand...
Code: 
RAM - (key_buffer / (sort_buffer + read_buffer))
Ist das so gewollt?
 
You must log in or register to reply here.
Back
Top