Binero strular
 

Nu börjar Binero strula mer och mer frekvent.. Det är allt från domäner som hoppar fram och tillbaka i kontrollpanelen, till diverse datumfel i densamma.

Det nya idag är kortbetalningen som inte fungerar, det är väl A och O att det ska vara lätt att registrera en domän. Jag har dessutom väldigt lång svarstid på mina sidor ibland, även de med väldigt lite innehåll.

Någon annan som upplever problem?

Jag känner att man måste ha koll på Binero eftersom de inte verkar ha koll åt en, det är väldigt irriterande. Detta i kombination med att domainz.se fungerar uselt för tillfället gör att jag inte har någon större koll på mina domäner.

Det får blir ett excelark framöver!

Jag har själv ett par domäner hos Binero men upplever inga större problem, dom hade en liten period i våras men inget som jag ser har stannat kvar.

har du snckat med Binero om kortbetalningarna?
Det kan ju ha något att göra med leverantörer av tekniken osv...

Har inte hunnit ta upp det med dem ännu men ska definitivt göra det.. Kom på att jag upplevt det ett flertal gånger nu.
Det är säkert inte hos dem felet ligger men det är upp till dem att få det att fungera kan jag tycka.

Tur att de har sån generös och bra support, då finns det hopp :)

Nja, Du menar alltså att om jag startar en butik där jag väljer att använda DIBS och DIBS terminal sedan får jätte problem blir det något jag ska koda om så det funkar?

Det man möjligtvis kan göra är att byta leverantör men det tar ju sin lilla stund.

Jag tror att om kortbetalningar är problem just nu så har nog Binero vetskap om detta men ofta är det längre än 1 dags arbete att byta eller ändra i leverantörs avtal osv.

Skicka ett support ärende med frågan och sedan får du nog ett vettigt svar tillbaka från dom kan jag tro.

Jaa, jag får göra det :)

Tycker inte om när saker inte vill fungera bara.
Men så är det generellt i samhället tycker jag, man blir så van och bekväm med alla förenklingar att man inte vet vad man ska ta sig till när det inte fungerar.

Man borde kanske vara glad NÄR saker fungerar istället :)

Tack för perspektiv :)

Jo att man blir grymt frustrerad när det inte funkar och går händelser i förväg det har jag egna erfarenheter av och man lär sig av dom situationerna med.

Innan jag drev eget företag med anställda, leverantörer och avtal osv så var jag nog mindre förstående men nu när man har dubbel arbetsmånad och massa kunder att vårda så inser man att vissa saker man gjorde bara för några månader sen var så otroligt fel...

Som sagt man lär av sina misstag!

Tack för svar, har ni någon app på g? Nyfiken...
I och med att ni använder Payex vid kortbetalningar så skulle ni kanske även använda er av deras mobila betalningstjänst? Jag vet iof inte hur pass väl den fungerar men det hade varit ett bra alternativ när man är på drift och inte har tillgång till bankdosor o.s.v.

Även vi (Adrecord) använder Payex för att debitera en del av våra annonsörer och dessa mail från Payex om driftproblem med EDB kommer så ofta så att om jag hade webbutik, eller annat behov av att mina kunder själva bestämde när de skulle betala, aldrig skulle använda Payex som leverantör. Driftproblemen med EDB måste ha pågått i över ett år utan att de verkar göra något åt det. Vid några tillfällen har det varit problem som legat en hel eftermiddag. Jag vet inte exakt men nog har Payex problem i alla fall vid två tillfällen varje månad med EDB.

Vi har haft stora problem med Binero det senaste halvåret men det har eskalerat de senaste månaderna och jag har fått läxa upp deras teknikers ett par tre-fem-åtta-femton gånger. Vet exakt rent tekniskt vad deras problem är (tänk lastbalanserare och sessionsrotering) men vill inte ta det publikt isf, vi har fortfarande en dialog med dem även om jag tänker byta ut dem.. imorgon.

Våra problem yttrar sig att det går "relativt" snabbt med statiska sidor (W3 Total Cache), 1-3 sekunders load men sen sker nersegning mellan 10-30 ggr per arbetsdag när browsern bara står i WAIT-läge (Time To First Byte) och väntar på data och detta tar mellan 30-90 sekunder innan deras kluster "hostar till" och börjar släppa ifrån sej data. Själva överföringen går ofta snabbt, 600-800 ms för en vanlig sida, men problemet är som sagt WAIT-perioden. Även när det går snabbt så har vi en WAIT på 800-1500 ms.

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.

Input
 

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.

Härligt att höra någon form av respons gällande det tekniska från er. Tråkigt att det ska behöva bli genom ett forum. Jag har mejlat sedan i måndags eftermiddags och det är först nu i kväll vi hörde något från er genom Anders. Som sagt, felsökning har pågått väldigt länge nu och detta orsakar oss stora problem.

Det jag irriterar mig mest på är att detta hade varit löst på under några timmar om jag bara fått direktkontakt med någon tekniker som sitter nere och skruvar på sakerna. Svårt för er att se om en ändring ger effekt på vår sida när er tekniker inte har direktkontakt med oss utan måste gå genom supporten. Men det är så ni jobbar och det kan inte jag göra så annat åt än att sitta och bli irriterad när inget händer. För det är vad vi ser.

Jag hoppas också att detta löser sig. Vad utgången av det hela blir återstår att se.

Men Binero kör väl inte apache utan LiteSpeed?

Server Error in '/' Application
 

Server Error in '/' Application när jag går till binero.se - vad kan det bero på?

Se bifogad fil.

Aj aj. Nu när man såg sin post såg jag hur lätt det var att missförstå.

Om man omformulerar till:
Nåt säger mig att det varken är Bineros eller EDB:s fel... En magkänsla bara..

Ledsen för felformuleringen. Jag har svårt att tro att Binero skulle kunna påverka kortproblemen.