Problem med nonchalanta FSData
 

Är det nån mer som har prestandaproblem med FSData? Jag upplever webbservern vi ligger på som generellt snabb, men vid flera tillfällen får mysql servern hosta. Det började redan i höstas.

FSData säger att de överbelastat antalet mysql användare och lovade i september en ny server. Jag tror det finns en annan prolematik. Nu börjar strulet:

9 sep - Jag rapporterar långa delayer på mysql anslutningarna.
20 sep - FSdata meddelar överbelastning och att vi behöver flyttas. Ungefärlig en vecka leveranstid. Ärendet stängs och ingenting händer.
6 okt - Jag frågar hur det går.
10 okt - FSdata meddelar att nya servern har kommit och flytt sker asap. Ärendet stängs och ingenting händer.
26 okt - Jag meddelar fortsatt problematik och frågar hur det går.
28 okt - FSData säger att det ska påskynda ärendet. Ärendet stängs och ingenting händer.
28 nov - 2,5 månader har gått. Något mutter ringer jag in och frågar hur det går. Vänligt bemött av Alexander öppnar han ärendet igen.
2 dec - FSData svarar att en RAID kontroller var dead-on-arrival 10 okt och behöver skickas på garantiärende till Tyskland. De har dock beslutat att köpa ett nytt istället och nya servern ska vara uppe om en vecka.
9 dec - Jag frågar hur det går.
13 dec - FSData svarar att de väntar på beställningar och retur.

Summa summarum är det ingen skillnad alls sen min felanmälan 9 sep. Upplever FSData som oerhört oengagerade i ärendet.

Här är ett exempel på mina dagliga loggar:

Warning: A MySQL connection established in 9.000 s.
Warning: A MySQL connection established in 9.006 s.
Warning: A MySQL connection established in 8.999 s.
Warning: A MySQL connection established in 9.001 s.
Warning: A MySQL connection established in 9.006 s.
Warning: A MySQL connection established in 2.999 s.
Warning: A MySQL connection established in 9.000 s.
Warning: A MySQL connection established in 2.999 s.
Warning: A MySQL connection established in 9.000 s.
Warning: A MySQL connection established in 3.009 s.
Warning: A MySQL connection established in 3.004 s.
Warning: A MySQL connection established in 9.003 s.
Warning: A MySQL connection established in 2.999 s.
Warning: A MySQL connection established in 9.002 s.
Warning: A MySQL connection established in 8.998 s.
Warning: A MySQL connection established in 8.999 s.
Warning: A MySQL connection established in 9.001 s.
Warning: A MySQL connection established in 3.010 s.
Warning: A MySQL connection established in 9.005 s.
Warning: A MySQL connection established in 9.003 s.
Warning: A MySQL connection established in 3.001 s.
Warning: A MySQL connection established in 3.001 s.
Warning: A MySQL connection established in 3.001 s.
Warning: A MySQL connection established in 8.998 s.
Warning: A MySQL connection established in 9.001 s.
Warning: A MySQL connection established in 3.000 s.
Warning: A MySQL connection established in 3.011 s.
Warning: A MySQL connection established in 9.007 s.
Warning: A MySQL connection established in 9.005 s.
Warning: A MySQL connection established in 9.005 s.
Warning: A MySQL connection established in 9.006 s.
Warning: A MySQL connection established in 9.004 s.
Warning: A MySQL connection established in 3.001 s.

Samt en del sådana här emellanåt:

PHP Warning: mysql_pconnect(): Lost connection to MySQL server at 'reading initial communication packet', system error: 111
PHP Warning: mysql_pconnect(): Lost connection to MySQL server at 'reading initial communication packet', system error: 113

Så här ser koden ut som mäter:

// Set start timestamp
$execution_time_start = microtime(true);

// Connect
$sqlLink = mysql_pconnect(DB_SERVER, DB_USERNAME, DB_PASSWORD);

// Set stop timestamp
$execution_time_stop = microtime(true);

// Calculate duration time
$execution_time_duration = $execution_time_stop - $execution_time_start;

Prestandan mellan olika hotel skiljer sig markant. Tyvärr vill inte FS-data dela med sig av sin prestanda, men nedan är 3 web-hotel som ger mycket bra prestanda:

oderland.com
egensajt.se
loopia.se

Jag har 4 kunder på varsina Loopia servrar.
* En snabb server (Blink blink)
* En godtycklig server. (1-5 s laddningstid)
* En mycket slö server. (Sidor i OpenCart laddar på 10-20 s)
Edit: Den fjärde också godtycklig. Jag befinner mig i Västerås, samma stad som Loopia.

Oderland behöver jag prova igen, det var länge sen sist och då var det otillfredställande med periodiska nertider flera ggr i veckan.

Egensajt.se har jag varit nyfiken på och lät prova det. La dock ner det när FTPn spökade. Ett server quota kommando fördröjde varje fil och osCommerce skulle ta ett dygn att ladda upp.

Är det du Anders som ligger bakom webhosting-benchmark.com? Jag har länge eftersökt en sådan tjänst som tar webbhotell till en rond. Ett tag slipade jag på idén i huvudet. Hur är dina planer på att vidareutveckla tjänsten? För att vara ett sånt framgångsrikt IT land som Sverige är, så tycker jag inte att våra webbhotell riktigt ger uttryck för det.

Kul att det är fler som är intresserad av prestanda för webhotel.

Jag tycker att du ska ta ett snack med egensajt om ftp-problemen. De är ganska måna om att inte ha den typen av problem (tyvärr ingår det inte i våra test (idag))

Många hotel har kortare nertider, dock har jag hittils inte märkt några problem med oderland som skulle vara värre än andra hotel.

Våra test skript är tillgängliga för nedladdning, som om du skulle se stora skillnader i våra siffror mot vad du får om du kör våra skript så är du välkommen att höra av dig till oss eller webhotellet ifråga.

Har du önskemål om fler funktioner?

Om det var en relativt viktig sida det gällde så hade jag flyttat för länge sen. Man kan inte acceptera sådana väntetider. Tyvärr är det väl kanske som du säger lite si och så med kvaliteten på webbhotellkonton, mycket på grund av att det är massproduktion för "vanliga kunder" som gäller om man vill tjäna pengar idag. Då får inte varje kund kosta särskilt mycket. Det finns naturligtvis alternativ om man har högre krav men då går kostnaden genast upp.

Skickade du någon ticket på det? Vi har inga rapporter om andra som har haft samma fel och vi har bytt ftp servern så välkommen att prova igen!

Förlåt om jag verkar lite egenkär, men saker och ting ändras snabbt. Nu är också FSData med.

Det där är ju verkligen inte acceptabelt, varken prestandan eller deras agerande.

Jag hade liknande problem med Loopia för ett par år sedan även om de inte var i närheten av lika allvarliga. Jag fick då samma problem med anslutningarna(~10 sek) och ibland connection timeout på ett par procent av anslutningarna till databasen, främst under kvällar när loaden var högst. Jag kontaktade supporten efter ett tag och jag blev flyttad till en snabbare databasserver vilket löste problemen.

Kör man på shared hosting får man tyvärr vara beredd på detta. Det är massproduktion och man vill inte ha allt för mycket outnuttjad serverkraft. De här problemen blir dock mycket mindre om man väljer ett hotell med en lastbalanserad miljö som t.ex. City Network eller EgenSajt. Jag tycker inte man som kund ska behöva kontakta supporten då och då för att få hoppa mellan olika servrar för att kunna få okej prestanda. Det borde man få ändå.

Det konstiga med loggarna är att samtliga tidsmätningar upp når ganska exakt 3 eller 9 sekunder med några tusendelars differens. Det kan inte vara en slump eller relaterat till belastning.
Anledning att vi valde FSData var just prestanda. Vi testade flera hotell men hos FSData blixtrade det bara till när vi laddade sidorna. CityNetwork finns det en annan tråd om här på WN om vad som var otillfredställande.

Jag är generellt trött på att jag som kund oftast vet mer än supporten man ringer till, eller teknikern man blir kopplad till. Det gäller flera webbhotell. När det gäller belastning och nertider så är supporten ofta ovetandes om driftstörningarna, om det inte varit flera timmar. Det är högst pinsamt att behöva informera webbhotellen om deras egna brister, det borde dom känna till innan jag ringer. De borde alla lägga externa bevakningar på maskinerna att börja med, t.ex. via pingdom. Intern bevakning är uppenbarligen otillräcklig.

Vilken tråd om CityNetwork syftar du på?

Givetvis har webbhotellen bevakning på sina maskiner men det är ju inte möjligt att externt bevaka svarstider på varenda site som de hostar. Sedan är ju inte supportpersonalen som sitter och övervakar så de kan ju inte vara liveuppdaterade med status på servrarna även om kommuniktaionen mellan tekniker och support ofta kan bli mycket bättre.
Många gånger beror dessutom störningarna på att det är problem i nätet någonstans mellan dig och webbhotellet och detta är ju utanför webbhotellets kontroll och är oftast beroende av vilken ISP man har.
Det är hur som helst väldigt mycket mer komplext än vad du verkar tro att driva ett webbhotell.

Jag tycker tvärtom han har fog för sin kritik; förutsatt att hans testscript låg lokalt. Har man inte en intern övervakning som säkerställer att databas-anslutningen går på en bråkdel av en sekund så vore det bättre att bara slänga upp en wordpress-demo på en separat host på varje server och övervaka denna - tills man fått till en hyffsad egen övervakning.

Att support-personal har tillgång till systemstatus i realtid är för mig också en helt grundläggande funktion för att supporten faktiskt ska vara informerad. Det borde inte krävas mer än ett par timmars utbildning och förutsatt att det finns en vettig övervakning för teknikerna är ju också exporten/anpassningen snabbt fixad.

Dock måste jag säga att när svarstiden är nästan exakt 9 sekunder många gånger får det mig också att tro att felet kan ligga hos skribenten. Laddar han in ett stort bibliotek innan testkoden med några inneboende problem? Gör han testerna från en extern maskin och så att han faktiskt testar sitt nät mer än han testar svarstiden hos databasen? Men sen finns ju också möjligheten att de körs lokalt på webbhotell utan någon felande kod inblandad och databas-servern ger 3-9 sekunders tider för anslutning och inloggning. Det är långt ifrån acceptabelt för någon miljö - oavsett om det är billig shared hosting.

Sen kan ju också nämnas att persistent connections till MySQL nästan alltid är totalt felanvändna och ger mer skada än nytta.

Du tog det där citatet helt ur sitt sammanhang. Jag har inte på något sätt påstått att han inte har anledningen att klaga för det har han verkligen. Det är inte acceptabelt som jag skrev i mitt förra inlägg i tråden.

Givetvis ska supporten ha tillgång till intern systemstatus i realtid, men att se externa mätningar(som efterfrågades) på alla webbhotellets siter är något helt annat. Jag skrev också att det här ofta kan bli mycket bättre.

Jag tänker ofta på optimering i mina skript och med exekveringsförlopp på några tusendels sekunder så är webbplatsen oftast blixtsnabb. Nyttjat RAM c:a 1 Mb. I koden redogör jag för att ingen annan kod kompileras eller körs emellan tidmätningarna.

Man vinner inte mycket på persistent connections i mysql gentemot andra mer komplexa databaser. Anledning till pconnect i mitt fall är i hopp om att hitta en redan öppen kanal istället för att skapa en ny. I avseende just delayen vid anslutning.

Efter att ha googlat lite hittar jag massor med trådar om just 3000ms och 9000ms delayer mot mysql. De beror alla på en bugg i linuxkerneln åtgärdad i 2.6.24.5. Det visar sig att FSDatas kernel från 2008 tillhör just de versioner där buggen bekräftats. Stämmer ju onekligen in med problematiken jag har också.

Länk för den vetgirige: http://www.linuxquestions.org/questi...ctions-613670/

Har ringt upp FSData om detta men de verkar ytterst ointresserade på supporten. Jag tyckte det då var lämpligt att tala med en ansvarig tekniker, och en sådan ska ringa upp mig sa dom. Supportkillen sa inte ens adjö när han la på. Av erfarenhet 2 ggr tidigare kommer nog aldrig teknikern ringa. Men vi väntar och ser... :)

Ser ingen mening att använda ticketsystemet för supportärenden. Det tar alltid minst 2-3 dagar innan ärendet vänder.

Måste bara berömma FSData utöver all kritik i tråden jag gett. Har talat med tekniker Henrik. Han är relativt nyanställd men mkt trevlig och ställde bra frågor och visade stort intresse för ärendet. Bra kille! Han kommer återkoppla imorgon efter att ha undersökt lite mera.

ITisGood.se: Tråden om CityNetwork återfinns här http://www.wn.se/t1049425.html. Det visade sig att Citynetwork tog till sig av kritiken, men jag valde att stänga mitt konto hos dom ändå då. Det är trist att man inte blir bemött förrän man går ut offentligt på WN.se. Min personliga åsikt är att CityNetwork borde få växa till sig lite grann. Hitta en stabil lösning som branschen känner igen och stå fast vid den. Kanske blev jag kund när skruvandet på variabler hade sin topp. Men det är erfarenheten jag fick. För övrigt hade de en svajig prestanda. Ibland jättesnabbt, ibland segade det till åt Bineros håll. Prestandan bekräftade dom hade varit ett problem. Detta var juli/augusti 2011.

Henke är en klippa och en riktigt trevlig prick. :)

Nu blir detta såklart rapporterat och undersökt, men jag kommer noga följa arbetet ändå. Men jag tycker att det låter oroväckande att du behöver vänta 2-3 dagar på att få svar från supporten, för så är det verkligen inte i normala fall. Oftast ligger inte ett ärende obesvarat mer än en halvtimme och som högst ett par timmar. PM:a gärna ditt ärende till mig, så undersöker jag var vi har brustit i våra rutiner.

Om man får svar inom en timme eller tre dagar kanske inte spelar någon större roll om det ändå tar tre månader att åtgärda problemet? :)

Jag håller inte med. Jag ser det istället som två olika saker som behöver åtgärdas. Vår driftchef kommer se över den tekniska biten, så därför fokuserar jag på supporten.

Jag försökte inte på något sätt förringa njoy's ursprungliga problem, om det råkade tolkas på det viset.

jgabor: Hela hösten har det varit flera dagar mellan svaren. Det tillhör mer vanlighet än ovanlighet. På ärendet registrerat den 9 sep svarade FSData först den 16 sep att supporten hade mkt att göra och därefter 19 sep kom det egentliga svaret.

När jag registrerade kontot tyckte jag FSData hade god prestanda. Säljaren sa att FSData ska vara snabbast, annars skulle jag bara ringa så fixade dom det. Man får väl ha lite is i magen om sånt, men det var definitivt inget "bara ringa".

September var före min tid, så jag kan inte svara för hur vi skötte oss då. Men jag arbetar kontinuerligt med vår supportansvarig, och tittar på hur vi kan bli bättre och effektivare. Och det verkar som om du haft en enorm otur, för det är extremt sällan ett ärende tar flera dagar att lösa. Då brukar det oftast gälla ett komplext serverproblem och inte ett "vanligt" supportärende.

Som sagt, PM:a gärna ditt ärende- eller kundnummer till mig så lovar jag att undersöka var i våra rutiner som vi har brustit, och att göra allt vi kan för att det inte ska ske igen. Och var heller inte rädd för att höra av dig till mig, om du får någonsin får vänta flera dagar på ett svar igen.

jgabor: Kan du inte titta på ert system för att bli uppringd också? Jag väntar fortfarande, några veckor efter det att jag knappat in mitt nummer, på att bli uppringd. Hade det varit en gång kunde jag köpt att det var fel nummer jag tryckt in, men 2 gånger av 2 försök har misslyckats.

Fast jag verkar komma till er via något kundtjänstbolag som heter Glidecom, kanske där problemet ligger.

Glidecom är ett systerbolag, som (förmodligen) kommer bli helt migrerat över till FS Data inom sinom tid. Men jag ska absolut undersöka det!

Aha, såg bara att det var de man ringde till, och tänkte att det var nåt kundservicebolag eller så.

Nej nej, inget hos oss är outsource:at eller liknande. Allting är "in house". :)

Kanske det som är problemet ;)

Trevligt att de har hittat en trevlig prick i Henrik. Hoppas att de inte sliter ut honom eller att han hamnar i vanlig nonchalant FS-data-support-lunk.

Har aldrig stött på ett webhotell med mer spydig och nonchalant support som är totalt ointresserad av hur mycket problem deras tilltag ställer till för kunderna som nyttjar deras server och sedan i sin tur sitter med kundsupport i sin tur och försöker hålla en bra kvalitet. Nä fy....

Nu har det gått snart en månad sen jag åter öppnade supportärendet sen september (för femte gången?). Som vanligt är det inget som har hänt. Utöver ett svar att man beklagade dröjsmålet. Jag fick själv genom en enkel googling upplysa FSData att linux kernelversionen de kör innehåller en vedertagen bugg som ger just problematiken. Hade supporten bara själva googlat på min problematik så var det toppsökträffarna. Tillämpas inte Google i FSDatas felsökningar?

jgabor: Talar vi om samma företag? Är jag den enda kunden som får vänta eller som uteblir från svar helt? Det är ju inte ett enstaka tillfälle. Det borde inte vara personligt, och jag försöker hålla humöret uppe när jag ringer. Jag lärde mig tidigt att supporten har morgonhumör och ryter till ibland, men samarbetar bättre när jag är trevlig.

Anders Larsson: Jag har samma erfarenhet, men vid ett tillfälle ringde dom faktiskt upp.

Både utvecklare och tekniker har varit involverade och vi har upptäckt att det är ett fåtal servrar som kör kernelversionen med buggen du hänvisar till. Åtgärder är dock planerade och rullas ut inom kort.

Jag beklagar även att du upplever att supporten har "morgonhumör", så ska det givetvis inte vara. Vi ska vara lika glada och tillmötesgående oavsett när på dygnet du ringer.

jgabor: Alla har morgonhumör ibland. Det är ju en del av att vara människa. =) Ge Henke den assistans han behöver så vi kan få bukt med detta. När FSData säger "snart" delar vi inte samma uppfattning av tid. Betyder "inom kort" dagar, veckor, eller månader?

Det är idag onsdagen den 22 februari 2012. Problematiken som ärenderegistrerades hos FSData den 9 sep 2011 kvarstår. Trots kritiken i forumet nonchalerar FSData vad som händer. Nu är jag förbannad och besviken. Hur oansvarlig kan man bli egentligen?

Jag har 10 ärenden registrerade hos FSData sedan 9 sep, varav 8 berör samma ärende. De lovar att återkomma, sen skiter dem i det och ärendet stängs ner. Nästan samtliga ärenden är besvarade dagar/veckor efter.

Jag citerar Jgabor här på forumet. "Oftast ligger inte ett ärende obesvarat mer än en halvtimme och som högst ett par timmar."

22 jan återöppnade jag ärendet. 11 dagar senare får jag FÖRSTA svaret på supportärendet. Denna gång från driftchefen (jgabor själv?). Han meddelar att han har annat att göra, men tittar på ärendet om en vecka. Vad är viktigare än att åtgärda Sveriges sämsta MySQL prestanda (se www.webhosting-performance.com).

Idag 22 feb ser jag att ärendet är avregistrerat av helpdesk utan återkoppling.

Avregistrerat? Var är min återkoppling?

Nu får det vara nog. FSDatas säljargument är att vara sveriges snabbaste webbhotell. Snabba på vadå? Snabba på nonchalera sina kunder kanske?

Vad anser ni?

Gällande MySQL-prestandan, så nej–jag är inte driftchef. Det är Jonas Björk som är det, och han tillträdde som driftchef i november (jag tillträdde som webbhotellschef i oktober). Han tittade redan för ett par månader sedan på bl.a. webhosting-performance.com och har sagt att det är hans personliga uppdrag att få upp FS Data i toppen vad gäller MySQL-prestanda. Så det kommer vi titta närmare på inom kort.

Dock vill jag även nämna att den dåliga MySQL-prestandan gäller inte för samtliga servrar. Problemet du rapporterade plus ett par olycksdrabbade servrar har lett till ett högt genomsnittsvärde som inte riktigt stämmer överens om man tittar på enskilda servrar.

Problemet med MySQL som du rapporterade blev löst inatt, och är en av orsakerna till omstarten av våra MySQL-servrar som vi har skrivit om på vår driftstatus. Det var egentligen schemalagt på ett betydligt tidigare datum, men blev tyvärr uppskjutet av en rad orsaker.

Om du följt vår driftstatus och vår blogg, så har du kunnat läsa att vi tyvärr har råkat ut för en mängd större störningar. Det började december med elarbetet, och fortsatte i januari när vi skulle övergå till våra nya Juniper-brandväggar samt byta internetleverantör från Telenor till Telia.

Detta byte var planerat i minsta detalj och utfördes endast nattetid för att inte påverka våra kunder, men åtskilliga gånger så ledde det till driftstörningar bland annat för att Telenor vid flera tillfällen inte lyckades konfigurera sin router korrekt så att de tog tillbaks nätet från Telia. Det ledde till ett "krig" mellan Telenor och Telia av vår IP-trafik, och detta kunde vi tyvärr inte påverka eftersom Telenor hade agerat fel.

Dock är internetleverantörsbytet nu genomfört, och borgar för bättre prestanda och stabilitet då vi är uppgraderade till att ha två gigabit-förbindelser på två olika stamnät som går in på var sin sida av byggnaden.

Alla dessa driftstörningar har lett till ett flertal mindre sådana och som i sin tur har lett till en oerhört ökad mängd supportärenden att behandla. Därför har våra svarstider inte varit i närheten av vad dem brukar och ska vara. Men som du kan läsa på vår blogg så är de stora bitarna åtgärdade och vi har en lång lista på förbättringar, som vi kommer lansera under 2012. Läs gärna om vårt förbättrade stöd för PHP, som bland annat introducerar möjlighet att sätta PHP-version på katalognivå samt PHP 5.4-RC.

Detta inlägg blev betydligt längre än vad jag hade räknat med, men jag tycker det är viktigt att du får hela historien så att du förstår att vi faktiskt arbetat stenhårt på att lösa de problem som vi har haft. Vi menar det verkligen när vi säger att vi vill vara Sveriges snabbaste och stabilaste webbhotell. Och just nu ser det faktiskt ut som om vi kan nå dit…

- Det låter jättebra. Kan vi inte få se fler maskiner på webhosting performance?

- Vi vet att den beror på linuxbuggen i kernelversionen. Efter att ni uppgraderat mysql maskinerna försvann 9 och 6 sekunder delayen och även de flesta 3 sekunders delayer. Det kvarstår alltså 3 sekunders delayer men i mindre bemärkelse och jag tror det beror på att www maskinerna fortfarande körs med kernelbuggen.

Det är sant att ni får ett högt snittvärde. Men så här ser också loggen ut:
Anslutning #1: 1 ms
Anslutning #2: 1 ms
Anslutning #3: 1 ms
Anslutning #4: 3000 ms <----
Anslutning #5: 3 ms
Anslutning #6: 1 ms
Anslutning #7: 2 ms
Anslutning #8: 4 ms
Anslutning #9: 1 ms
Anslutning #10: 1 ms

Det syns inget på grafen för mysql16, men delayerna förekommer även där.

- Vad gäller omstarten av mysql maskinerna med ny konfiguration. Jag förstår inte syftet med driftstatus sidan. Jag bevakade den i 3 h och det stod bara "Inga problem rapporterade". Ni har bekräftat att det var problem med mysql16 och att den låg nere timmar.

- Det låter olyckligt och talar för att ni hade mycket att göra i december. Men det förklarar inte varför supportärenden avregistreras utan notis eller att man inte behandlar ärenden när man har möjlighet. Vi pratar om 6 månader av supportkontakt.

- Bandbreddsmätningar på webhosting performance visar ingen kapacitetförändring hos er. Loopia och Binero mäter mot samma server (sunet) och visar åttadubbelt.

- Märker inte av nån försämring i väntetiden att få svar av supporten. Det är alltid flera dagar väntan. Jag är mest besviken över att ni avregistrerar ärenden i utan notis. På det senaste står det "Avslutat av helpdesk" och jag väntar fortfarande på svar.

- Jag har ingen inblick i er verksamhet. Jag ser bara utsidan. Om ni jobbar stenhårt känner jag spontant att ni glömmer det viktigaste. Få kunden att känna sig hörd, bemött, och informerad.

- Det är bra att du känner hopp även om ni ligger så långt efter konkurrenterna. Ni måste ha kunder på maskinerna också. Idag är ni dubbelt så dyra, hälften så kraftfulla och erbjuder nästintill ingen support alls.

Varför inte börja med att konfigurera/investera i en prototyp plattform. Lägg upp den på webhosting performance och bevaka stabiliteten. Börja flytta över prioriterade kunder när ni uppnåt stabilitet och nöjda resultat. När kunderna är flyttade, formatera om de gamla maskinerna och gör dom samma. Utgå ifrån att det inte ska se ut som maskin 23 åtminstone. http://www.webhosting-performance.co...?provider_id=1

Det kan vara dödstöten att peta på maskiner som kunder redan ligger på om det uppstår problematik.

Ingen dum idé. Jag vidarebefordrar förslaget till vår driftchef.


Kerneln är uppgraderad till en helt ny version, så då skulle det vara att buggen även finns i den nyare kerneln eller att det beror på något annat. Vi ska undersöka.


Som Sulo svarade, så är vi väl medvetna om att driftstatus inte används i den utsträckning vi hade velat. Det ber vi om ursäkt för! Vi ska försöka bli bättre på den fronten.

Ett ärende kan antingen avregistreras automatiskt för att inget hänt under en längre period, alternativt att någon på kundtjänst stänger ärendet eftersom de anser att det berör ett liknande problem i ett annat öppet ärende. På så vis slipper vi göra det dubbla arbetet för att lösa ett och samma problem, och kan lättare få överblick över vilka problem som råder för tillfället. Dock ska de meddela detta i samband med stängningen. Jag ska prata med vår kundtjänst och se till att det blir bättring på den fronten.


Det beror på att vi inte gått över till gigabit-nätverk för samtliga av våra servrar ännu, men det är något vi arbetar på. Så det kommer tids nog… Vi skyndar långsamt, för att försöka påverka våra kunder minimalt.

Du kan alltid öppna ett ärende igen genom att helt enkelt svara på det. Att det ofta är lång väntetid för just dig beror nog på naturen av ditt ärende… Det gäller något som inte direkt kan betjänas i kundtjänst, utan vi måste involvera en tekniker. Och när det gäller saker som att uppgradera en kernel, så är det inget vi kan fixa samma dag som du nog förstår.

Men jag vet inte exakt vad dina olika ärenden har handlat om… PM:a mig gärna ärendenummer, så ska jag undersöka.

Helt enig. Kunde inte sagt det bättre själv.

Att vi ligger långt efter skulle jag kraftigt vilja sätta mig emot. Om man bortser de senaste månadernas driftstörningar, så har vi historiskt sett levererat högre prestanda, stabilitet och snabbare svarstider än de flesta webbhotellen. Binero och Loopia som du nämnde tidigare har ju även dem haft större driftstörningar, Binero med sin migrering till Binero 2.0 och Loopia med sina e-postproblem som resulterade i dataförlust, tragiskt nog.

Dessutom så anser jag att vårt stöd för PHP, Ruby on Rails, Pyhon och Django är bland de bästa, om inte de bästa, i Sverige–speciellt med tanke på att det knappt finns några andra webbhotell som erbjuder alla dessa programmeringsspråk. Det är även ytterst få webbhotell som har stöd för versionshantering i samma utsträckning som vi… Listan över innovationer kan göras rätt lång.

Dock hjälper det inte mycket när den grundläggande infrastrukturen och plattform inte fungerar till 100%–vilket är precis det vi arbetar med just nu.

Med detta vill jag inte säga att allt är guld och gröna skogar–långt ifrån! Dock har de senaste månaderna varit rejält tråkiga för en stor del av våra kunder, vilket kan lätt få en att tro att det alltid varit så, vilket inte är fallet.

FS Data hade inte existerat sedan 1997 i så fall.

Gabor: Snälla, skippa sälj snacket. Ingen här är intresserad av att ni har stöd för PHP, PHP på katalognivå, RoR, Python, Django eller versionshantering.

Det låter bara illa över att du försöker länka till er sida eller försöka försköna över vilka innovationer ni har på er 80tals plattform.

Lös problemet och gör kunden nöjd istället för att försöka sälja.

Det var som svar på njoy's påstående att vi låg långt efter, där jag försökte påvisa att vi faktiskt inte bara legat på latsidan i alla dessa år utan faktiskt har lanserat nya och/eller förbättrade tjänster–som löst kunders problem eller underlättat deras vardag. Så jag anser att mitt "säljsnack" för fullt befogat… Jag ser inte hur jag skulle kunna besvara ett sådant påstående på annat sätt.

Och 80-tals plattform? Visst, den har många år på nacken, men större delen av vår plattform är egenutvecklad och har utvecklats aktivt under alla dessa år. Visst, det kanske inte sett fint ut på ytan eftersom gränssnitten för bland annat vår kontrollpanel inte fått den kärlek den har förtjänat, men den bakomliggande tekniken har aldrig varit omodern–om än att den haft sina brister här och var. Vi uppdaterade dock utseendet förra veckan med vad vi kallar för Waff 2.5, inför en större kommande uppgradering som benämns Waff 3.0. (Förlåt, men: du kan läsa mer om det på vår blogg.)

Att jag länkar till vår blogg, är för att visa att jag inte bara slänger ur mig tomma ord här, utan att det är något FS Data som helhet står bakom.

Som Markus Karlsson skrivit i sin kommentar så är den rätt lik Bineros gränssnitt.

Men hur vore det om ni tar och löser problem ordentligt istället för att skapa "mersälj"? Att ni kommer med nya funktioner och polerar era problem skapar snarare irritation än behåller kunderna. Nu vet jag inte hur er statistik ser ut, men behålla kunder vill man väl

hnn, skippa du skitsnacket om jgabor istället, han måste ju få besvara kritik och andra frågor och självklart jobbar dom parallellt med att lösa saker :)

Tydligen var inlägget för gammalt för att redigera, så det blev dubbla inlägg istället. Ber om ursäkt för det!

Jag ska vara ärlig, och ser inte alls likheterna. Däremot vet jag att FS Datas hemsida har haft nuvarande design sedan 2010-02-21, men det var först nu som vi även uppdaterade designen för kontrollpanelen.

EDIT: Jag kan väl tillägga att orsaken till att vi inte uppdaterar vår design särskilt ofta, så är det främst för att FS Data består främst av tekniker där utseendet inte särskilt ofta är jättehögt prioriterat. Men det är något jag försöker ändra lite på, även om tekniken oftast ska stå i fokus.

Men det är ju precis därför vi bland annat bytt internetleverantör, är igång med att byta ut vårt existerande SAN mot ett toppmodernt sådant, fasar ut PHP 4 och en massa annat, vilket jag gång på gång har försökt demonstrera genom att, hör och häpna, länka till vår blogg.

Svar till jgabor:

Att kerneln är uppgraderad är felaktig information du fått. Jag gjorde en kontroll nu och den visar fortfarande 2.6.24.2 från 2008.

-Tycker du verkligen att ni har nån överblick när du läser min problematik? Att ni slipper dubbelt arbete? Ni slipper väl allt arbete eftersom supporten uteblir och kunder måste återöppna sina ärenden en gång till.

- Hur ska det då "borga för bättre prestanda och stabilitet" menar du? Jag uppfattar som att produkten du lyfter och försvarar, inte finns ännu. Och är det långsamt dit, behöver vi inte ens diskutera den? Låt oss tala om den problematik som finns, inte hur er produkt ser ut 2014.

- Du förstår väl hur det ser ut. 8 återöppnade ärenden under 6 månader. Och du ber mig att för 9:e gången göra samma sak som anledningen till 2:a ärendet, att väcka ett gammalt ärende. Samarbeta istället. Jag tycker mig visat mig tillgänglig som en resurs då jag även rapporterat loggar med mätvärden och tidpunkter och den bakomliggande orsaken till problemen istället för att bara "gnälla". Det är gratis felsökning för er belastade avdelning. Dedikera en tekniker som lyssnar och följer upp.

jgabor: Hur skulle det vara om du, som insatt i den här forumstråden ledde arbetet för supportärendet? Du blir den som tar hela ärendeansvaret och gör all återkoppling. Jag sänder dig då kundnr och supportnr. Förhoppningsvis leder detta till ett gott avslut av den här tråden.

Intressant tråd. Väntar med spänning på FS-datas svar på väl genomtänkt och underbyggd kritik.