Då det är många här som idag kör Drupal hos det svenska webbhotellet Binero och kanske ännu fler som funderar på det tyckte jag det vore lämpligt med en dedikerad tråd för diskussioner kring att använda Drupal hos Binero där vi kan ta upp fördelar, nackdelar, problem och lösningar mm.
Vi har redan diskuterat Binero en del i andra trådar, som t.ex. denna tråd som egentligen handlar om Drupal hos Loopia, men jag hittade ingen dedikerad samlingstråd för allt kring Drupal hos Binero.
Om Binero: Binero är ett av Sveriges största webbhotell som vunnit flera utmärkelser för bra service, hög tillgänglighet och prisvärda paket med mycket funktioner. Binero ägnar sig (så vitt jag vet) endast åt så kallad "shared hosting", dvs att man delar webbserver med flera andra kunder. (Andra former av hosting som vissa webbhotell erbjuder är VPS och dedikerade servrar.)
Jag vet att man kan göra wikisidor också, men wikisidor är helt värdelösa för att hålla igång vettiga diskussioner och så vitt jag kan se går det inte att lägga till kommentarer till wikisidorna här.
Comments
SSH hos Binero
Att kunna logga in med SSH är viktigt verktyg för att effektivare kunna jobba med Drupal (och webbutveckling överhuvudtaget). Speciellt kombinerat med det fantastiska Drush.
SSH fanns förut hos Binero, men försvann förra året på gamla konton. Men i det nya systemet som lanserades i år (kallat "Binero 2.0") finns SSH åter.
För tillfället finns inte kommandot "php" hos Binero (dvs möjligheten att köra PHP från kommandoraden) och det gör att Drush inte fungerar hos Binero även om man har SSH-access. Jag har frågat supporten om detta och de har sagt att de ska kolla på det.
Snål minnestilldelning i memory_limit i PHP
Drupal kan vara rätt minneskrävande för vissa operationer så som att processa bilder med ImageCache eller bygga om omfattande menyer (om man t.ex. kör Administration Menu).
Variabeln
memory_limiti PHP bestämmer hur mycket minne varje PHP-process max kan använda. Binero har idag 48M i gamla systemet och 64M i Binero 2.0. Detta är för lite, och leder till varningar som denna från ImageAPI:I gamla systemet går det dock att öka minnesgränsen genom att lägga till
ini_set('memory_limit', '128M');i settings.php trots att Bineros support hävdar motsatsen.I Binero 2.0 går det däremot inte att öka minnestilldelningen på detta sätt och man kan inte ens betala för att få ökad minnestilldelning. Däremot finns det ett visst hopp om att minnestilldelningen ska kunna ökas i framtiden.
Slut på egen minnestilldelning
Nu verkar supporten har fått upp ögonen för att det går att ställa in minnestilldelningen själv i gamla systemet, såhär skriver de på Binero drift:
Så mycket för att ha tillräckligt med minne hos Binero :(
Nu förstår
jag varför det helt plötsligt blivit minnesbegränsingar på kontot i det gamla systemet, 128M var för bra för att vara sant...
Jag har också upplevt en allmän försämring hos Binero. Kanske beror det på bieffekter som uppstår när de gör migrering. På mitt konto var plötsligt register_globals aktiverat.
Givetvis är det något vi
Givetvis är det något vi håller ögonen öppna för, detta är relativt oroväckande med tanke på att kunder som går runt denna begränsning kan orsaka enorma störningar på våra tjänster och således påverka andra kunder.
Gamla systemet 48MB
Nya systemet 64MB
Vi kommer säkerligen i framtiden kunna ta fram extra tjänster där man kan köpa till mer minne som exekveras per process.
Problemet är lite minne, inte möjligheten att ställa in själv
Ja, egentligen bryr jag mig inte om möjligheten att kunna ställa in detta själv, jag förstår precis hur mycket störningar det kan påverka andra kunder på delade servrar och jag förstår att ni inte kan tillåta det.
Problemet är bara att 48M är alldeles för lite för Drupal.
Inte för besökaren utifrån, men för administrativa åtgärder och t.ex. hantering av bilder. Det är inte för inte som man får en varning om man har mindre än 96M och använder ImageAPI i Drupal.
En av de Drupalsajter jag sköter om i Bineros gamla system klarar inte ens av att spara modul-sidan eller bygga om menyerna utan att det slår i taket och man får minnesfelmeddelande. När jag ställde upp det till 128M försvann alla problem. Därav besvikelsen av att måsta gå tillbaka till 48M.
Jag vet inte hur det är hos Loopia och de andra stora webbhotellen, men åtminstone hos Oderland var det inga problem alls att få 128M tilldelat av supporten utan extra kostnad. Detta kan vara avgörande när man som utvecklare ska rekommendera webbhotell för Drupal.
Binero är så nära att vara ett utmärkt webbhotell för Drupal (nu sedan SSH kom tillbaka) och med några få åtgärder (mer minne och php-cli) skulle ni nå ända fram. Vi är nog många som gärna vill stanna var hos er hellre än att byta.
Efterfrågan på en högre
Efterfrågan på en högre memory_limit är relativ låg i och med nuvarande gräns fungerar bra för våra kunder, vi försöker att anpassa oss efter marknaden och inte specifika önskemål som efterfrågas av enskilda kunder.
Nu har vi heller inte så värst många Drupal kunder liggande hos oss, utan det kan säkert bero på att det fungerar sämre hos oss än hos andra webbhotell. Nu har det säkert fungerat bra för dom som går runt våra begränsningar som vi fick veta alldeles nyss, men när jag slängde upp en installation i 2.0 så laddar den väldigt snabbt och där har vi då trots allt 64MB som vi anser är en generös gräns.
Kan du i så fall skriva lite steg-för-steg hur du gör för att det blir segt? För det är väl som du skrev administrativa åtgärder då som tar längre tid på sig än vanligt.
Jag förstår att efterfrågan
Jag förstår att efterfrågan på högre memory_limit är låg och för säkert 98 procent av era kunder så räcker 48M mer än väl. Vad jag efterlyser är en lite ökad flexibilitet för de som har lite högre behov, men ändå inte så krävande att det är dags att byta upp sig till VPS eller dedikerad server.
Jag vet sedan tidigare att ni månar om att ha likadana miljöer för alla och därför inte kan specialanpassa lösningar för enskilda kunder. Så det kanske är svårt/omöjligt att åsidosätta era standardvärden för enskilda kunder? Vissa webbhotell jag jobbat med har enskilda php.ini för varje kunde som de kan justera vid behov.
Jag driftar inget själv så jag har svårt att säga om 64M är generöst eller inte, det kanske är väldigt generöst, jag vet bara att det är mindre än vad som rekommenderas och att jag kan få mer på annat håll (128M hos Oderland, har 200M på ett webbhotell i USA). Det kan hända att bytet från 48M till 64M är tillräckligt för att lösa alla mina problem (se mitt test nedan).
Jag är också medveten om att Drupal inte är så optimerat som man skulle kunna önska. Det finns cachningsfunktioner som hjälper till en del, men ändå handlar det ofta om en oherrans massa databasförfrågningar för en enkel sidvisning på en måttligt komplicerad sajt. Har man dessutom många moduler (vilket ofta är fallet med Drupal eftersom kärnan inte är tillräcklig för att göra en normal webbplats) kan de stjäla ytterligare kraft/minne.
När det gäller segheten så upplever jag inte att Drupal är segt hos er i gamla systemet, segheten gäller något annat (se nedan). Mitt enda problem har varit att vissa administrativa åtgärder helt enkelt krävt mer minne än 48M och det resulterar i "Fatal Error".
En av åtgärderna som brukar leda till Fatal Error är att spara modulsidan (admin/build/modules). Eftersom ni inte ännu slagit av möjligheten att ställa in memory_limit gjorde jag ett test nu där jag sparade modulsidan med lite olika minnesinställningar:
48M: Fatal Error
64M: Inga problem
128M: Inga problem (förstås)
Detta är förstås specifikt för just denna Drupalinstallation beroende på vilka moduler jag har osv, så det är inte säkert att en annan installation har samma problem. Jag kan försöka sätta ihop en steg-för-steg-beskrivning senare eller sätta upp en testinstallation och försöka återskapa det utanför den aktuella sajten.
Däremot har jag precis börjat använda Binero 2.0 för en kund och där finns en seghet. Varje förfrågan tar lite för många sekunder utan att det händer något, sedan ritas sidan upp snabbt. Det är ännu för tidigt för att jag ska påstå att det är ert fel. Jag använder t.ex. fortfarande den temporära domänen och det kanske är DNS-uppslagningar eller annat som lägger på en viss fördröjning på varje förfrågan. Jag ska kolla närmare på det.
Prestanda i Binero 2.0
Jag har precis börjat testa att köra Drupal i Binero 2.0 och för tillfället så slår jag av att det är mycket segare än i gamla systemet. Men jag har inte hunnit testa så mycket så jag vet inte om det är ett generellt problem eller ett tillfälligt problem för min del pga vissa omständigheter.
Hur upplever ni andra att prestandan för Drupal är i Binero 2.0 (speciellt jämfört med gamla systemet)?
Jag har inte testat Binero
Jag har inte testat Binero 2.0 än men det är tråkigt ifall något sånt här förstör en i övrigt riktigt bra tjänst.
Långsamma databasservrar också
Vi har arbetat med flera drupalwebbar hostade hos Binero och upplever dom som ojämna. Tidigare var dom bra och en förklaring kanske kan vara att de har haft en stor kundtillströmning, vilket innebär ett större tryck.
Problematiken är framför allt:
I vår dialog med Binero menar dom att databasservrarna är så snabba som man kan förvänta sig av en delad miljö.
Vissa webbar går hyfsat men de med lite större tryck fungerar inte att hosta hos Binero pga. prestandaproblem.
Så mitt tips är:
Enkla sajter med få databasanrop - Binero funkar ok
Komplexa sajter med många databasanrop - Välj annan hosting
Binero har en bra kundservice och förmågan att ta till sig kritik så ökad memory_limit kan nog hända i framtiden.
--
Happiness - www.happiness.se
Inte möjligt att köra Drush hos Binero
Som en del av fördelarna med SSH-access för Drupal är möjligheten att köra Drush. Tyvärr går detta inte hos Binero då de inte tillåter PHP på kommandoraden. Jag fick detta svar från supporten efter att de hade undersökt möjligheterna:
Så för den som hoppades på att SSH hos Binero innebar Drush ser det tyvärr mörkt ut.
Det finns ett sätt att köra Drush utan SSH men det verkar inte heller fungera på Binero enligt den här tråden.
Problemet med Binero är att
Problemet med Binero är att det bara har ett erbjudande. Man kan inte skala upp sitt konto vilket stället till det. I den nya miljön kan man dessutom inte lägga till CRON-jobb utan att kontakta supporten. Senaste tiden tycker jag även att deras kontrollpanel har blivit väldigt seg. Going down....
--
Peter Törnstrand, Happiness
Binero 2.0 mycket långsammare än Binero 1.0 (och Oderland)
Jag upplevde att Binero 2.0 var långsammare än gamla systemet och jag har ansträngt mig för att göra ett riktigt test av det. Jag installerade en och samma Drupalinstallation på tre stycken konton; Binero gamla systemet (server: Obelix), Binero 2.0 (server: okänd) och Oderland (server: Thea).
Det är exakt samma version av Drupal (6.16), samma filer, samma moduler aktiverade, samma Devel-genererade innehåll, samma databas osv. Helt identiska installationer med andra ord. Jag flushade cachen, körde cron och laddade om startsidan tre gånger innan jag noterade resultatet. Jag var inloggad som använder 1 på samtliga sajter. Ingen cache påslagen.
Binero gamla systemet:
Executed 68 queries in 7.84 milliseconds.
Page execution time was 264.8 ms.
Binero 2.0:
Executed 68 queries in 92.18 milliseconds.
Page execution time was 728.03 ms.
Oderland:
Executed 68 queries in 10.6 milliseconds.
Page execution time was 247.73 ms.
Binero 2.0 är inte bara lite långsammare, det är mycket långsammare. Bineros gamla system och Oderland var däremot väldigt nära varandra i resultatet.
Det var ganska få noder i första testet, så jag genererade 50 kategorier och 500 noder med Devel. (Noterbart är att själva genereringen tog mycket längre tid på Binero 2.0 än de övriga sajterna.) Sen kopierade jag databasen och files-katalogen från en av installationerna till de två andra (för Devel genererar lite olika mycket bilder etc, så det blev inte exakt samma antal förfrågningar till databasen).
Binero gamla systemet:
Executed 133 queries in 14.72 milliseconds.
Page execution time was 345.59 ms.
Binero 2.0:
Executed 133 queries in 344.21 milliseconds.
Page execution time was 1947.97 ms.
Oderland:
Executed 133 queries in 24.13 milliseconds.
Page execution time was 319.38 ms.
Siffrorna varierade lite mellan omladdningarna, men varje gång stod det klart att gamla Binero och Oderland presterande ungefär likvärdigt medan Binero 2.0 var ohjälpligt efter hela tiden. Detta bekräftar den känsla jag haft när jag jobbat med en ny Drupalsajt på Binero 2.0.
Sen testade jag modulsidan (admin/build/modules):
Binero gamla systemet:
Executed 430 queries in 177.48 milliseconds.
Page execution time was 2644.92 ms.
Binero 2.0:
Executed 430 queries in 810.74 milliseconds.
Page execution time was 12285.58 ms.
Oderland:
Executed 430 queries in 139.44 milliseconds.
Page execution time was 972.89 ms.
Siffrorna talar för sig själva. Om mitt konto på Binero 2.0 är representativt för systemet så är Binero 2.0 inget att lägga en Drupalsajt på för närvarande.
Binero 2.0 kördes på ett temporärt domännamn (exempel.se.preview.binero.se) men jag tror inte det är skälet till det dåliga testresultatet.
Vill bara hänga på tråden för
Vill bara hänga på tråden för att faktiskt se vad Binero ger för respons i denna tråd. För mig är det lite oroväckande att de inte kommenterat ditt test AdrianB (på två månader). Jag har placerat kunder hos Binero (1.0) nästan uteslutande i ett par år av tre huvudskäl; prestandan för mellanstora siter, kontrollpanelen och supporten (att de spelar nes-musik i telefonkön gav plus i kanten).
I några få fall har behovet av ökad minnesgräns i php gjort att jag använt mig av den manuella inställningen upp till 96MB och precis som det påpekas ovan så är den funktionaliteten ovärderlig men relativt sällan använd.
Innan jag börjar gnälla tänkte jag påpeka att Binero 1.0 varit i en egen klass på marknaden. Vår verksamhet behöver kunna hänvisa till "välkända" leverantörer som har tillförlitlig prestanda och där har Binero 1.0 utmärkt sig.
Jag har försökt ha tålamod med 2.0 eftersom jag vet att migreringar kan ställa till det mesta men jag börjar tappa tilltron. Efter att ha placerat några kunder hos Binero 2.0 samt testat både Drupal- som ett par Wordpress-installationer - så har Vi har fått klagomål från Våra kunder. Hade det varit tunga siter med tunga funktioner så hade jag haft förståelse för långsamma databasservrar - de är ju delade - men vi snackar väldigt enkla installationer med väldigt sparsmakat innehåll. För att få dem att rulla respektabelt Måste vi köra boost och sätta cron sällan.
När Mitt företag börjar tappa Våra kunders förtroende pga den dåliga prestandan hos webbhotellleverantören så har det gått över gränsen. Tyvärr.
Jag vet inte om Binero håller på att göra en Loopia - bli för stora för sitt eget bästa?
Jag kan bara hålla med, både
Jag kan bara hålla med, både i hyllningen till Binero 1.0 (speciellt innan de tog bort SSH och SFTP) och besvikelsen över Binero 2.0, hittills. Eftersom jag ändå trivs med Binero i övrigt hoppas jag verkligen de kan lösa problemen.
När det gäller SSH-biten i Binero 2.0 ska man som Drupal-utvecklare veta att det inte går att köra Drush (se mitt inlägg ovan) trots SSH-accessen.
Man ska även veta att rättigheterna inte blir korrekta för filer om man jobbar med SSH eller SFTP. T.ex. om man drar hem en modul med wget och packar upp den så får inga filer rättigheter så att de kan läsas utifrån, så man måste manuellt gå in och justera rättigheterna för kataloger och filer i efterhand.
Jag blev faktiskt väldigt
Jag blev faktiskt väldigt glad när jag fick reda på möjligheten till SSH i Binero 2.0 men lika besviken när jag märkte att det inte gick att använda till något intressant. Vi ser det dock fortfarande som en lyx att kunna göra allting via SSH/Drush - men visst skulle det vara skönt att kunna effektivisera sitt arbete i den omfattningen det är möjligt via SSH.
Men för att få allt så bra måste man kanske tom öppna eget webbhotell...
Just nu framstår Oderland
Just nu framstår Oderland allt bättre i mina ögon.
För en kund (en Drupalsajt) öppnade vi konto på Oderland förra året efter att jag hade gjort research och kommit fram till att många rekommenderade dem och för att de hade SSH vilket jag verkligen ville ha. SSH är lite av en lyx och rätt sällsynt på svenska webbhotell, men inte desto mindre viktigt i mina ögon.
Men i vintras upplevde vi att det var så stora problem med prestandan att vi bytte till Binero. Det var ett skumt fel där första förfrågan tog alldeles för lång tid medan efterföljande förfrågningar rullade på rätt hyfsat. Men det blev alltså ohållbart, jag hade bra kommunikation med Oderlands support men just då kunde de bara erkänna att de inte fixade att förbättra det just då.
Sedan dess har det dock hänt saker, Oderland har lyckats komma till rätta med vissa flaskhalsar och mina testvärden ovan från slutet av våren visar på att Oderland numera är riktigt kvicka. Nu håller jag på att sätta upp ett nytt konto hos dem och åtnjuter blixtrande snabb SFTP-anslutning (tyvärr problem med Binero även på den punkten på grund av Bredband2 enligt Binero), välsignelsen av att jobba med Drush och helt acceptabel Drupal-prestanda. Så långt känns det väldigt lovande.
Att byta webbhotell är dock ett bök och sällan något kunder vill öppna plånboken för fullt ut, så jag hoppas fortfarande att Binero får ordning på Binero 2.0 för mina existerande sajter där, speciellt de som idag ligger på 1.0 och fortfarande har bra prestanda. Det har blivit bättre, men det är inte bra.
Re: Binero 2.0 mycket långsammare än Binero 1.0 (och Oderland)
@agogo & AdrianB: Ber om ursäkt att vi inte följt upp det (forumtråden försvann tyvärr lite i sommarledigheterna) men jag ska försöka ge lite ljus på hela ärendet.
Ja, vi har haft prestandaproblem på ett av klustrena i vår nya miljö. Detta är löst genom att ett nytt bättre optimerat (med ny mjukvara) har satts upp vilket löste problemet. Vi håller nu på jobba på att optimera ut ett ytterligare webbserverkluster som kommer ersätta det första helt och hållet (som tyvärr var dåligt optimerat med annan mjukvara vilket gjorde att problem uppstod när antalet kunder i det växte snabbt). Hur som helst är det något som vi givetvis både kan och ska lösa, och ni som har problem med seghet uppmanar vi att skicka in ett mailärende till oss med vilket domännamn det rör så ska vi se vad vi kan göra.
Problemet är alltså inte databasrelaterat eller beror på någon lastrelaterad seghet i mysql-servrarna, utan är helt reltaterat till lastbalanseringen, virtuella uppsättningen och storageconfigurationen av det tidigaste litespeedklustret (webbserversidan) vi satte upp i Binero 2.0.
@blixxa: Cronhantering via kontrollpanelen kommer snart. Det är mycket som ska läggas till samtidigt som vi jobbar med migreringsarbetet så allt kommer tyvärr inte på en gång. Vi kommer också införa fler typer av tilläggstjänster på sikt (t.ex. höjd memory_limit)
Till sist så beklagar vi att en del kunder fått uppleva långsamma applikationer (just drupal och concrete5 har varit de två som märkts av absolut mest - men också andra databasintensiva applikationer som Wordpress och Joomla har till viss del blivit drabbade) och uppmanar åter igen er med långsamma applikationer att maila och hänvisa till denna tråd så ska vi lösa era problem.
Mvh Johan
Det låter bra att det jobbas
Det låter bra att det jobbas på. Jag vill helst vara kvar hos er om det bara är möjligt, men tills vidare placerar jag inga nya Drupal-kunder hos er av förklarliga skäl.
De tester jag gjorde i slutet av maj (och publicerade här den första juni) har inte sett några nämnvärda förbättringar hittills. Jag kollade testinstallationerna nu igen. Mitt Binero 2.0-konto ger fortfarande testresultat som är 5-10 gånger långsammare än Binero 1.0 för exakt samma installation.
Ni har mina uppgifter i ärende AAT-997308 från den 30 maj i våras.
Jag glädjs över att ni tar er
Jag glädjs över att ni tar er tidan att kommentera här på drupal.org men precis som AdrianB så kommer vi inte heller att kunna placera Drupal-kunder hos Binero förrän prestandaproblemen åtgärdats.
Eftersom vi jobbar med många olika kunder hellre än några få så är det inte en hållbar lösning att vi ska behöva kontakta er support för varje kund - när problemet är detsamma för dem alla. Det skulle helt enkelt kosta oss för mycket att belastas av den sortens ökade administrationarbete.
Angående "databasintensiva applikationer" så är frågan vad poängen med ett webbhotell är som bara klarar av webbplatser utan världens mest populära och använda CMS (Joomla, Wordperss & Drupal)? Problemen har ju trots allt uppstått även på grundläggande installationer med sparsmakat innehåll.
Vi började använda Binero i
Vi började använda Binero i april 2010 pga alla bra recensioner. Men redan från början noterade vi att det gick lite långsamt, men eftersom vi jämförde med en Drupal-installaton på en gammal server hos FSData (den är nu uppgraderad) så var inte skillnaderna så stora. Men under hösten började det bli ohållbart.
Så vi utförde en enkel (ovetenskaplig) test: vi gjorde en backup på en Drupal-installation hos Binero 2.0 och återskapade den på en (ny) server hos Binero. Sedan testade vi att öppna samma sidor i samma webbläsare (vi använde modulen Devel för att ta tid och jämföra minnesåtgång och utnyttjade inte Drupals cachning). I genomsnitt gick vanliga sidor ca 3 gånger fortare i FSData-kopian. I administrationsgränssnittet (t ex modulsidan) blev skillnaderna ännu större. Intressant att notera är också att minnesåtgången i genomsnitt enligt Devel var ca dubbelt så stor hos Binero. Vad beror det på? PHP-version? Inställningar?
Så vi använder numera FSData i flertalet av våra Drupal-installationer. FSData har inte något särskilt användarvänligt administrationsgränssnitt och är dyrare än Binero, men erbjuder (som vi uppfattar det) en mycket bra teknisk plattform (exempelvis kan man med .htaccess ställa in hur mycket minne som ska användas och SSH är standard) och även bra support.
Intressant att höra att
Intressant att höra att minnesåtgången är så mycket högre hos Binero. Jag kör sedan ett par månader en Drupalsajt på Binero 2.0 och kan bara instämma i övriga kommentarer att det ofta går riktigt segt. Att försöka administrera en sida kan vara oerhört frustrerande. Jag jämför med Hostmonster där jag har ett antal andra Drupalsajter.
På Johans/Bineros uppmaning ovan kontaktade jag dem med hänvisning till denna tråd, men fick "jag upplever den som väldigt snabb" och ett Pingdomtest till svar. Så "så ska vi lösa era problem" verkar vara i överkant. Eller också har man en annan syn på vad som är ett prestandaproblem.