sykerjoe
Anmeldungsdatum: 4. März 2011
Beiträge: 89
|
Morgen miteinand Apache: Apache/2.2.14 Ich probiere gerade unsere Apache Installation zu optimieren, und bin dabei auf ein Benchscript gestoßen http://sourceforge.net/projects/abgraph/files/abgraph/abgraph%201.1/abgraph-1.1.tar.gz/download ... kennt jemand ähnliche Sachen? wie optimiert ihr euren Apache? Ich wäge ab, ob ich fastcgi oder fcgid verwenden soll für unseren Webservice ( RequestTracker ) hat da jemand nen Tipp für mich? grüße sykerjoe
|
agaida
Anmeldungsdatum: 24. Februar 2010
Beiträge: 3348
Wohnort: Bielefeld
|
Auch wenn es jetzt richtig arrogant klingt. Du brauchst keinen Benchmark, Du brauchst nur jede Menge Zeit, eine Testmaschine und, falls Eure Site ein wenig größer ist, noch ein paar Leute zum Testen und Fixen. (Das nur so aus eigener Erfahrung, deshalb bin ich zu Linux gekommen. Ich brauchte schnell mal einen Apachen. Das war vor knapp 2 Jahren, langsam weiss ich, was ich tue.) Wenn die Sache bis jetzt vernünftig implementiert ist, dann könnte das mit Tests in 1-2 Stunden durch sein, falls bei Euren Applikationen oder im Aufbau des Servers geschweint wurde, bekommst Du Spass. Dann darfst Du Dich erst mal in das Rechtesystem und die Sicherheitsmechanismen von PHP einarbeiten (und wie das durch verschiedenen Applizierungsmodelle angesteuert wird). fastcgi kannst Du knicken, fcgi ist erstmal der Weg für die nächste Zeit. Das positive ist, dass das eigentlich nur richtige Probleme mit PHP geben wird. Der Nachteil ist, dass das den Großteil der Probleme ausmachen dürfte. Wenn Du dir einen Gefallen tun möchtest, pack das auf eine Migrationsmaschine und gut ist's. Wenn die läuft, kurz auf diese welche umschalten und die eigentliche Arbeit machen und zurückschalten. Und dann kann man anfangen, die einzelnen Komponenten des Konstrukts der Reihe nach abzuarbeiten.
|
Roger_Wilco
Anmeldungsdatum: 11. August 2010
Beiträge: 224
|
agaida schrieb: fastcgi kannst Du knicken, fcgi ist erstmal der Weg für die nächste Zeit.
Wie kommst du darauf?
|
agaida
Anmeldungsdatum: 24. Februar 2010
Beiträge: 3348
Wohnort: Bielefeld
|
Schau mal auf die Aktivitäten in der Entwicklung und die Lizensierung und die Aussagen im Netz darüber. Nur weil etwas existiert, heisst das nicht, dass man es auch einsetzen sollte. Über das Für und Wider mag man streiten, eventuell bietet sich ein Besuch im debian oder ubuntu irc an. Im Endeffekt bin ich 2009 die damals noch jüngeren Pros und Cons durchgegangen. Soviel scheint sich nicht geändert zu haben. Ich empfand es als sehr unangenehm, mich mit diesem Thema in epischer Breite auseinandersetzen zu müssen. Da ich erst ubuntu- und jetzt debian-server einsetze und fast unisono fcgi favorisiert wurde und wird, habe ich das dann eingesetzt. Da sind auch noch ein paar Kleinigkeiten mit suexec. Wenn man sich damit ernsthaft auseinandersetzt, dann hat das einige Vorteile. Die eigenen Konfigurationen werden, wenn man die gefundenen Sachen einsetzt und testet, besser. Geichzeitig verbessern sich die eigenen Mittel und Möglichkeiten, der zu erreichende Performancegewinn ganz ohne Benchen ist nicht zu verachten. So ungefähr wollte ich das mit der Zeit verstanden wissen. Wenn man sich dann noch in das Thema Performance-Steigerung php, MySQL (oder andere DB) und Möglichkeiten des Cachings einliest, dann wird am Ende auch was von. Das ist aber immer auch ein Gesamtkunstwerk, bei dem eine beschissen aufgesetzte Komponente einem die Performance des Gesamtsystems nachhaltig kaputtmachen kann. Von daher wird es wohl den einen "Mach-mich-glücklich"-Benchmark, der einem gleich auch noch alle eigenen Fehleinstellungen liefert, nicht geben. Ein wenig was zum Lesen ohne Anspruch auf Wahrheit, Gültigkeit etc. Als Einstieg ins Thema sollte es aber zur Lieferung für Schlagwörter für tiefergehende Recherche ausreichen. hier ganz am Ende der Hinweis
|
Roger_Wilco
Anmeldungsdatum: 11. August 2010
Beiträge: 224
|
agaida schrieb: Schau mal auf die Aktivitäten in der Entwicklung und die Lizensierung und die Aussagen im Netz darüber. Nur weil etwas existiert, heisst das nicht, dass man es auch einsetzen sollte.
Ja, kenne ich. Ich habe auch schon selbst einen entsprechenden Artikel geschrieben. Das Problem ist, dass die meisten dieser Anleitungen den gleichen Sachverhalt nur wiederkäuen. Nicht umsonst stimmen die ganzen Artikel zu mod_fcgid zu 90% überein, hier mal ein anderer Paketmanager, da mal ein anderes DocumentRoot für den Apache httpd oder ein anderes Verzeichnis für den "fcgi-starter", ansonsten aber identisch. Auch muss nicht alles stimmen, was so im Internet steht. Tatsache ist, dass PHP mittlerweile ganz gut selbst seine Prozesse verwalten kann und mit PHP-FPM gibt es ebenfalls eine sehr brauchbare Alternative zum Prozess-Management für PHP. Mit mod_fcgid sind diese Möglichkeiten aber nicht nutzbar, da dieses die Prozesse ausschließlich selbst erstellen will, und mod_proxy_fcgi wird erst mit Apache httpd 2.4 kommen. Es bleibt also nur mod_fastcgi , wenn man einen extern gestarteten FastCGI-Prozess nutzen, aber nicht auf Apache httpd 2.4 warten oder ein offiziell nur mit Apache httpd 2.0 kompatibles Modul einsetzen will.
|
agaida
Anmeldungsdatum: 24. Februar 2010
Beiträge: 3348
Wohnort: Bielefeld
|
PHP-FPM - ein ganz heikles Thema und eigentlich für Fortgeschrittene. Ich denke aber mal, dass mit der Umstellung von cgi oder mod_php auf fastcgi oder fcgi schon eine ganze Menge erreicht ist. Da ist es dann erst mal fast egal, wofür man sich entscheidet. Man wird seine Gründe haben. 😉 Doof ist halt nur, dass man erst mal einen recht großen Überbau an Wissen aufbauen muss, um überhaupt sach- und fachgerecht entscheiden zu können. Die Implementierung ist dann trivial. Das Gleiche sehe ich auch bei irgendwelchen Benchmarks so. Wenn was auf dem Papier schnell ist und dann auch schnell gebencht wird, ist schön. Das heisst aber noch lange nicht, dass ich irgendeinen praktischen Nutzen davon habe (Mein Vergleich: Mit dem Ferrari im Stau und dann sagen: 0 auf 100 in 3s) Ich hab das in den vergangenen Wochen ein wenig intensiver gespielt: Meine Seiten auf meinem privaten Atom fühlten sich an wie ein totes Stück Fleisch. Die einzige Optimierung war eingentlich nur, dass ich mich mal ein wenig an den MySQL-Einstellungen vergangen und bei der Gelegenheit dann Nägel mit Köpfen gemacht habe. MySQL 5.1 → Percona und die Grundeinstellungen vernünftig gesetzt. Ein Unterschied wie Tag und Nacht. Und das alles ohne die PHP und Apache-Einstellungen auch nur anzupacken. Eine weitere Optimierung wäre z.B. eine Vertex III für Seiten und DB. Und das sind dann Einflussgrößen, die mir kein Benchmarkprogramm sagt. Das ist aber eh seit Jahren mein Thema: Um Daten zu verarbeiten, muss ich die schnell genug bereitstellen. Erst wenn es dann in der Verarbeitung hakt, dann sollte ich was an dieser Stelle unternehmen. (Im Sinne forcierter Optimierung. Erst mal die low hanging fruits mitnehmen, das ist einfacher und meist sehr effektiv)
|
sykerjoe
(Themenstarter)
Anmeldungsdatum: 4. März 2011
Beiträge: 89
|
Ah ich sehe schon ich habe da schon Spezis erwischt .. sehr gut ... Ich post hier erstmal mein vorhandene Config vielleicht hat ja noch jemand von euch nen guten Tipp für mich... Die Anwendung ist die Tracking ISSUE Software Request Tracker. <VirtualHost *:80>
#ServerName servername
#DocumentRoot "/opt/rt4/share/html"
Redirect permanent /* https://rt.company.org/index.html
Redirect permanent / https://rt.company.org/index.html
</VirtualHost>
NameVirtualHost *:443
<virtualhost *:443>
ServerName servername
#ServerAlias requesttracker.copmany.org
DocumentRoot "/opt/rt4/share/html"
AddDefaultCharset UTF-8
Alias /NoAuth/images/ /opt/rt4/share/html/NoAuth/images/
ScriptAlias / /opt/rt4/sbin/rt-server.fcgi/
##################################
<Location />
Order allow,deny
Allow from all
Options +ExecCGI
#AllowOverride None
AddHandler fcgid-script fcgi
</Location>
#ServerName localhost
include /etc/apache2/sites-available/default-ssl.conf
</VirtualHost>
Sind eigentlich die Optimierungparameter für fcgid gleich die von fastcgi ?.... Achja und die Anwendung benutzt kein PHP sondern nur javascripts und css dateien grüße sykerjoe
|
adun
Anmeldungsdatum: 29. März 2005
Beiträge: 8606
|
Achja und die Anwendung benutzt kein PHP sondern nur javascripts und css dateien
Ähm ne, die ist in Perl geschrieben. Das Paket rt3.8-apache2 möchte am liebsten mod-perl2, nimm doch einfach das.
|
sykerjoe
(Themenstarter)
Anmeldungsdatum: 4. März 2011
Beiträge: 89
|
Ähm ne, die ist in Perl geschrieben. Das Paket rt3.8-apache2 möchte am liebsten mod-perl2, nimm doch einfach das.
ah sorry etz war ich falsch ..... wir wollen aber auf die neue Version updaten und da funkt. modperl zwar denke aber das fcgid performanter ist, oder ist das nicht der fall ? grüße sykerjoe
|
sykerjoe
(Themenstarter)
Anmeldungsdatum: 4. März 2011
Beiträge: 89
|
nachtrag: also ich habe auch mal eine config mit dem alten mod-perl
eingerichtet... und das geht seltsamerweise viel viel flotter..... kann das sein ? Die Responsetime ist wesentlich höher.... und auch nach einer gewissen Idle Zeit, erhöht sie sich im gegensatz zu modperl gewaltig oder ist bei mir einfach fcgid nicht richtig konfiguriert hier mal meine config: fcgid.conf: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71 | #<IfModule mod_fcgid.c>
# AddHandler fcgid-script .fcgi
# FcgidConnectTimeout 20
<IfModule mod_fcgid.c>
IdleTimeout 7200
# An idle fastcgi application will be terminated after IdleTimeout seconds.
FcgidIdleScanInterval 480
# The scan interval for idle fastcgi applications.
FcgidBusyTimeout 3000
# a fastcgi application will be terminated if handing a single request longer than busy timeout.
FcgidBusyScanInterval 480
# The scan interval for busy timeout fastcgi applications.
FcgidErrorScanInterval 3
# The scan interval for exit pending fastcgi applications. fastcgi applications will be terminated within
# this scanning.
FcgidZombieScanInterval 3
# The scan interval for zombie process.
FcgidProcessLifeTime 86400
# A fastcgi application will be terminated if lifetime expired, even no error is detected.
# SocketPath /tmp/fcgid/sock.rt3
# WICHTIG, das komplette Verzeichnis bis hin zum Socket muss schreibbar sein füche!
# The directory to put the UNIX domain socket. (UNIX only)
FcgidSpawnScoreUpLimit 150
# The spawn-speed control score up water limit. Score increases while a process is spawned or terminated, and
# decreases as time progresses; while the score is higher than SpawnScoreUpLimit, the spawning will be held
FcgidSpawnScore 1
# The weight of spawning. This weight will be plused to the spawn-control score on every spawn. The higher
# this number is, the lower speed of spawning can be.
FcgidTerminationScore 2
# The weight of termination. This weight will be plused to the score while fastcgi process terminates. The
# higher this number is, the lower speed of spawning can be.
FcgidMaxProcesses 40
# The max count of total fastcgi process count.
FcgidMaxProcessesPerClass 32
# The maximum number of fastcgi application instances allowed to run for any one fastcgi application.
FcgidMinProcessesPerClass 0
# The minimum number of fastcgi application instances for any one fastcgi application.
# DefaultInitEnv env_name env_value
# The default environment variables before a fastcgi application is spawned. You can set this configuration
# more than once.
FcgidConnectTimeout 100
# The connect timeout to a fastcgi application.
FcgidIOTimeout 1200
# The communication timeout to a fastcgi application. Please increase this value if your CGI have a slow
# initialization or slow respond.
# OutputBufferSize n (64k bytes)
# CGI output cache buffer size.
# MaxRequestsPerProcess n (-1)
# Adds a MaxRequestsPerProcess parameter that allows mod_fcgid to exit after handling a certain number of
# requests, similar to the existing ProcessLifeTime option.
</IfModule>
|
grüße sykerjoe
|