[TYPO3-UG Dutch] print-weergave zonder &print=1 parameter - cache probleem.

Patrick Broens patrick at netcreators.com
Sat Nov 15 18:12:39 CET 2008


Beste Marijn,

Ik heb zelf geen directe ervaring met Pecl APC, maar weet dat dit een
PHP caching mechanisme is. Dit is heel wat anders dan het caching
systeem van TYPO3. TYPO3 slaat de output op in de database, oftewel de
HTML. Bij een pagina die geheel gecached kan worden, wordt dus de gehele
HTML is de database opgeslagen en hoeft bij een volgende oproep dus
alleen uit de database gelezen te worden zonder de hele pagina weer
opnieuw op te bouwen. Onderdelen die niet gecached kunnen worden, worden
dan verwerkt en alsnog in dit gecached gedeelte ingevoegd. (simpele
omschrijving)

Mijn vraag is, als je al css voor media="print" toevoegt, waarom zou je
dan nog een print-vriendelijke pagina op willen bouwen? Een print
vriendelijke pagina is erg old school, sinds de stylesheets met
media="print" is dit helemaal niet meer nodig. Wanneer je een pagina
bekijkt en deze wilt printen, dan wordt de print stylesheet gelezen. Zo
kun je de pagina voor scherm er heel anders uit laten zien dan voor print.

Dat wil niet zeggen dat er niet een probleem in je installatie zit. Had
je dit probleem ook al voordat je deze PHP caching gebruikte? Of is dat
sinds APC gekomen? Anders ligt de fout waarschijnlijk in je Typoscript.

Je hebt het over overload problemen. Wat was hier de oorzaak van? Is er
bizar veel verkeer op je website? Heb je al eens gecontroleerd of de
pagina's door het caching systeem van TYPO3 werden gecached? Want als je
de TYPO3 caching uit hebt staan voor alle pagina's dan wordt de load erg
hoog. Bij hoge traffic kan ik aanraden om de extensie nc_staticfilecache
uit te proberen. Die maakt namelijk voor elke pagina een statische HTML
pagina aan, indien mogelijk, zodat zelfs PHP niet eens aangeroepen
wordt. Je load wordt hier erg laag van, omdat PHP niet aangesproken
wordt in veel gevallen.

APC is niet echt caching, het is een performance verbeteraar voor PHP,
net zoals eAccellerator. Ik kan me niet voorstellen dat de performance
hierdoor echt significant beter is geworden.

Patrick

Marijn Depraetere wrote:
> Dag group,
> 
> T3: 4.2.1 in een dedicated LAMP-omgeving met APC caching op serverniveau.
> 
> Extensies:
> TemplaVoila! (templavoila)
> Random Images (maag_randomimage)
> News (tt_news)
> SmoothGallery for TYPO3 (rgsmoothgallery)
> Google Sitemap for Pages and Contents (mc_googlesitemap)   
> Date2Calendar (date2cal)
> 
> Via TemplaVoila! heb ik, per template ook een print-vriendelijk
> exemplaar voorzien.  Deze print-vriendelijke template wordt opgeroepen
> via een print-icoon die ik via typoscript ingebouwd heb:
> 
> <code>
> # Printable version
> // Create a link to a printable version of the current
> // page--complete with all GET parameters needed by
> // extensions:
> lib.iconPrint = IMAGE
> lib.iconPrint {
>     // The image
>     file = images/main-icon-printpage.gif
>     altText = Afdrukbare paginaversie
>     titleText = Afdrukbare paginaversie
>     border = 0
>     
>     stdWrap.typolink {
>     // Get the id of the current page:
>         parameter {
>     data = page:uid
>     }
>     // Add whatever is in the query string:
>     addQueryString = 1
>     addQueryString {
>         // Account for the fact that RealURL etc
>     // may have manipulated the query string:
>     method = GET
>     }
>     // Add the 'print' parameter:
>     additionalParams = &print=1
>     // Do not cache the print version:
>     no_cache = 1
>     // Open print-page in new window
>     extTarget = _blank
>     target = _blank
>         }
>     }
> }
> </code>
> 
> Bovendien heb ik, in de template zelf ook een print-vriendelijk CSS
> bestand ingebouwd als volgt:
> 
> <code>
>     <style type="text/css" media="screen">
>     @import url("resources/subpages-2column.css");
>     </style>
> 
>     <style type="text/css" media="print">
>     @import url("resources/subpages-print.css");
>     </style>
> </code>
> 
> Dit alles werkte, tot voor kort, perfect.
> 
> PROBLEEM
> 
> Na wat overload-problemen op onze server hebben we ervoor geopteerd om
> een caching-systeem (APC) te installeren op serverniveau.  We gingen af
> op de aanbevelingen van dit document:
> 
> http://typo3.org/development/articles/testing-and-tuning-typo3-performance/page/2/
> 
> 
> We hebben dus wel eAccellerator vervangen door APC.
> 
> Het probleem is dus dat niet de gewone template getoond wordt bij het
> openen van een nieuwe pagina, maar de print-template wordt gebruikt. Dit
> zonder de parameter &print=1.  Dit gebeurt zonder enige logica.
> 
> Bijvoorbeeld:
> index.php?id=1 --> Gewone template
> index.php?id=2 --> Print template
> index.php?id=3 --> Gewone template
> 
> Het wissen van de pagina-cache (op applicatieniveau) lost het probleem
> op, maar enkel tijdelijk.  Een dag later worden terug andere pagina's
> verkeerd weergegeven.
> 
> VERMOEDELIJKE OORZAAK 1
> Er is dus duidelijk een cache-probleem, maar ik weet niet hoe dit op te
> lossen valt en wat de oorzaak is.  Hoe gaat het caching van typo3
> pagina's eigenlijk in zijn werk?  Kan het zijn dat de APC op
> serverniveau de cache op applicatieniveau opslaat en deze aanbrengt als
> de correcte pagina?
> 
> VERMOEDELIJKE OORZAAK 2
> Ik heb indexed_search recent vervangen door een google-searchbox.  Ik
> weet dat indexed_search ook de pagina's in zijn eigen cache zette.  Kan
> het zijn dat er nog wat neveneffectten ontstaan zijn hierdoor?  De APC
> is wel maar geactiveerd na het uitschakelen van de indexed_search.
> 
> Alvast bedankt voor het meedenken,
> Marijn Depraetere


More information about the TYPO3-UG-dutch mailing list