Server voor grote website(s)

[semyazaruax]

Beste,

momenteel hebben we 12 grote webwinkels draaien, echter gebeurd het regelmatig dat de server(s) er uit liggen en -of dat de laadtijd van een pagina gewoon weg onbeschoft lang duurt omdat de server "traag" is of een hikje heeft. Waarom of waardoor is ons eigenlijk niet bekend, wel weten wij dat de servers enkele jaren oud zijn en sommige zelfs behoorlijk oud m.a.w. oude CPU, weinig RAM.

We hebben per maand gemiddeld 150.000 bezoekers per website (maal 12 dus). Ik weet dat het weinig informatie is, maar we krijgen van het bedrijf waar alles gehost word weinig tot geen fatsoenlijke informatie.

Nu zitten wij er over te denken om over te stappen naar een andere host en nieuwe hardware aan te schaffen.

Mijn vraag aan jullie is, of jullie suggesties hebben voor de hosting en misschien een goede suggestie voor de hardware kunnen geven.

We hebben verschillende websites draaien in onder andere: NL, EN, UK, ES, IT, PT.

Ik heb wel diverse aanbieders bekeken welke hosting aanbieden alleen zit er behoorlijk veel verschil in, en het meeste dat zegt mij toch niks qua specificaties en zo voort.

Ik hoop dat jullie wat suggesties kunnen geven voor hardware en bedrijven waar we de hosting onder kunnen brengen

P.S. Alles is momenteel onderverdeeld in een cluster van ca. 6 servers waar ook twee admin's op draaien en een vetaal systeem gezien alle websites in diverse talen beschikbaar zijn.

[Miepermans]

Goedemorgen,

Als ik vragen mag, wat hebben jullie zelf al onderzocht ? Ik heb het vermoeden dat hier een commerciele opdracht neergelegd word bij tweakers. Dat is natuurlijk niet de bedoeling.

Als je aan geeft wat er reeds onderzocht is, dan kunnen we je misschien verder helpen.

[Gomez12]

In wezen moet je hier geen hardware tegenaan gooien (want je hebt geen idee wat voor hardware wel goed draait) maar eerst gewoon je website laten doormeten waar de bottle necks zitten en dan aan de hand daarvan bepalen wat voor hardware je nodig hebt.

Compleet blind gezegd kan je het wellicht wel in "the cloud" onderbrengen met automatische scaling aangezet, alleen dan heb je wel een risico dat je een torenhoge rekening krijgt als er 1000 vm's opgestart worden als je software gewoon traag is.

Oftewel meten is weten, dus eerst meten.

[Viper®]

Hosting bedrijven zullen over het algemeen dezelfde vragen stellen als wij hier welke betrekking hebben tot verkeer, aanvragen, loads, performance etc.

Zolang je weinig tot geen data hebt van de huidige hosting is het moeilijk een keuze maken.

Bijna alle hosting partijen kunnen een offerte maken voor het hosten met eventuele groei en piek momenten etc. Denk dat je toch met hosting bedrijven contact moet opnemen.

[KoeKk]

Dit is een beetje brede vraag, het hangt enorm af van de load van de websites hoe zwaar de server belast wordt. 150k aan bezoekers op een statische HTML site stelt andere eisen dan 150k bezoekers op een niet geoptimaliseerde Magento webshop

(En wat Gomez zegt)

Als je zelf niet de kennis in huist hebt: ga op zoek naar een hosting partij gespecialiseerd in maatwerk hosting en waar je een goed gevoel bij krijgt. Een goede hoster kan je adviseren en zelfs assisteren bij je diagnose naar performance problemen.

[semyazaruax]

Hi, dank voor je reactie Miepermans

We doen eigenlijk alles intern we zijn alleen niet blij met het bedrijf dat de hosting verzorgd (een vriend... ja, daar heb je het al hahaha) en willen eigenlijk gewoon zelf nieuwe servers aanschaffen en het bij een "echt bedrijf" onderbrengen.

We weten zelf niet goed wat te doen, hebben wel gekeken naar bedrijven als pcextreme.nl en dergelijke en naar een rack, maar je hebt al een rack voor 300 euro, maar je hebt ze ook voor 5000 euro per rack.

Gezien wij zelf niet heel veel van servers af weten, hadden we iets van, we vragen het op Tweakers want de mensen hier hebben geruime kennis en ervaring van en met servers. Het is dus puur een vraag om zelf van te leren zodat we zelf de juiste beslissingen kunnen maken.

We kunnen wel gewoon zeggen, "Oh er zit een Intel i7 processor in met 16GB DDR3 1333" maar misschien heeft dit wel weinig tot niks te betekenen omdat een server meer aan RAM en Lees / schrijf snelheid heeft zeg maar.

Puur om te leren en informatief dus zodat we begrijpen hoe, wat en waar. Heb inmiddels wat boeken besteld om te leren hoe het gehele hosting gebeuren werkt (netwerk beheer met Linux, clusters, database, caching en dergelijke).


@Gomez12

Dat is ook het probleem, er word ons nu niet duidelijk verteld hoe en waardoor het steets gebeurd. Dus wij weten (als leken) ook niet echt goed hoe dit nu te testen en -of te bekijken. Zeker ook niet gezien onze geringen kennis van servers en het onderhoud daarvan

We zouden dus toegang nodig hebben tot de server zelf om dingen te meten en de "bottleneck" te kunnen vinden dus?

Server Not Found / Forbidden

is wat de HTTP Code terug geeft (heb een cron gemaakt die met regelmaat checkt, en de status terug mailt naar ons). Lijkt mij dat de server dan plat ligt haha.

Ik zal eens vragen want je hebt volledig gelijk met "meten is weten"!

[Slechdt]

Lijkt me dat downtime dan toch wel prijzig is. Iemand aannemen die al deze kennis al heeft? Dan hoef je zelf niet te prutsen en loop je ook niet het risico dat je straks met verkeerde partijen/hardware/software zit.

[begintmeta]

Dat zou me dan inderdaad ook een goed idee lijken.

Als je geen toegang hebt tot de servers (en software?) waar de shops nu op draaien wordt het natuurlijk lastig, dan moet je toch echt zorgen dat die 'hostende vriend' bereid is wat meer moeite te doen, of die op de een of andere manier daartoe aanzetten. Als je wel toegang tot de software hebt kan je vermoedelijke problemen daarin natuurlijk wel zelf (laten) bekijken.

[ Voor 87% gewijzigd door begintmeta op 14-12-2015 09:55 ]

[emnich]

Als je er al weinig verstand van hebt, zou ik zeker niet zelf het beheer gaan doen.

Verder zal je toch echt moeten weten wat je bottleneck is om er iets over te kunnen zeggen. Daarbij kan je ook eens kijken naar wanneer de server precies down gaat, is dat op piek momenten of is dat terwijl je cronjobs uitvoert of...

[Helixon]

angelovancleef schreef op maandag 14 december 2015 @ 09:45:
Hi, dank voor je reactie Miepermans

We doen eigenlijk alles intern we zijn alleen niet blij met het bedrijf dat de hosting verzorgd (een vriend... ja, daar heb je het al hahaha) en willen eigenlijk gewoon zelf nieuwe servers aanschaffen en het bij een "echt bedrijf" onderbrengen.

We weten zelf niet goed wat te doen, hebben wel gekeken naar bedrijven als pcextreme.nl en dergelijke en naar een rack, maar je hebt al een rack voor 300 euro, maar je hebt ze ook voor 5000 euro per rack.

Gezien wij zelf niet heel veel van servers af weten, hadden we iets van, we vragen het op Tweakers want de mensen hier hebben geruime kennis en ervaring van en met servers. Het is dus puur een vraag om zelf van te leren zodat we zelf de juiste beslissingen kunnen maken.

*snip*

Hoi Angelo,

Als ik je een goed advies mag geven, dan zou ik kijken voor een professioneel opgezet bedrijf. Niet om reclame te maken, maar mij bevalt het zelf heel goed bij TransIP. Daar krijg je webhosting pakketten, voor een eerlijke prijs.

En mocht je het toch in eigen beheer willen houde, dan kun je ook een VPS aanschaffen/huren.

Verder wil ik je mee geven dat het installeren en configureren van de hosting servers het werk niet is, maar je moet deze servers ook zelf kunnen beheren en onderhouden. Wanneer je er helemaal alleen voor staat wordt de doorlooptijd bij downtime alleen maar groter. Dat is natuurlijk niet wenselijk.

Oh ja, en als laatste "Krijg geen spijt, backup optijd! "

Greetzz

[ Voor 25% gewijzigd door Helixon op 14-12-2015 09:57 ]

[DukeBox]

Gebruik je een standaard platform/cms ?

[Verwijderd]

Niet meteen upgraden. Goede optimalisatie kan wonderen doen. Ik zou, natuurlijk wel afhankelijk van de inhoud van de site, zo'n site met 150.000 bezoekers misschien wel makkelijk op een 5 euro p/m VPS kunnen zetten (voorbeeldje!).
Is alles goed geminified? CSS JS HTML?
Gebruik je caching? Algemeen, of in je site?
Varnish interessant?
Opcache aan?
PHP-FPM? FCGID? Goed ingesteld?
Nginx, lekker snel? Of goed ingestelde Apache?
PHP7 is een stuk sneller dan 5.x. Wellicht een optie.
Onnodige code/plugins verwijderd?
CDN?
Slechte bots (die capaciteit wegsnoepen) blocken met CSF/mod-security/cloudflare?

Dat waren een paar dingen waar je naar kan kijken.

[semyazaruax]

Dank voor jullie antwoorden, goede informatie (en eerlijk)!

Wij gebruiken een zelf ontwikkeld platform/CMS. Het is niet het beste wat er is maar het functioneerd en ze zijn niet bereid over te stappen naar iets anders. Dit is echter voor de back-end

De front-end is ook volledig zelf ontwikkeld en werkt wel goed en na behoren. Tests (bijvoorbeeld via Google insight) zijn allemaal na genoeg perfect, dus het zit hem echt in de hosting / server en niet in de website(s) zelf.

Ik ga een proberen om toegang te krijgen en te onderzoeken wat de bottleneck is. Ik zal hier reageren ter informatie wanneer ik dit gevonden heb

[_Apache_]

Waarom niet in AWS/ Azure? Je kunt je eigen architectuur kiezen, je kunt de machines online trekken in de geo-locatie die voor je gebruikerst meest gunstig is. Als je hardware ondermaats is klik je er gewoon extra resources bij.

Klik eens rond in de azure calculator bijv om en indicatie van de kosten te krijgen.

We hebben hier zelfs een klant draaien met diverse proxies over de continenten om content snel te serveren en een enkele root server voor het verspreiden van de content. Zo kan je je eigen architectuur compleet zelf opzetten. Ideaal

[ Voor 12% gewijzigd door _Apache_ op 14-12-2015 10:10 ]

[semyazaruax]

Kreeg net te horen dat de server van "italie" was blijven hangen waardoor alles dus niet doorstroomde... geen idee of dit jullie iets zegt? (het is een cluster, dus dat mag dan toch niet?). De database sync ligt er dan uit en dan moet een van de "slaves" gereboot worden.

Verder vertelde hij dat het in de meeste gevallen is dat MYSQL het moeilijk heeft en dat daardoor de hele data-flow niet lekker loopt en alles op hol gaat en er één of meerdere dingen ge-restart moeten worden.

In mijn ogen, snellere hardware = betere data-flow (snellere input -en output / verwerking) en opgelost, maar dat zal wel niet zo handig zijn natuurlijk hahaha.

Die Azure calculator is ideaal! we gaan eens goed verdiepen hier in dankjewel!

[mcDavid]

angelovancleef schreef op maandag 14 december 2015 @ 10:03:
Dank voor jullie antwoorden, goede informatie (en eerlijk)!

Wij gebruiken een zelf ontwikkeld platform/CMS. Het is niet het beste wat er is maar het functioneerd en ze zijn niet bereid over te stappen naar iets anders. Dit is echter voor de back-end

De front-end is ook volledig zelf ontwikkeld en werkt wel goed en na behoren. Tests (bijvoorbeeld via Google insight) zijn allemaal na genoeg perfect, dus het zit hem echt in de hosting / server en niet in de website(s) zelf.

Ik ga een proberen om toegang te krijgen en te onderzoeken wat de bottleneck is. Ik zal hier reageren ter informatie wanneer ik dit gevonden heb

De front-end is niet interessant qua server belasting. De back-end des te meer. Als die slecht in elkaar steekt kan het best eens zijn dat je met het herontwerpen van een paar queries of anders inrichten van je tabellen een stuk meer kunt winnen dan met hardware er tegenaan smijten.
Het lijkt me ook niet zozeer de taak van een hosting provider om uit te zoeken waarom jullie zelf-ontwikkelde software traag is. Als die inhouse ontwikkeld is lijkt me dat jullie ook zelf de capaciteit (zouden moeten) hebben om daar wat logging in te bouwen.

Kort samengevat: denk toch dat jullie eerder een softwareproblemen dan een hosting probleem hebben.

[emnich]

Het is al eerder gezegd, hardware is pas het laatste waar je naar moet kijken (of je moet geld genoeg en kennis te weinig hebben).

Misschien gaat MySQL wel onderuit omdat je langzame queries hebt die met een index te verhelpen zijn. Dan kan je 10 extra servers inzetten of één index toevoegen met hetzelfde resultaat.

Zolang je de oorzaak niet weet, kan je het probleem niet oplossen. Je bent nu alleen bezig met de symptomen....

[_Apache_]

Heeft MySQL niet zoiets als een execution plan, dat je kan zien waardoor hij zo langzaam is en welke keuzes hij maakt voor het uitvoeren van z'n query?

Dat gaat je vriend worden

[Icey]

Het lijkt mij handig om misschien eerst intern een server neer te zetten om te kijken hoe en wat. Er zijn vervolgens ook systemen om bezoekers te simuleren. Niet altijd is hardware namelijk de bottleneck, het hoeft niet altijd de oplossing te zijn namelijk.

Het komt vaak voor dat ik queries herschrijf of simpelweg indexes toevoeg op de juiste plekken. Het kan best zijn dat je opeens van 15+ seconden naar 0,x gaat. (Simpel voorbeeld, mijn voorgangers hadden een facturatiesysteem gemaakt die draaide 1x per maand bijna een uur, doe ik nu in 15 seconden in 1 query i.p.v. tientallen foreaches).

Misschien zit er één automatische taak in de weg... ik heb wel eens meegemaakt dat een rapport gegenereerd werd die er langer dan 1 minuut over deed, na 1 minuut draaide de taak opnieuw, zag dat het rapport nog gegenereerd moest worden en begon opnieuw. Die draaide dus 24/7 door.

[ Voor 11% gewijzigd door Icey op 14-12-2015 10:24 ]

[Tjolk]

_Apache_ schreef op maandag 14 december 2015 @ 10:17:
Heeft MySQL niet zoiets als een execution plan, dat je kan zien waardoor hij zo langzaam is en welke keuzes hij maakt voor het uitvoeren van z'n query?

Dat gaat je vriend worden

Dit inderdaad.

Ik heb het grootste deel van 2014 besteed aan het herschrijven van de backend van onze in-house ontwikkelde backend (incl. SOAP server en aangekoppeld WMS/CMS). Hele database omgezet naar nieuwe, efficiëntere tabelindeling, goede indexen, handigere query's, etc. Hoe vaak ik niet EXPLAIN ... heb gebruikt... Maar het heeft me heel veel inzicht en winst opgeleverd. Dusdanig veel zelfs dat de hostingpartij * mij vroeg of het wel klopte dat de databaseserver zo weinig te doen had in vergelijking met eerdere jaren.

Wat ook heel veel kan schelen is bijvoorbeeld upgraden van MySQL 5.1 naar 5.5 en inderdaad upgraden van PHP 5.x naar PHP. Beide performen echt een stuk beter en dan hoef je dus niet meteen met "ijzer" te smijten. Wel eerst even controleren en testen natuurlijk of je geen issues krijgt met die nieuwe versies.

Je zegt ook dat het niet aan de front-end kan liggen, want Google zegt dat het goed is. Reken daar niet per se op.
Klinkt misschien lomp, maar vorig jaar hadden we tijdens de kerstdrukte enorme performance problemen. Was lang zoeken, maar bleek uiteindelijk door 2 knelpunten in de front-end te komen. Dat waren problemen die pas optraden als er zo'n 250-300 users tegelijk aan het rondkijken waren op de shops. Sluit dus niets uit voordat je het grondig getest hebt.

*) Signet in ons geval

[Powermage]

Net als ongeveer alle andere reacties, meten is weten en is ook echt nodig.
Voorbeeldje bij een klant van ons, trage applicatie, kwam vanuit de DB server.

Ooit had een DBA geroepen dat het aan de disk IO lag, nu zaten er veel disken in die DB server (in een externe enclosure) dus een setje SSD's erin scheelde die enclosure (hosting en stroom) dus de ROI zat wel snor, maar in de performance scheelde het niets, wat blijkt, de grote processen die uren lopen op de achtergrond waren allemaal single threaded opgebouwd en de disk-io was nooit een probleem... daar zit je dan met je 12 fysieke core's DB server, die die hele periode gewoon geen fuck uitvoert want single thread proces... de grootste stappen wat meer paralel laten uitvoeren gaf een snelheidswinst van een paar honderd procent (en dit bleek achteraf nog geen 2 dagen werk)

Het kan best zijn dat de hardware op het moment niet eens zo veel uitvoert maar de query's en opbouw van de website/database/indexes etc gewoon onder de maat is.

Je zou een tool als Solarwinds DPA als demo kunnen downloaden en naar de DB server connecten (je kan hem desnoods hosten op je lokale werkstation) die laat je een paar dagen lopen en misschien haal je daar zo wat gekkigheid uit.

[_Apache_]

Powermage schreef op maandag 14 december 2015 @ 11:49:
Ooit had een DBA geroepen dat het aan de disk IO lag,

offtopic:
Ik mag hopen dat de betreffende hardware en DBA de deur gewezen zijn?

[Powermage]

Die hele toko was al lange tijd exit maar iedereen (wijzelf ook hoor) maakte de fout daarin te geloven (verder moet ik zeggen was het een goede vent hoor, wel veel waardevolle dingen ingebracht)
daarnaast zoals vermeld, de roi (voor de acc omgeving) was in iedergeval dermate kort dat het sowieso geen kwaad kon, maargoed.

[gekkie]

Ook niet uitgesloten dat als je eerst je DB probleem had opgelost, je als nog tegen de disk I/O als volgende bottleneck was aangelopen .

Maar het loont wel om eerst te kijken of er quick wins zijn in je queries, indexen en database configuratie (opties tunen wil ook nog wel eens wat schelen, out of the box gaan de configuraties vaak uit van vrij beperkt geheugen .. I/O costs op basis van harddisks ipv SSD etc).

Daarna loont het vaak wel om eerst de hardware te upgraden, op basis van de nieuwe inzichten en vervolgens kun je nog bezig gaan met meer microoptimalisaties.

[Gomez12]

gekkie schreef op maandag 14 december 2015 @ 12:48:
Ook niet uitgesloten dat als je eerst je DB probleem had opgelost, je als nog tegen de disk I/O als volgende bottleneck was aangelopen .

Maar het loont wel om eerst te kijken of er quick wins zijn in je queries, indexen en database configuratie (opties tunen wil ook nog wel eens wat schelen, out of the box gaan de configuraties vaak uit van vrij beperkt geheugen .. I/O costs op basis van harddisks ipv SSD etc).

Daarna loont het vaak wel om eerst de hardware te upgraden, op basis van de nieuwe inzichten en vervolgens kun je nog bezig gaan met meer microoptimalisaties.

Niet gaan beginnen met je query's, dat zijn grote en ingrijpende wijzigingen die veelal onbedoelde bijeffecten kunnen hebben en die je eerst moet testen etc.

Ik zou altijd (in nood) beginnen met hardware ertegenaan smijten, reken maar gewoon eens uit wat een week aan software-optimalisaties kost en hoeveel hardware je er voor hetzelfde geld tegenaan kan gooien en hardware kan je in principe gewoon over een uur hebben draaien.

Alleen moet je wel eerst weten waar je hardware bottleneck zit, die moet je doormeten en als je dan ziet dat je cpu het te druk heeft dan bestel je een betere cpu, is je ram vol dan bestel je meer ram, is je hdd /ssd te traag bestel die dan bij etc.
Dat kost je over het algemeen max een paar honderd euro (op jaarbasis) per server en dan heb je lucht gewonnen.

Daarna kan je als je lucht hebt gaan kijken naar je query's etc

[elhopo]

semyazaruax schreef op maandag 14 december 2015 @ 10:11:
Kreeg net te horen dat de server van "italie" was blijven hangen waardoor alles dus niet doorstroomde... geen idee of dit jullie iets zegt? (het is een cluster, dus dat mag dan toch niet?). De database sync ligt er dan uit en dan moet een van de "slaves" gereboot worden.

Dat is maar net hoe de hele applicatie is opgebouwd. Ik heb wel eens meegemaakt dat er synchrone logging plaatsvond en op het moment dat de database volzat hing alles. Merk je in test niets van...
Wellicht is de boel meer uit te splitsen, dus iedere land een aparte set van server, database. Als er dan 1 hangt heeft de rest er geen last van.

Oh, en of een cluster daar geen last van heeft is compleet afhankelijk van hoe de boel is opgezet. Als de master hangt zou de slave het moeten overnemen, maar dat kan je in een testomgeving vrij makkelijk simuleren lijkt me. Het kan zomaar zijn dat de software naar een IP verwijst en niet naar een cluster. Nogmaals, compleet afhankelijk van hoe de boel is opgezet, welke database enz...

Verder vertelde hij dat het in de meeste gevallen is dat MYSQL het moeilijk heeft en dat daardoor de hele data-flow niet lekker loopt en alles op hol gaat en er één of meerdere dingen ge-restart moeten worden.

In mijn ogen, snellere hardware = betere data-flow (snellere input -en output / verwerking) en opgelost, maar dat zal wel niet zo handig zijn natuurlijk hahaha.

Zoals de anderen al zeggen: Waardoor heeft 'ie het zwaar? IO's? Processor? Te weinig geheugen? Waarschijnlijk is de software aanpassen beter. Doe eens wat testjes met LoadUI bijvoorbeeld...

oh ja, zet niet overal 'haha' achter, komt een beetje dom over, als een Facebook post ofzo...

[Jazzy]

semyazaruax schreef op maandag 14 december 2015 @ 10:11:
Kreeg net te horen dat de server van "italie" was blijven hangen waardoor alles dus niet doorstroomde... geen idee of dit jullie iets zegt? (het is een cluster, dus dat mag dan toch niet?). De database sync ligt er dan uit en dan moet een van de "slaves" gereboot worden.

Verder vertelde hij dat het in de meeste gevallen is dat MYSQL het moeilijk heeft en dat daardoor de hele data-flow niet lekker loopt en alles op hol gaat en er één of meerdere dingen ge-restart moeten worden.

In mijn ogen, snellere hardware = betere data-flow (snellere input -en output / verwerking) en opgelost, maar dat zal wel niet zo handig zijn natuurlijk hahaha.

Ik denk dat hier het issue zit. Je bent zelf niet technisch genoeg om het verhaal van de hoster goed te interpreteren, gebruikt maar wat niets zeggende termen (hangen, doorstromen, data-flow, verwerking) en kunt dus totaal niet inschatten wat de beste oplossing is. Zorg eerst dat je *begrijpt* wat het probleem is, laat je dan door een kundig persoon adviseren over de oplossing.

[T0ny]

Ik denk dat een cloud dienst zoals bv Azure of AWS voor jullie een goede optie is aangezien je dan een deel van de complexiteit niet zelf hoeft op te bouwen en beheren.
Als ik jullie was zou ik een bedrijf/adviseur inhuren die ervaring heeft met het technisch inrichten van dit soort omgevingen (web/infra specialist), op korte termijn ben je dan wat geld kwijt maar op lange termijn zul je daar zeker plezier van hebben.

[Jazzy]

Op zowel korte als lange termijn ben je veel geld kwijt want Azure is behoorlijk duur, AWS idem dito. Verder neemt het de complexiteit maar voor een deel weg, een slecht ingerichte en beheerde applicatie gaat ook op een cloudomgeving slecht draaien. En het introduceert natuurlijk ook weer nieuwe complexiteit, ook verlies je controle en flexibiliteit omdat je een groot deel van het beheer uit handen geeft.

[Tjolk]

Jazzy schreef op maandag 14 december 2015 @ 13:38:
Op zowel korte als lange termijn ben je veel geld kwijt want Azure is behoorlijk duur, AWS idem dito. Verder neemt het de complexiteit maar voor een deel weg, een slecht ingerichte en beheerde applicatie gaat ook op een cloudomgeving slecht draaien. En het introduceert natuurlijk ook weer nieuwe complexiteit, ook verlies je controle en flexibiliteit omdat je een groot deel van het beheer uit handen geeft.

QFT

[gekkie]

Gomez12 schreef op maandag 14 december 2015 @ 13:16:
[...]

Niet gaan beginnen met je query's, dat zijn grote en ingrijpende wijzigingen die veelal onbedoelde bijeffecten kunnen hebben en die je eerst moet testen etc.

Als er zeg een stuk of 5 echte slow queries zijn en een explain uitwijst dat bijvb indexen niet gebruikt worden maar door de queries anders op te zetten deze wel gebruikt kunnen worden lijkt me dit een vrij "laaghangend fruit" optimalisatie.
Bovendien leer je daar gelijk je bottlenecks beter door kennen en kunnen je bottleneck's ook verschuiven door vrij basic optimalisaties, deze zou ik dus altijd doorvoeren alvorens er meer hardware tegen aan te smijten. Micro-optimalisaties zou ik inderdaad (als je ze al doet) na de hardware doen.

Net alsof een wijziging van hardware (en daarmee vaak ook DB configuratie .. anders wordt je rekenbeest nog niet effectief gebruikt) en hoster niet zou hoeven te testen .

Wat ik niet echt snap is hoe de ontwikkelaars bij TS kunnen ontwikkelen zonder enige kennis van (DB-)hosting. Je host toch minimaal je eigen test omgeving lijkt me ? En krijgt als ontwikkelaar dan toch vanzelf wel een beetje gevoel voor wat je SQL server doet ?

[ Voor 11% gewijzigd door gekkie op 14-12-2015 13:59 ]

[Gomez12]

T0ny schreef op maandag 14 december 2015 @ 13:31:
Ik denk dat een cloud dienst zoals bv Azure of AWS voor jullie een goede optie is aangezien je dan een deel van de complexiteit niet zelf hoeft op te bouwen en beheren.

Imho is "the cloud" bijna altijd de slechtste optie, het is leuk om klappen op te vangen maar als je gewoon weet dat je nu gemiddeld 150.000 bezoekers hebt en niet verwacht dat je volgende week gemiddeld 1.5 miljoen bezoekers hebt (of 150 om ook maar even de andere kant uit te gaan) dan kan je gewoon een basis aan (virtuele) hardware neerzetten die bijv 200.000 bezoekers kan opvangen en dan ben je veel goedkoper uit dan "in the cloud".

En qua complexiteit / beheersbaarheid ben je imho veel slechter uit met de cloud (of je moet echt een heel duur prijsplaatje betalen qua mirroring etc) want ook "the cloud" moet wel eens herstart worden voor updateheaven etc. En met MS/Amazon valt daar heel erg slecht over te praten op welke tijdstippen dat gaat gebeuren.

Plus dat je in basis heel erg weinig aan complexiteit inlevert als je niet eerst grof gaat investeren in ontwikkeling. Als er nu op een MySQL database gewerkt wordt, dan biedt MS daar afaik geen direct alternatief voor oftewel je kan een VM inrichten met daarop MySQL maar dan houd je dezelfde complexiteit, je kan het gaan ombouwen naar SQL Azure (of hoe dat dan ook heet) maar dat betekent weer je hele applicatie/DBA aanpassen.

gekkie schreef op maandag 14 december 2015 @ 13:51:
[...]
Als er zeg een stuk of 5 echte slow queries zijn en een explain uitwijst dat bijvb indexen niet gebruikt worden maar door de queries anders op te zetten deze wel gebruikt kunnen worden lijkt me dit een vrij "laaghangend fruit" optimalisatie.

Als je de infrastructuur nu hebt staan die die 5 query's aanwijst dan gelijk doen, als je die infrastructuur die ze kan aanwijzen in 1 week opgetuigd hebt wederom gelijk doen.
Echter wat ik van TS begrijp hebben ze die infrastructuur nu niet, hebben ze de kennis niet om die op te tuigen en hebben ze daarnaast ook de toegang niet waardoor ze niemand kunnen inhuren die de infrastructuur opzet.

Dan vermoed ik dat het over het algemeen maanden werk gaat worden om dat op te tuigen en dan hoeft er nog niet eens iets uit te komen (ik heb genoeg situaties gezien waar iedereen op zoek was naar slow query's terwijl alle query's onder de 10 ms bleven, alleen zaten er for-each loopjes in die gewoon de hele machine downbrachten door voor 1 pagina 1 miljoen requests te doen)

Performance is over het algemeen een samenspel van hardware, code en database / query's. En het 1e is makkelijk te meten, goedkoop door te voeren voor een quick-fix, terwijl 2 en 3 vrij onbekend zijn qua prijs en doorlooptijd maar met een normaal uurtarief al snel gaan optellen.

[gekkie]

Gomez12 schreef op maandag 14 december 2015 @ 13:59:
[...]
Als je de infrastructuur nu hebt staan die die 5 query's aanwijst dan gelijk doen, als je die infrastructuur die ze kan aanwijzen in 1 week opgetuigd hebt wederom gelijk doen.
Echter wat ik van TS begrijp hebben ze die infrastructuur nu niet, hebben ze de kennis niet om die op te tuigen en hebben ze daarnaast ook de toegang niet waardoor ze niemand kunnen inhuren die de infrastructuur opzet.

Dan vermoed ik dat het over het algemeen maanden werk gaat worden om dat op te tuigen en dan hoeft er nog niet eens iets uit te komen (ik heb genoeg situaties gezien waar iedereen op zoek was naar slow query's terwijl alle query's onder de 10 ms bleven, alleen zaten er for-each loopjes in die gewoon de hele machine downbrachten door voor 1 pagina 1 miljoen requests te doen)

Mjah ook dat zie je in je SQL / applicatie logs vrij snel terug als het goed is, maar goed lijkt er inderdaad op dat ze er EN niet bijkunnen .. EN als ze het al zouden kunnen het niet zouden kunnen interpreteren (hosting incl. webserver + db == een grote blackbox .. enige performance die gemeten wordt is via de frontend in de categorieën "het doet het", "gut wat duurt het lang" en "500".

Performance is over het algemeen altijd een samenspel van hardware, code en database / query's. En het 1e is makkelijk te meten, goedkoop door te voeren voor een quick-fix, terwijl 2 en 3 vrij onbekend zijn qua prijs en doorlooptijd maar met een normaal uurtarief al snel gaan optellen.

FTFY en afhankelijk van hoe beroerd de code is ben ik het wel of niet met je eens:
Als het die 1 miljoen requests zijn .. of queries die om de een of andere reden geen gebruik maken van indexen, of veel te veel onnodige gegevens joinen etc. Dan kun je er vrij veel hardware tegen aan gooien die nog niet de performance weet te evenaren van die quick fixes in je code, kortom ik zou dat toch eerst onderzoeken. Maarja wie ben ik ..

[FreqAmsterdam]

Even tussendoor, zonder inhoudelijk te reageren. Wat een verdomd slechte bedrijfsvoering heb je als je een dergelijke vraag op een publiek forum stelt. Zeker gezien het om bijzonder veel traffic (en dus geld) gaat.

Dit lijkt me geen technisch probleem, maar een commercieel probleem. Je zult gewoon geld moeten uitgeven, zij het soft- dan wel hardware. Daarnaast zul je de teugels uit handen moeten geven. Je gaf zelf al aan er niet veel verstand van te hebben, maar een paar posts terug lees ik dat je dingen gaat onderzoeken.

Dus stel jezelf de vraag: wil ik het zelf gaan doen (want daar lijkt het op), of ga ik het uitbesteden. Als je het uit gaat besteden dan kun je gewoon een opdrachtomschrijving maken, en deze naar diverse partijen sturen. Je kunt dan zelf de partij met de beste oplossing kiezen.


Knip, doe eens niet zo denigrerend..

[ Voor 20% gewijzigd door Equator op 22-12-2015 10:36 ]

[DukeBox]

FreqAmsterdam schreef op maandag 21 december 2015 @ 17:15:
[knip]

nofi, maar veel van de duur betaalde consultants e.d. komen ook gewoon hier op t.net.

[ Voor 20% gewijzigd door Equator op 22-12-2015 10:36 ]

[KoeKk]

Wat een intens trieste reactie Freq. Over het algemeen zal je in PNS goed onderbouwde reacties vinden die een behoorlijk onafhankelijk advies geven. Lijkt mij dat elke goede werkgever dit zal begrijpen en de waarde hiervan kan inschatten.

De vraag is ook niet of er geld uitgegeven moet worden, maar waaraan. En als de TS geen enorme technische kennis heeft dan is het toch ook prima om ergens anders deze kennis op te zoeken? Verder zal je van heel veel bedrijven een advies krijgen wat op hun eigen mogelijkheden gebaseerd is (Van een hoster zal je een oplossing krijgen in de richting van wat zij kunnen leveren, ongeacht of dit de beste oplossing voor het probleem is).

[Jazzy]

KoeKk schreef op dinsdag 22 december 2015 @ 10:20:
Wat een intens trieste reactie Freq. Over het algemeen zal je in PNS goed onderbouwde reacties vinden die een behoorlijk onafhankelijk advies geven.

Over het algemeen zul je in PNS ook veel beter omschreven vragen vinden, denk dat de TS zich gelukkig mag prijzen dat het topic niet gesloten is en er een aantal waardevolle adviezen gegeven zijn. Feit is dat de TS geen verstand van zaken heeft en wel om technisch advies komt vragen, dat is inderdaad een waardeloze aanpak en dat mag van mij best gezegd worden. Zachte heelmeesters maken stinkende wonden.

[Equator]

Goed, mede door het feit dat de TS zich al ruim een week niet heeft laten zien, en het feit dat dit topic conform de regels niet geheel in Professional Networking & Servers behoort sluit ik het topic om te voorkomen dat dit nog verder offtopic gaat.

De opmerkingen omtrent het al dan niet stellen van een vraag op Tweakers vind ik een beetje vreemd. Het forum is er juist voor het stellen van vragen, en PNS is er voor de geavanceerdere problemen. Dat iemand het niet zo goed voor elkaar lijkt te hebben als dat anderen dat hebben moet geen reden zijn om je "gegeneerd te voelen" voor het gebruiken van GoT om je vragen te stellen.