Um beim Apache den Content-Type für *.svg Dateien korrekt zu setzen:
<FilesMatch "\.(svg|SVG)$" > ForceType image/svg+xml </FilesMatch>
Um beim Apache den Content-Type für *.svg Dateien korrekt zu setzen:
<FilesMatch "\.(svg|SVG)$" > ForceType image/svg+xml </FilesMatch>
Gerade habe ich im PECL-Paket eine nette GUI für den APC-Cache gefunden. Es zeigt sehr anschaulich die Auslastung des Caches. Aus dem PECL-Paket wird dafür nur die apc.php in ein erreichbares Verzeichnis gelegt. Standardmäßig zeigt es die Cache-Auslastung des aktuellen virtuellen Hostings. Im Kopf der Datei lassen sich aber verschiedene Authentifizierungs-Optionen einstellen, sodass man z.B. einem User “admin” die Cache-Hits aller Seiten auf dem Server zeigen kann.
Generell sei bemerkt, dass der APC-Cache immer global agiert. Dies ist auch durchaus sinnvoll – nur so spielt APC sein Potential voll aus. Jedoch sind die Statistikvariablen für jedes PHP-Script auf dem Server auswertbar (so auch für das apc.php Script). Betreiber von Shared-Hosting Systemen sollten sich im Klaren darüber sein, dass so z.B. die Pfade von häufig verwendeten Dateien für jeden Hosting-User abrufbar sind. Soweit ich die Konfiguration bisher interpretiere, lässt sich auch durch jeden User per PHP-Script der gesamte Cache resetten…
Gerd hat auch schon darüber geschrieben. Da viele professionelle PHP-Anwendungen sowieso auf Caching setzen habe ich bisher keine Notwendigkeit gesehen den APC-Cache mal auszuprobieren. Da ein Server in letzter Zeit besonders hohe Load hat, habe ich den APC-Cache jetzt doch mal ausprobiert.
Nach einem ersten, subjektiven Test muss ich sagen, dass der Leistungssprung wirklich erstaunlich ist. Ich habe den Eindruck, dass auch Typo3-Seiten (trotz eingebautem Caching) spürbar schneller und flüssiger laufen. Beim Blick auf den Graphen für die CPU-Load würde ich vorsichtig mal von 1/3 weniger Load ausgehen. Letztendlich ist der Leistungssprung durchaus logisch: Es wird nicht nur (wie sonst) lediglich die Ausgabe gecached sondern auch der kompilierte PHP-Code.
PDF-Dateien zu verlinken ist so eine Sache. Je nach Client-Einstellung wird die Datei mal innerhalb des Browsers und mal im Reader (standalone) geöffnet. Manche lösen es so, dass sie der Verlinkung ein target=”_blank” mitgegeben. Dies ist aber im xhtml-Standard nicht erlaubt und führt zu einem nicht validen Dokument.
Lösung ist es, dem Apache per Konfig oder .htaccess mitzuteilen, dass bei PDF-Dateien ein Download-Header angefügt werden soll. Der Browser öffnet dann einen Download-Dialog. Dies funktioniert natürlich nicht nur mit PDF-Dateien - auch nervige Media-Player kann man so (z.B. bei MP3-Dateien) aussperren.
<FilesMatch "\.(pdf|PDF)$" > ForceType application/octet-stream Header add Content-Disposition "Attachment" </FilesMatch>