[ Date Index ]
[ Thread Index ]
[ <= Previous by date /
thread ]
[ Next by date /
thread => ]
Re: [LUG] Nginx vs. Apache
- To: "list@xxxxxxxxxxxxx" <list@xxxxxxxxxxxxx>
- Subject: Re: [LUG] Nginx vs. Apache
- From: Matt Stevenson <mrmstevenson@xxxxxxxxx>
- Date: Mon, 11 May 2015 21:48:34 +0100
- Delivered-to: dclug@xxxxxxxxxxxxxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dcglug.org.uk; s=1428397562; h=Sender:Content-Type:List-Subscribe:List-Help:List-Post:List-Unsubscribe:List-Id:Reply-To:Subject:To:From:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=7P337f8cj4OWFx5AHcP4Wv93EqqNWkYre8InrsMh+eg=; b=IUIJOJfNPAtuDED/pTHbvZCTOgddyEUayWk9pX2To5/LuvRRWcUYX73ZUX8BFC7L3SyWUqb3CEySZQ0xR+vsdTi9sjgP9VkRgvo/hZC/stS4XO2SoIeTA+NfA5I2V371OOHZkLKU6zG4uv/sxDhSKHkcI093xJ83ic5rionci3Y=;
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=bkys4BOJc54xWKGZkRPMwyoHo0Gh5vjrTTprKAfNBbU=; b=SWpmyJhg0afT+WDk2iNV9EShF3cT0PWQqT9McjwSxdc4smeDbqLsRgomyrmgBgkSZ1 hibBuU5Dba5+OIUySyW1yEs9JFjwKpO/R6Fpk2srlAHjmbjkugOLaL6WwAju4Tpw46CZ saJXZbb9HbA7cF3AecQVbSGOG2Tk7Mp0DnFixJpMtf+mvGZfNHJEHJKP6MJfTRdi/z4b w6iil6FA0jy60bG9Hc8W7nA1ElGxxwpD+r52lTK/HMvs18zzvd8RNdGZ5agxS1xNclZq Kmf0yOCuwt/lRLhrFrdtR/+KLav9KXAbrgkjSBeYihOiGANj0tM9D6rPKT8NC6vQZ24n dcag==
Theres a thought Tom so we are back to Single servers and failover oh no my head hurts, thanks for the warning though!
On Monday, May 11, 2015, Tom <madtom1999@xxxxxxxxxxxxxx> wrote:
> On 11/05/15 21:17, Joseph Bennie wrote:
>>
>>> On 11 May 2015, at 20:53, Simon Waters <simon@xxxxxxxxxxxxxx
>>> <mailto:simon@xxxxxxxxxxxxxx>> wrote:
>>>
>>> I'm skeptical of load balancing for databases.
>>>
>>> It makes sense if the goal is robustness, although some big services
>>> use other means, like a master/slave model, or just use highly
>>> available hardware configurations, with a single simple MySQL instance.
>>>
>>> But the gain from multiple servers is low. With master/master all the
>>> transactions may be effectively being applied to both servers anyway,
>>> so the performance can go down.
>>>
>>> In contrast even modest database optimisations can reduce effort by
>>> orders of magnitude. Not done this sort of stuff so much with MySQL,
>>> but I imagine the principles are similar to other relational databases.
>>>
>>> Modern servers can handle thousands or tens of thousands transactions
>>> per second.
>>>
>>> What sort of stats do you have for the database. Table sizes, index
>>> sizes, transaction mix, cache hit rates etc. if you haven't looked at
>>> this you probably need a DBA not hardware.
>>>
>>>
>>
>> I mostly second this, My personal experience of running a pair of
>> parallel Master-slaves = never a day when it worked right! (v5.0, its
>> improved apparently), just beef up a server to be the master and have
>> slave replication for read/redundancy, if you can scale the read
>> operations then you can get some performance gains, but write should go
>> via the single master for consistencyâ and sanity.
>>
>> chances are if you really have data-io problems your looking in the
>> wrong place, front side caching is probably more optimal, There are
>> multiple strategies and you can tune at a URL + params level, something
>> like 10mins before auto expire can really take a load off.
>>
>> but guessing your hosting and not in control of that. If that's case you
>> might want to investigating throttle strategies to mange load, rather
>> than have your io max out. â if it does add more NICâs - chances are its
>> net IO causing the blocking not the internal IO.
>>
>>
>>
>>>
>>> Sent from myMail for iOS
>>>
>>>
>>> Monday, 11 May 2015 19:45 +0100 from Matt Stevenson
>>> <mrmstevenson@xxxxxxxxx <mail
--
The Mailing List for the Devon & Cornwall LUG
http://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/listfaq
