[Danielos]

Ursprungligen postat av dr_blue

Vet exakt rent tekniskt vad deras problem är (tänk lastbalanserare och sessionsrotering)

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.

[dr_blue]

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.

[barxth]

Ursprungligen postat av dr_blue

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.

Brukar försöka hålla mig ifrån att lägga mig i diskussioner om ärenden, men i detta fallet är det värt att nämna att jag i mail till dig för några dagar sedan har informerat dig om delen med omladdning av Apache. Där jag skrev att det är de rena drifteknikerna som felsöker ert problem med ett gäng mätningar mot olika applikationer, och jag var lite snabb med att ge min teori rörande omladdningen innan jag hade fått färdig feedback från dem.

Det har inget med varken lastbalanseringen eller sessionsbiten att göra och som jag skrev till dig var det dumt av mig att delge dig den teorin (som hade sitt ursprung i att jag manuellt flyttade er till en relativt nyuppsatt klustermiljö, där det hos mig fanns en kortare misstanke om att dessa bitar inte var optimalt konfigurerade, vilket visade sig vara ett felaktigt antagande då de fungerade precis som tänkt).

Ville bara klargöra den saken så inte missförstånden växer ut mer än de behöver.

Hur som helst så hoppas jag att det löser sig för er på ett bra sätt och jag vet att Anders haft löpande kontakt med A hos er under dagen.