necro
A unix timestamp does not have different timezones. It is a counter. No matter where u are in the world a timestamp call should give you the same numeric value at the same instant. It is not time zone adjusted. Store that number, unadjusted as the source of truth. You can get to any local time after that.
1. https://irb-cisr.gc.ca/en/statistics/Pages/Irregular-border-...
( and this is just the sw border, not accounting for flights ) 2. https://www.cbp.gov/newsroom/stats/sw-border-migration/fy-20...
1. Site and static content are served directly by your webserver. ( HTTP2/push helpful )
2. Site served by your web servers but static content is served by a CDN ( HTTP2/push NOT helpful )
3. Site and static content proxied by some service. ( HTTP2/push helpful )
For sure having multiple instances will help some of this, but adds more complexity. Do you have your app write to multiple instances, and then read low latency from one, and read high latency from another? Is that data now consistent? Do you setup Redis replication and make sure that works right and then read from different replicas? Or perhaps you engineer some queue that does not block writes, groups them together and writes to Redis in a separate thread. Then you have to maintain all this and make sure it's correct, back it up, what are the corner cases, failure modes, etc.
From my experience, if you want to engineer things well, you end up essentially building out the same sub systems that a larger db engine has. Say Innodb. I'm smart enough to know that I'm not smart enough to build a one off complex system more correctly than really smart people that have been iterating over many years and improving things on something like innodb.
There are very rare, very specific cases where I would use redis over something else if I was building something realtime, large and important.
This means that if you have part of your application that requires fast consistent GETs, and then another application does a slower SORT, UNION, DIFF, etc, on the same db or even other dbs on the same Redis server, EVERY other client request has to wait for this slower command to finish. http://redis.io/topics/latency
This is something that one really has to engineer around in order to use it in an environment that requires performance and consistent latency. In our case of 1000s req/s it was just unacceptable to have the latency be affected, sometimes by 10 times, by a slower command.
I do love all the sort, diff, union commands.
16GB ram
512GB intel ssd
1TB sata instead of cdrom
1GB AMD Radeon HD 6770M
I always got the next best mbp but since this one I thought I was always going backwards on certain things so I have not upgraded. So a 2.5 year old laptop still has these advantages that are important to me...
- non glossy display
- I have 1.5TB storage now ( and can go higher now ) compared to the max 1TB that is offered now.
- I'm still on snow leopard , primarily due to the multiple fullscreen idiocy in lion and mountain lion ( but that might change now in mavericks)
My only reason to upgrade is that I would like the fans to come on less when I'm plugged into an external 30" display. It's a little disappointing that the last 3 mbp releases are not, or making me thing twice, about hitting the buy button.
//make yourself a file dd if=/dev/zero of=1m count=1 bs=1m
//post directly to origin
time curl -F "file=@1m" -X POST "http://up4.pinkbike.com/upload/t.php" -w %{speed_upload}Bytes/s
array(3) { ["HTTP_USER_AGENT"]=> string(81) "curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8y zlib/1.2.3" ["REQUEST_METHOD"]=> string(4) "POST" ["CONTENT_LENGTH"]=> string(7) "1048770" } 230177.000Bytes/s real 0m4.560s user 0m0.004s sys 0m0.010s
//post via Cloudfront to same origin
time curl -F "file=@1m" -X POST "http://dhima35gjf4ct.cloudfront.net/upload/t.php" -w %{speed_upload}Bytes/s
array(3) { ["HTTP_USER_AGENT"]=> string(17) "Amazon CloudFront" ["REQUEST_METHOD"]=> string(4) "POST" ["CONTENT_LENGTH"]=> string(7) "1048770" } 227055.000Bytes/s real 0m4.623s user 0m0.005s sys 0m0.011s
So upload time is not much different from my location. The origin is in San Jose, and in my case I'm in Vancouver BC, and going through the Seattle cloudfront edge. Would be interesting to see what you get from other locations ( I'm occasionally getting "ERROR: The request could not be satisfied" with cloudfront post )
I'm curious if the edge receives the full POST/PUT first and then does a complete PUT/POST to the origin, or does it forward as it's receiving.
KVM is really easy to setup. Install the package on your linux distro, start up virt-manager if you want gui, "start" new machine and install whatever you want from any cd image you have. Of course once you wrap your head around it you'll want to do it with cli tools and custom automate it. But basic virt-manager might take you a long way. Once you have multiple machines and you want to migrate between hosts you'll have to setup a shared storage. That can be as easy as an nfs share/mount. We started with just 1 ssd for that, but then built a dedicated box with many intel ssds on hardware raid 10. Never had an issue. But shared storage/live migration is not always needed and can add more risk. If you engineer it that all your hosts are independent and you have redundant services for everything, then you dont need to live migrate. If you need to free up that host, just turn it off, as you have redundant services running on other hosts.
In fact on our Dev systems we run KVM on our osx laptops nested in a vmware vm. ( vmware can nest like this passing hardware flags to the guest host ) So on osx you run vmware, which runs a linux vm, then that vm is used as a kvm host to run other vms via kvm. This way we can run exactly 100% the same image locally as is in production.
In fact if you really want to do some crazy plumbing... the VM host on my laptop has a VPN link to our DC, this puts it on the same internal network as our DC production hardware. I can then live migrate a production VM ( like a web front end ), onto my laptop, while it's fully operational doing processing for the production environment. On my laptop it will still be, via VPN, receiving and processing live web requests on our website, and properly sending back data to the proxy and user. Not very performant, but the flexible plumbing is nice if you want to test/debug a clone of the exact production system locally.
I just looked what 250TB would cost us on s3, $20k/month, or $240k/year. ( im not even counting the put/get usage )
You can build it, for ease of math, 100x 3TB seagate constellation. 100x $250 = $25k, another $5k easily covers a 45 jbod and raid card and server with ssd zil and arc for zfs and you're done. so $30k. Get 2 more for redundancy and backup as you see fit.
So over 3 years, 720k vs apples to apples 90k ( if you got 3 of those servers) so you save say $600k. You can get a decent remote dev for $200k/year for that time.
We run straight kvm virtualization on our own hosts for flexibility. We run dbs on bare metal. I hear all these stories of people vms "crashing" all the time but i can tell you we have only had 1 instance of a vm, or in this case host dying in 4 years. Happened to be one of the video conversion hosts that is pinned 24/7 and it turned out it just hit some un recoverable memory hardware error. No big deal there were others.
Flexibility? We can clone and spin up VMs at will. We can live migrate and upgrade hosts. We can automate things with virtlib to our hearts desire.
Costs? $1500/month for direct equinix colo ( includes power, full rack, and gigabit connection from tier1 provider ) Never had a power issue, never had a network issue. We also use a CDN for static stuff and thats extra. We started with 3 servers, now are at a dozen, and adding a new one does not add a new monthly expense.
You can have a E3-1240 V2 @ 3.40GHz server built for $1500 and that as a host can run most of our front end stack. Sure we have 6 of those for backend crap, redundancy, but we actually run most of our stack on 1 of them. Mostly we do that for shits and giggles, but also because the interaction between the www, redis, mcd, zeromq is a few ms faster when it does not go over physical net. So if you over optimize like us, and want 30ms page gen times, you can nerd out like that.
s6 CPU: 8 MEM: 32080MB total running CPU: 16 MEM: 16384MB r-fp1 running CPU: 2 MEM: 1024MB r-mcd2 running CPU: 2 MEM: 1024MB r-www2 running CPU: 2 MEM: 4096MB r-www3 running CPU: 2 MEM: 4096MB r-red1 running CPU: 2 MEM: 2048MB r-red2 running CPU: 2 MEM: 2048MB r-zmq running CPU: 2 MEM: 1024MB r-zmq2 running CPU: 2 MEM: 1024MB
front end proxy, www front ends, redis, zeromq, memcached, etc. Excluding mysql db which is on bare metal. This serves our site that handles about 200 page views per second peak day, and that is at 25% host utilization. Our pages generate ( no caching ), including redis, zmq, and maybe 25 db mysql calls per page in about 30ms. You can optimize things too like...you know that the default config on a server will kick down the cpu to 1.6Ghz if its not really loaded, and that means page gen times in our case would be 15ms slower. Hell, we dont have to try to save power, so we can kick that sucker to 3.4Ghz all the time and make sure users get the benefit of that. Nice to be in control of the host.
We never needed remote hands or anything like that, but that is available a phone call away. I visit the colo in San Jose once a year and I schedule it with my motocycle trip down there. Sometimes I just dust the servers off, pet them a little and look at the pretty lights.
Of course ec2 has it's use. If your html traffic spikes higher than 1 gbps, then it's nice to have the flexibility of a fatter distributed pipe. If you want to optimize for rtt then it's nice to be able to spin up in a different geographical areal.
I think what bugs me the most is that a lot of companies use the argument of, if you get high traffic, like slashdotted or hackernews you can spin up a 100 front ends easily and handle it. We've been on the top of hackernews and the change in traffic was in the noise floor as compared to 200 r/s we normally handle. The point I'm trying to make is that if you engineer your app better, and understand and fix issues with generating your pages faster, you wont need the fancy scale to 100 front ends bullshit. ( tip. it's probably your database queries anyways so optimize that. it's not the print/echo statement that is outputting html on the front end ) Of course some do require webscale and it's a good way to go with ec2 and all the extra costs and engineering, but it seems that every joe blow and his blog or app seems to think they need so spin up to 100 front ends.
Sorry for the rant. I actually think that ec2 and the likes are the future and as tech gets better and prices get better I can see it making sense for more and more. I just wanted to give a contrast with our current setup.
"This is retarded! There's no delay in the while loop. How many times does the client have to connect to the DB per second? Thousands! I can't believe this implementation is so fucking stupid!"
In this case we try to refer to the code directly, taking our reference to the person.
If you configure innodb correctly it comes down how much IO you can do on your log fs, to make sure you can sustain some update rate to this sequential log. Then nest is the IO to the db fs, so you can sustain the rate of the flushes. You can tune some of this much better with some percona mysql patches. Innodb does insert batching for you to minimize IO, and if you are doing updates to the same data it may even buffer the changes in buffer pool.
Also it's much easier as of late to get the benefit from a larger initial cwnd. Back then you needed to recompile the kernel with source tweaks, now you just use a backport or depending on your distro version you already have the benefit as kernel 2.6.39 has the change... http://kernelnewbies.org/Linux_2_6_39
megaupload owners - fast cars, hookers and blow
studios - fast cars, hookers and blow
actors - fast cars, hookers and blow
apple - wages for workers in china.
I guess the lesser evil is the studios...at least they are employing local hookers!