PHP Opcache funktioniert nicht wie gewünscht

[ThunderByte]

Hi,

Ich habe vor kurzer Zeit von der PHP Version 5.4 zu 5.5 gewechselt.
Da nun Opcache implementiert war, wollte ich dieses auch nutzen, ich habe mich dementsprechend informiert und Opcache aktiviert und folgende Punkte abgeändert:

Code: Alles auswählen

opcache.enable = "1"
opcache.enable_cli = "1"
opcache.enable_file_override = "1"
opcache.error_log = "/var/log/php_opcache.log"
opcache.fast_shutdown = "1"
opcache.interned_strings_buffer = "8"
opcache.log_verbosity_level = "2"
opcache.max_accelerated_files = "4000"
opcache.memory_consumption = "128"
opcache.revalidate_freq = "60"
opcache.revalidate_path = "1"

Laut einem Opcache Status Script, funktioniert auch alles wie gewünscht.
Nun zum eigentlichen Problem, Ich hatte mir erhofft, dass nach der Installation von Opcache, die Auslieferung meiner (WordPress) Seite schneller von statten geht. Allerdings, bekomme ich, wenn ich mit dem Apache eigenen Benchmarktool "ab" die Geschwindigkeit der Seite teste, genau das selbe Ergebnis, wie vor der Aktivierung von Opcache.
Muss ich da manuell noch etwas konfigurieren?

Ich bin über jede Hilfe Dankbar!


Software:
Debian 7
Apache 2.2
PHP 5.5
MySQL 5.5

[rendegast]

Wie sieht Dein Test aus?

Alternatives Tool jmeter.
Ein "Positiv" diesbezüglich
http://tehnoblog.org/opcache-apcu-stati ... benchmark/
(apc(u) bringt dort nix)


Hier etwas, um die hits/misses anzuzeigen
http://php.net/manual/en/function.opcac ... status.php
https://github.com/rlerdorf/opcache-status


----------------------------------------------------------
Warum zeigt das in php5-apcu 4.0.7 enthaltenen apc.php nix (mehr?) an?
Unter php-apc 3.1.13/wheezy (+ php5-gd, lighttpd) hatte ich immer ein "Erfolgserlebnis".

[ThunderByte]

Wie sieht Dein Test aus?

Alternatives Tool jmeter.
Ein "Positiv" diesbezüglich
http://tehnoblog.org/opcache-apcu-stati ... benchmark/
(apc(u) bringt dort nix)


Hier etwas, um die hits/misses anzuzeigen
http://php.net/manual/en/function.opcac ... status.php
https://github.com/rlerdorf/opcache-status


----------------------------------------------------------
Warum zeigt das in php5-apcu 4.0.7 enthaltenen apc.php nix (mehr?) an?
Unter php-apc 3.1.13/wheezy (+ php5-gd, lighttpd) hatte ich immer ein "Erfolgserlebnis".

Hallo,

Tut mir leid für die späte Anwort. Opcache funktioniert wohl doch besser, als ich dachte, dadurch braucht der Benchmark nur halb so lange und schafft auch doppelt so viele Requests pro Sekunde.
Das reicht mir allerdings noch nicht, kann man da noch etwas optimieren?

Hier die Tests:

Ohne Opcache:

Code: Alles auswählen

Concurrency Level:      20
Time taken for tests:   91.936 seconds
Complete requests:      200
Failed requests:        0
Write errors:           0
Total transferred:      4962800 bytes
HTML transferred:       4912600 bytes
Requests per second:    2.18 [#/sec] (mean)
Time per request:       9193.590 [ms] (mean)
Time per request:       459.679 [ms] (mean, across all concurrent requests)
Transfer rate:          52.72 [Kbytes/sec] received

Mit Opcache:

Code: Alles auswählen

Concurrency Level:      20
Time taken for tests:   42.047 seconds
Complete requests:      200
Failed requests:        0
Write errors:           0
Total transferred:      4962800 bytes
HTML transferred:       4912600 bytes
Requests per second:    4.76 [#/sec] (mean)
Time per request:       4204.655 [ms] (mean)
Time per request:       210.233 [ms] (mean, across all concurrent requests)
Transfer rate:          115.26 [Kbytes/sec] received

Grüße und danke.

Edit: Hier ein Bild der Statusseite:
http://fs5.directupload.net/images/151004/brqxrxik.jpg

[rendegast]

Du könntest die Menge des vorgesehenen Speichers von 128M auf 64M heruntersetzen.
Jedoch scheint das nur ein Max zu sein. Bei mir sind es per default 64M,
der Cache belegt aber nur 8M, beim 'htop' sehe ich nichts von den restlichen 55M.



Du könntest vielleicht die Verbleibezeit(?) erhöhen:

Wenn ich herumprobiere 'ab .... http://..../...php'
opcache: 430Requ/sec
( opcache+apcu nur noch 180Requ/sec !!!!???? )
( opcache+apcu deaktiviert 60R/s )
( nur apcu (nominell) aktiviert 40R/s !!!!???? )
( bei Bezug von https:// TLS1.2 komme ich gerade auf 10R/s)
Wenn ich eine Weile warte
260R/s ---> 360R/s ---> 420 R/s ---> 430R/s
Auf der Statusseite wächst die Anzahl der hits entsprechend von wenigen/Durchgang zu 90/Durchgang eines 430R/s-Durchgangs.

Jedoch bleibt die auf der Statusseite angezeigte Anzahl gecachter Skripte konstant,
was da also verloren geht?
Nicht zu vergessen, 'ab' ist dabei ein theoretischer bench.

In die Richtung gehen vielleicht

Code: Alles auswählen

opcache.interned_strings_buffer	4
opcache.max_accelerated_files	2000
opcache.max_wasted_percentage	0.05
opcache.force_restart_timeout	180

Der Wert interned_strings_buffer entspricht dem Status buffer_size
(bei Dir 8M)
und zählt zum Status used_memory.



40MB gecachte Skripte sieht doch gut aus,
wie ist denn das Hit/Miss nach einem Tag Normalbetrieb?

[ThunderByte]

Hi,

Danke für deine Antwort.
Wie lese ich denn die Hit/ Miss Werte aus?

[rendegast]

Auf der Anzeige von opcache.php nach unten scrollen,
oder rechts über dem Kreis 'Hits' anklicken.


https://tideways.io/profiler/blog/fine- ... g-suprises
Mehr als zusehen, daß möglichst die meisten benutzten Skripte im Cache vorgehalten werden, geht wohl nicht.
Die misses sollten also nach einer gewissen "Aufwärmphase" stabil bleiben (wohl kleiner als opcache.max_accelerated_files)
und nur noch die hits sollten ansteigen.

[ThunderByte]

Hi,

Hier der Screenshot:
http://fs5.directupload.net/images/151006/uw5ijf95.jpg

[rendegast]

used_memory 10.57 MB
free_memory 1.43 MB
wasted_memory 0 bytes
current_wasted_percentage 0.00%

buffer_size 3,145,728
used_memory 1.18 MB
free_memory 1.82 MB

num_cached_scripts 221
num_cached_keys 659
max_cached_keys 3,907

hits 88,464
start_time Mon, 05 Oct 15 13:23:11 +0200
last_restart_time never
oom_restarts 0
hash_restarts 0
manual_restarts 0
misses 222

Die zwei Einstellungen
opcache.memory_consumption 12(.00 MB)
opcache.interned_strings_buffer 3
machen sich imo nur optisch gut
( halt ein gut gefüllter, aber nicht überfüllter Cache ).

Bei einem Seitenaufruf kommen ~ 20-150 hits dazu.
Tendenziell ist es auch zu spüren,
aber für den Seitenaufbau des squirrelmail/roundcube ist imapproxy gravierender.

[ThunderByte]

Hallo,

Ich verstehe ehrlich gesagt leider nicht, was genau du mir damit sagen möchtest

[rendegast]

Der erste Teil ist ein "Zeigst Du mir Deins, zeig ich Dir meins".
Nach weiteren drei Tagen hat sich nichts verändert , außer die hits sind auf 230.000 gestiegen.
Meine "Optimierung" der Herabsetzung der beiden Speicherwerte scheint also passabel
(wenn auch imo unnötig,
es bringt wohl nur ein MB RAM durch buffer 4->3).



Die Erwähnung meiner Anwendung der Webmailer:
Die Anfragen an den Mailserver (-> dovecot-imap) finden dabei häufig statt, und sind "teuer" wegen der immer wieder stattfindenden Authentifizierung.
Jedes Auflisten eines anderen Ordners kostet eine/mehrere "Schaltsekunde",
was durch imapproxy wegfällt.
Die größte Optimierung liegt (in diesem Fall) also außerhalb von php.

[rendegast]

Anm.

In opcache.php

Code: Alles auswählen

    <script src="//cdnjs.cloudflare.com/ajax/libs/d3/3.0.1/d3.v3.min.js"></script>
    <script src="//cdnjs.cloudflare.com/ajax/libs/jquery/1.11.0/jquery.min.js"></script>

->

Code: Alles auswählen

    <script src="./cdnjs.cloudflare.com/ajax/libs/d3/3.0.1/d3.v3.min.js"></script>
    <script src="./cdnjs.cloudflare.com/ajax/libs/jquery/1.11.0/jquery.min.js"></script>

und die beiden Skripte entsprechend im Verzeichnis von opcache.php abgelegt vermeidet die online-Zugriffe.