Joey

Sziasztok,

Ez itt az elso postom iphonerol.

Jo volt

q4m leforditasa

Szuksegunk van a telepitett mysql forraskodjara (amit az apt-get source mysql-server-5.1 parancsal tudsz letolteni).
Nalunk 5.1.40-es mysqlt probaltunk leforditani, viszont a Docs konyvtarral meggyult a bajunk, ezert ./configure –without-docs; make parancsal forditottuk le.

Ha nem a szabvanyos konyvtarakba vannak a libjeink, akkor a –prefix parancsal tudjuk meghatarozni. (./configure –with-mysql=/root/mysql-source/mysql-dfsg-5.1-5.1.40/ –prefix=/root/mysql-source/mysql-dfsg-5.1-5.1.40/)
Mielott megprobalnad leforditani, telepitsd fel a libmysqlclient-dev csomagot.

How the big brothers do it: WordPress

“We are using Varnish heavily for caching images. All of the images on WordPress.com and Gravatar are cached via Varnish. We have about 60 varnish servers deployed on WordPress.com and 10 on Gravatar. Each Gravatar varnish server is serving 3ish thousand requests per second. My gripe with Varnish is that whenever we upgrade, we seem to run into new performance/optimization problems which require lots of time to resolve. As a result, WordPress.com is still running an older version of Varnish. Persistent caching (across server restarts) should be introduced in Varnish 2.1 which should be cool.”

http://serverqa.wordpress.com/

“We are using nginx as a reverse proxy (load balancer) serving tens of
thousands of requests per second across various large sites
(WordPress.com, Gravatar.com, etc). We deploy our nginx reverse
proxies in active-active pairs using Wackamole and Spread to control
the floating IPs for high availability. Our busiest load balancers
(req/sec) are serving about 7000 req/sec and the most traffic per
machine is in the 600Mbit/sec range. We could push each machine more,
they aren’t maxed out, but we like to leave some room for growth, DoS
attacks, hardware/network failures, etc. The bottleneck for us seem
to be the large number of software interrupts on the network
interfaces cause the boxes to become CPU bound at some point.

(we are running Debian Lenny mostly).

We are using “cheap” commodity hardware.

2 x Quad-core AMD or Intel CPUs
2-4GB of RAM
Single SATA drive
2 x 1000Mbit NICs

Since it is so easy to deploy more servers, it’s super easy to scale,
and this configuration has been ultra-reliable for us. Most of the
failures we have had are from human error.”

http://www.ruby-forum.com/topic/195378#852220

Multi-Master Replication Manager To MySQL

Azon alkalombol szuletett ez a bejegyzes, hogy megnyitottak a blogjukat, melyben elsokent publikalt kedves Istvan baratom/kollegam Ezuton is szeretnek gratulalni hozza, es csak igy tovabb

Az MMM for MySQL project, segitseget nyujt abban, hogy a multi masteres mysql rendszeredben dinamikusan tudd kezelni az aktiv-passziv nodeokat, es a roluk replikalo slaveket. Egy jol beallitott kornyezetben, eszrevetlenul, tudsz MySQL verziot cserelni, nagy tablakat alterelni, indexeket modositani, lockolni, backupolni anelkul, hogy a felhasznaloid ebbol barmit is eszrevennenek.

http://blog.mysql-mmm.org/2009/08/some-use-cases-for-mmm-for-mysql/ postban olvashatsz, hogy milyen esetekben veheted hasznat ennek az egesznek

Redis Benchmark

5 kulonbozo DELL es 1 DB SuperMicro (Custom) serveren teszteltem. Mindegyik serveren Debian operacios rendszer volt. A gepek default configokkal futottak (ertsd ez alatt: make; ./redis-server – config parameter nelkul) A kovetkezo parancsot futtattam minden gepen: ./redis-benchmark -q -n 100000

Ami a legviccesebb volt szamomra, hogy “Boss” nevu szerver i386os tobb, mint 2 eves (2 Ghz QuadCore, 8Gb Ram, 2DB SATA (RAID1)), le volt terhelve a teszt kozben, megis a 3. legjobb volt. A Xen1-Xen2 server 3Ghz QuadCoreos 8 Gb memorias 6×130 Gb SAS (Raid5), boven alatta teljesitett – terheles nelkul.

Redis

A Redis (http://code.google.com/p/redis/) egy kulcs-ertek alapu adatbazis kezelo. Mukodeseben hasonlit a memcachere, azonban az adatok permanensen is tarolasra kerulnek, igy egy esetleges restart utan az adataink a kovetkezo indulasnak is rendelkezesre fognak allni. Tovabba, nem csak stringeket, hanem listakat es seteket is kezel.

A leirasa szerint, 110 ezer iras/s (SET), 81 ezer olvasas/s (GET) -ra kepes egy belepo szintu linux rendszeren.

Ha felkeltette a figyelmed, akkor erdemes megnezni az altaluk irt peldakodot (http://code.google.com/p/redis/wiki/TwitterAlikeExample), ami egy Twitter Clone bemutatasa mindenfele “fejlett” adatbazis kezelo nelkul. Az alapelvek egesz jok benne, viszont csak erre nem epitenek egy siteot Az authentikacios reszt feluletesnek tartom, illetve eleg meresznek tunik az, ha postolsz egy uzenetet, akkor az osszes kovetod “timeline”-jaba beleszurja ugyanazt a postot.

Jon nehany nap hetvege, igy lesz lehetosegem kiprobalni, hogy tenyleg mire kepes