Resultaten 16 tot 27 van de 27
Pagina 2 van de 2 Eerste 1 2
  1. #16
    Anoniem
    5 Berichten zijn liked



    Thread Starter
    Citaat Oorspronkelijk geplaatst door Kevin Bentlage Bekijk Berichten
    Je zou die memory_limit tijdelijk steeds iets lager kunnen zetten, net zo laag totdat PHP tegen het limiet aanloopt. Wellicht kun je dan aan de error aflezen waar precies dit limiet bereikt wordt en of dit wel klopt.
    Ik heb een pak van deze:

    [core:error] [pid 317506:tid 140338442106624] [client xxx.xx.xx.xxx:25342] Script timed out before returning headers: index.php, referer: http://www.xxx.xxx/nl-BE

  2. #17
    Spoed: Varnish-Setup
    geregistreerd gebruiker
    555 Berichten
    Ingeschreven
    10/06/06

    Locatie
    Emmeloord

    Post Thanks / Like
    Mentioned
    14 Post(s)
    Tagged
    0 Thread(s)
    21 Berichten zijn liked


    Naam: Arie

    Ik zie het woord cache een aantal keer voorbij komen, maar nog niet in deze context: Wat als het plaatsen van een nieuw artikel nu de gehele/gedeeltelijke cache verwijderd? Bij nieuwe hits op de frontend wordt vervolgens alles weer opgebouwd. En dat kan aardig wat resources kosten. En dat ebt dan weer weg zodra de cache weer is opgebouwd. Bij veel cache oplossingen werkt het op deze manier.

  3. #18
    Anoniem
    5 Berichten zijn liked



    Thread Starter
    Citaat Oorspronkelijk geplaatst door Arieh Bekijk Berichten
    Ik zie het woord cache een aantal keer voorbij komen, maar nog niet in deze context: Wat als het plaatsen van een nieuw artikel nu de gehele/gedeeltelijke cache verwijderd? Bij nieuwe hits op de frontend wordt vervolgens alles weer opgebouwd. En dat kan aardig wat resources kosten. En dat ebt dan weer weg zodra de cache weer is opgebouwd. Bij veel cache oplossingen werkt het op deze manier.
    Die vraag stelde ik inderdaad ook deze ochtend aan de ontwikkelaar, maar nog geen antwoord. Maar dat zou toch geen 800 processen ipv 120-130 mogen zijn volgens mij

    Wij hebben een site draaien, maar op Wordpress, en daar doet deze cache-oplossing dit ook, maar heeft amper invloed op de load

  4. #19
    Spoed: Varnish-Setup
    geregistreerd gebruiker
    1.892 Berichten
    Ingeschreven
    17/08/05

    Locatie
    Amsterdam

    Post Thanks / Like
    Mentioned
    34 Post(s)
    Tagged
    0 Thread(s)
    35 Berichten zijn liked


    Naam: Wieger Bontekoe
    Bedrijf: Skynet ICT B.V.
    Functie: CEO
    URL: skynet-ict.nl
    Registrar SIDN: Nee
    View wbontekoe's profile on LinkedIn

    Citaat Oorspronkelijk geplaatst door Anoniem Bekijk Berichten
    Die vraag stelde ik inderdaad ook deze ochtend aan de ontwikkelaar, maar nog geen antwoord. Maar dat zou toch geen 800 processen ipv 120-130 mogen zijn volgens mij

    Wij hebben een site draaien, maar op Wordpress, en daar doet deze cache-oplossing dit ook, maar heeft amper invloed op de load
    Dit klinkt als een fuck-up in een PHP script waardoor je server een klap krijgt. Als het iets te maken had met gebruikers, hits of iets in die geest dan zou het na enkele minuten zichzelf oplossen en rustiger worden. Dat je echt handmatig actie moet ondernemen betekend dat er een loop ergens zit (of een andere php fout).
    Skynet ICT B.V. - The cause of the problem is: the printer thinks its a router.

  5. #20
    Anoniem
    5 Berichten zijn liked



    Thread Starter
    Citaat Oorspronkelijk geplaatst door CharlieRoot Bekijk Berichten
    Dit klinkt als een fuck-up in een PHP script waardoor je server een klap krijgt. Als het iets te maken had met gebruikers, hits of iets in die geest dan zou het na enkele minuten zichzelf oplossen en rustiger worden. Dat je echt handmatig actie moet ondernemen betekend dat er een loop ergens zit (of een andere php fout).
    Lijkt me ook niet koosjer alvast:

    Netwerkverkeer sinds opstart: 147,8 GiB

    Deze MySQL-server draait inmiddels 0 dagen, 12 uren, 50 minuten en 22 seconden. Deze is gestart op 02 aug 2016 om 01:53.

    Verkeer # ø per uur
    Ontvangen 2,4 GiB 191,6 MiB
    Verzonden 145,4 GiB 11,3 GiB
    Totaal 147,8 GiB 11,5 GiB
    Verbindingen # ø per uur %
    Max. gelijktijdige verbindingen 340 --- ---
    Mislukte pogingen 38 2,96 0,04%
    Afgehaakte 5,084 395,97 5,60%
    Totaal 91 k 7,065,96 100,00%

    11.3Gb per uur uitgaand op de MYSQL

  6. #21
    Spoed: Varnish-Setup
    geregistreerd gebruiker
    1.084 Berichten
    Ingeschreven
    17/02/03

    Locatie
    Hoorn

    Post Thanks / Like
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    5 Berichten zijn liked


    Naam: Raymond Karsten
    KvK nummer: 37109993
    Ondernemingsnummer: nvt

    Kun je niet testen met alleen de backend? Dus dat de frontend tijdelijk niet toegankelijk is voor bezoekers en er vervolgens een artikel geplaatst wordt?

    Het lijkt er meer gewoon op dat iets bij het plaatsen van het artikel voor een loop zorgt. Door dus de website tijdelijk volledig onbereikbaar te maken voor alles en iedereen zou je kunnen zien waar het aan ligt.

    Je kunt bijvooorbeeld ook alleen toegang geven voor een IP-adres middels een de firewall of een htaccess bestand of iets dergelijks. Vervolgens post je een artikel en dan kijken wat er gebeurd op de server.

  7. #22
    Spoed: Varnish-Setup
    geregistreerd gebruiker
    555 Berichten
    Ingeschreven
    10/06/06

    Locatie
    Emmeloord

    Post Thanks / Like
    Mentioned
    14 Post(s)
    Tagged
    0 Thread(s)
    21 Berichten zijn liked


    Naam: Arie

    Een loop hoeft het nog niet eens te zijn. Er zijn gewoon logge sites die MySQL voor ieder wissewasje gaan raadplegen. Tientallen / honderden query's per hit. Een voorbeeld is Magento. Een site met een handjevol bezoekers kan je hele CPU volstoppen. Of een crawler die iedere pagina bij langs gaat. Of dat Bing en Google samen met ieder meerdere bots tegelijk bezig zijn.

    Zonder de site verder te kennen is het moeilijk raden wat er hier nu aan de hand is, 99% zeker kunnen we denk ik wel zeggen dat het aan de website zelf ligt en dat dit niet met een magische server configuratie verholpen is.

    Om verder te debuggen zou je ook kunnen overwegen om een kopie van de website apart online te zetten zodat het normale verkeer er geen last van heeft.

  8. #23
    Anoniem
    5 Berichten zijn liked



    Thread Starter
    Mogen we inderdaad zeker van zijn.

    Ook nog, van gisterenavond 23u tot nu, is de database van 931Mb, naar 1.33Gb gegaan ... De ontwikkelaar zoekt het verder uit, maar het Varnish-verhaal om dit op te lossen ligt uiteraard in de vuilnisbak ...

  9. #24
    Anoniem
    5 Berichten zijn liked



    Thread Starter
    Na een deploy deze middag, zijn er wat verbeteringen, maar het blijft problematisch wanneer men in de backend aan het werk gaat. Dit heb ik zopas via New Relic opgevangen en valt perfect samen met het omhoog schieten van het aantal processen voor deze user:

    http://users.telenet.be/bottie/screens/entity.jpg

  10. #25
    Spoed: Varnish-Setup
    geregistreerd gebruiker
    4.100 Berichten
    Ingeschreven
    09/12/05

    Locatie
    Almere

    Post Thanks / Like
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    76 Berichten zijn liked


    Naam: Ramon Fincken
    Bedrijf: Managed WordPress Hosting / MijnPress.nl
    Functie: CEO
    URL: www.managedwphosting.nl
    Registrar SIDN: Nee
    KvK nummer: 30262182
    TrustCloud: ramonfincken
    View ramonfincken's profile on LinkedIn

    Citaat Oorspronkelijk geplaatst door Anoniem Bekijk Berichten
    Na een deploy deze middag, zijn er wat verbeteringen, maar het blijft problematisch wanneer men in de backend aan het werk gaat. Dit heb ik zopas via New Relic opgevangen en valt perfect samen met het omhoog schieten van het aantal processen voor deze user:

    http://users.telenet.be/bottie/screens/entity.jpg
    Hmm drupal, die kan uit zichzelf al heel goed cachen ..
    WordPress hosting Optimalisatie webbouw debugging door WP Core developers

  11. #26
    Anoniem
    5 Berichten zijn liked



    Thread Starter
    Er is een nieuwe deploy uitgevoerd en 'plots' draait alles als een zonnetje. Wanneer ik vraag wat de oplossing was:


    Het enige wat we hebben gedaan is de caching afgestemd op de server. Qua code hebben we helemaal niets aangepast.

    - Alle cachetabellen zitten in file cache, dus ipv in de databank worden deze nu op file niveau bijgehouden om de databank niet te belasten.
    - Caching van advertenties is verder geoptimaliseerd (impressies worden via cron ipv page load geregistreerd)
    - Megamenu is opgenomen in caching
    - 404 pagina's worden opgevangen zodat ze geen resources verbruiken.
    - ...
    Maximale geheugenverbruik is nu amper 0,4-0,8Gb ipv 24Gb ...

  12. #27
    Spoed: Varnish-Setup
    geregistreerd gebruiker
    555 Berichten
    Ingeschreven
    10/06/06

    Locatie
    Emmeloord

    Post Thanks / Like
    Mentioned
    14 Post(s)
    Tagged
    0 Thread(s)
    21 Berichten zijn liked


    Naam: Arie

    Inderdaad zoals verwacht werd caching verkeerd benut en werd derhalve de MySQL server overbelast. Hoewel het misschien niet 'aan de code' lag, lag het wel aan de instellingen ervan. In ieder geval niet aan de server. Maar goed, met enige regelmaat zoekt de klant de oplossing bij de server in plaats van zijn eigen afdeling.

Pagina 2 van de 2 Eerste 1 2

Labels voor dit Bericht

Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2021 Webhostingtalk.nl.
Web Statistics