A neat approach with many benefits. Two things to mention:
this is a concern when the common replication technique starts being a PITA (with GTID, promoting a new master in MySQL shouldn’t be a problem). So this is not what you should rush for for your 2-slave setup
this approach applies to pretty much any replication task – not necessarily MySQL, not even necessarily DB replication at all
You can have this benchmark run forever, or you can specify a specific period of time. To set the duration of the test, use the -t NUMm option. The NUMm format is a representation of time. Here are some time format examples:
-t60S (60 seconds)
-t1H (1 hour)
-t120M (120 minutes)
To demonstrate running a benchmark, let’s run Siege against this blog:
siege -b -t60S http://blog.remarkablelabs.com
and then also “user emulation”:
When creating a load test, you should set the -dand -c NUM options. The -d NUM option sets a random interval between 0 and NUM that each “user” will sleep for between requests. While the -c NUM option sets the concurrent number of simulated users.
Here is an example of a load test of a Heroku application:
and you could use custom headers (think cookies) with -H.
And what’s even better, it’s widely available – I’ve installed it on Mac through Ports (although it’s on brew as well) and then unpacked it from RPM on my GoDaddy SSH shell account (because I couldn’t just go and install it there). It worked well in both cases.
This was hanging around in my Keep for quite a while – right till I realized that I need it somewhere for a quick reference, although it just messes my Keep flow. Thus posting it here in a “JFTR” fashion.
Data access latencies:
L1 cache reference ……………………. 0.5 ns
Branch mispredict ………………………. 5 ns
L2 cache reference ……………………… 7 ns
Mutex lock/unlock ……………………… 25 ns
Main memory reference …………………. 100 ns
Compress 1K bytes with Zippy …………. 3,000 ns = 3 µs
SSD random read …………………… 150,000 ns = 150 µs
Read 1 MB sequentially from memory ….. 250,000 ns = 250 µs
Round trip within same datacenter …… 500,000 ns = 0.5 ms
Read 1 MB sequentially from SSD ….. 1,000,000 ns = 1 ms
Send 1MB over 1 Gbps network ……. 10,000,000 ns = 10 ms
Disk seek ……………………… 10,000,000 ns = 10 ms
Read 1 MB sequentially from disk …. 20,000,000 ns = 20 ms
Send packet CA->Netherlands->CA …. 150,000,000 ns = 150 ms
MySQL Storage Requirement per Data Type:
TINYINT – 1 byte (BOOL is an alias for this)
SMALLINT – 2 bytes
MEDIUMINT – 3 bytes
INT, INTEGER – 4 bytes
BIGINT – 8 bytes
FLOAT(p) – 4 bytes if 0 <= p <= 24, 8 bytes if 25 <= p <= 53
FLOAT – 4 bytes
DOUBLE [PRECISION], REAL – 8 bytes
DECIMAL(M,D), NUMERIC(M,D) – Varies
BIT(M) – approximately (M+7)/8 bytes
This is a “you learn better when you write it down” sort of post. Never actually got into DNS record types – as a lot of things I’ve missed, there was just no need and I wasn’t curious enough. Although curiosity without regular application of that knowledge is rather pointless – “you soon will forget the tune that you play”, if you play it just once or twice.
That said, I’m gonna be needing this knowledge soon (I presume), so I thought I better do me a hint page (a “crib sheet”, as the dictionary suggests).
A record – “Address”, a connection of a name to an IP address like, for instance, “example.com. IN A 126.96.36.199” – where IN is for the Internet, i.e. “Internet Address…” Wildcards could be used for “all subdomains”
AAAA – “four times the size”, A-address for IPV6 addresses (see a note on IPV6 below)
CNAME – Canonical Name, specifies an alias for existing A record, like “subdomain.example.com CNAME example.com“. Useful to make sure you only have one IP address in A record, and others rely on A name – so if IP changes, it’s one place you have to change it at. Note: do not use CNAME aliases in MX records.
MX – Mail eXchange, specifies which server serves zone’s mail exchange purposes – like, for instance, “mydomain.com IN MX 0 mydomain.com.“; final dot is important, 0 is for priority: ther could be multiple MX records for the zone, and they processed in priority order (the lower the number the higher the priority). Same-priority records are processes in random order. Right-side name should be an A record.
PTR – specify pointer for a reverse DNS lookup, required to validate hostname identity in some cases – “188.8.131.52.in-addr.arpa. IN PTR name.net” (note that IP of name.net is 184.108.40.206)
NS – Name Server, specifies a (list of) authoritative DNS server for the domain, for instance: “example.com. IN NS ns1.live.secure.com“. This should be specified at authoritative server as well.
SOA – State Of Authority, an important record with zone’s name server details – “authoritative information about an Internet domain, the email of the domain administrator, the domain serial number, and several timers relating to refreshing the zone“. Example: mydomain.com. 14400 IN SOA ns.mynameserver.com. root.ns.mynameserver.com. ( 2004123001 ; Serial number 86000 ; Refresh rate in seconds 7200 ; Update Retry in seconds 3600000 ; Expiry in seconds 600 ; minimum in seconds )
SRV – an option to specify a server for a Service, like “_http._tcp.example.com. IN SRV 0 5 80 www.example.com.” – here’s the service name (_http), priority (0), weight (5) for services with the same priority, and port (80) for the service.
NAPTR – recent and complex regexp-based name resolution I’m not keen to into.
There’s MUCH MORE of this crap, hope I won’t need to ever dig that deep