Slashdot Mirror

Globalscale have a similar product out there that's not so great (not my site BTW). I wonder if they've addressed the overheating issues and poor h/w quality (just look at those solder joints) this time round.

I work with some very high traffic sites, storing large data sets (100GB+).

  Depending on the application (if it allows for different write-only/read-only database configurations) we'll have a master-master replication setup, then a number of slaves hanging off each MySQL master. In front of all of this is haproxy* which performs TCP load balancing between all slaves, and all masters. Slaves that fall behind the master are automatically removed from the pool to ensure that clients receive current data.

  This provides:
  * Redundancy
  * Scaling
  * Automatic failover

  The whole NoSQL movement is as bad as the XML movement. I'm sure it's a great idea in some cases, but otherwise it's a solution looking for a problem.

(*) http://haproxy.1wt.eu/

• HAproxy
• Distributor
• Crossroads
• Pen
• Balance/BalanceNG
• Pound

HAproxy (which is the one I use) has the ability to define "backup" servers which can be used in the event of a complete failure of all servers in the pool, even if there is only one server in the main pool. If you're trying to do this on the cheap, that may help. It also has embedded builds for things like the NSLU2, so it may be easy to run on an embedded device you already have.

Haproxy is better than Pound, IMO. It's lightweight, but handles immense load just as well as layer 3 load balancing (LVS), with the advantages of layer 5 proxying. It uses the latest Linux APIs (epoll, vmsplice) to reduce context switching and copying to a minimum. It has a nice, concise stats module. Its logs are terse yet complete. It redirects traffic to a working server if one is down / overloaded.

Hi,

an article I wrote last year about application scaling using load balancing may help you. It will not solve your problems but will certainly help you with the concepts, best practises and traps to avoid, which is a good starting point.

You can get read it online here : http://1wt.eu/articles/2006_lb/ or you can download it as a PDF here :
http://www.exceliance.fr/en/ART-2006-making%20appl ications%20scalable%20with%20LB.pdf

Also, what you need is to perform benchmarks frequent during all the cycle of development of your applications. Using
traffic generators, you will simulate a lot of users and see how your application/database behaves. And believe me, it
never breaks where you expected it to ! On the first run, it's almost always caused my too much memory usage.
Then you optimize it (decrappify it in fact), then you break on concurrency (threads, processes, file descriptors,
sockets, ...), then you optimize it again and break on I/O in the database. Then you have to rewrite all your requests,
and when you finally saturate the frontend servers with 1% of your target load, you realize that you have to rewrite
everything using a faster language. But at least, you will be able to save time by starting on a few cheap servers, for
the time needed to translate the code for version 2.

You talked about 60000 users. If it's a population of 60000 users, it's not much. If it's 60000 concurrent users, it's
a huge load and you will have to educate yourself in network and operating system tuning, because tuning the app alone
will not be enough.

Good luck!
Willy