Citat:
Ursprungligen postat av Danielos
Att man har ett problem här är något jag personligen inte förstår, jag tror att många med mig intressant skulle höra vad du tycker och för att lära oss mer.
|
Well, deras teori som jag fått som förklaring och luskat lite själv om är att först och främst kör lastbalanserare (F5) i frontend mot kunden och de använder sticky sessions som låser en återkommande anslutning mot en viss nod i deras kluster, enligt dem gör de detta av prestandasynpunkt vilket jag kan till viss del hålla med om. Problemet med lång WAIT på 30-90 _sekunder_ beror enligt dem på att just den nod vi kör mot för tillfället gör en reload på sin config och lastbalanseraren fattar inte detta och sitter och väntar på svar från servern. Sen så startar äntligen servern eller så skickar lastbalanseraren en vidare till en ny nod, det vet jag inte exakt vilket för det är svårt att avgöra så här utifrån. Anyway, denna teori fallerar enligt min summering längre ner.
De påstår då att de måste göra en hel reload av apache när en ny config skrivs från deras kontrollpanel men jag har då påpekat för dem att apache har haft stöd för graceful reloading av vhosts sedan 1.3 och att jag aldrig de senaste 5-6 åren jag drivit egna servrar själv haft problem med detta. Alternativt om problemet skulle ligga i deras F5 lastbalanserare borde detta vara ett extremt välkänt problem, och deras lb's borde inte sälja bra eller användas av så många.
Problemet i dessa resonemang ligger i att om det vore lastbalanseraren så hade inte problemet varit återkommande alltså nästa gång jag klickar på sajten så uppstår samma sak igen. Dessa problem kan pågå i upp till 10-15 minuter. Om det hade varit en lastbalanserare så hade den skickat mig till en ny nod och problemet hade varit löst. Om det hade varit apache som startar om (vilken apache behöver 30-90 sekunder på sig för att terminera aktiva trådar och anslutningar och sen starta upp med sina child-processes igen, när man inte ens använder graceful som ska vänta på att trådarna ska bli klara?) så hade problemet varit övergående och sidan hade laddat snabbt vid nästa förfrågan. Hade det varit apache så att jag fortfarande körde mot samma nod så hade den levererat sidor snabbt igen när den väl startat.
Att lastbalanseraren upptäcker att noden startar om och skickar mig en till ny nod, som i sin tur startar om, och jag skickas till en tredje nod, som också startar om, anser jag otroligt osannolikt. Och att detta skulle hålla på i 10-15 minuter? Det är eoner av tid för en server.
Problemet är verifierat även för statiska sidor (W3 Total Cache) och andra WP-installationer (vi har ett flertal) så detta drabbar alla våra besökare också och inte bara när vi är inne i wp-admin då cachen är avslagen för direkt generering av alla sidor.
Vi har självfallet verifierat att upplevs likadant från flertalet isp:er (Tele2 på jobbet, Perspektiv Bredband hemma och min chef har Telia).
Kanske lite rabblande och långa meningar då jag är för jäkla trött nu, både på dem och det är svårt att sammanfatta veckor av mejl och klurande. Hoppas någon iaf förstår mitt resonemang och håller med, annars kan det bli en intressant diskussion och jag är helt öppen för att lära mig mer
.
Tips på bra webbhotell för WP? Vill inte köra egen VPS även om det vore det bästa enligt mej, IT-chefen vill att vi låter någon annan (läs; leverantör) sköta patchningar och säkerhetsuppdateringar etc.