My biggest concern is that a fraudster will simply replace the account information to one he owns him or herself. Because it is such a hot topic on Twitter at the moment, this altered message would make its rounds quickly.

I was able to trace the original message back to @CruzRojainforma, the Chilean Red Cross. So far the retweeted message hasn’t been altered – other than being translated into English. But I’ve urged people to stop retweeting the account details and visit the official Red Cross website at www.redcross.org instead. There’s a link right on their main page that explains how you can donate time or money to the Chilean earthquake efforts.

On a final note, Twitter is also used to find missing persons. And with positive results I may add, as this article explains. Google also has a Person Finder database running, which it had done for te Haiiti earthquake as well. But please ensure that you do not give out too much personal details about the person you’re looking for, because it becomes a (nearly) permanent part of the Internet.

Again, the intentions are good, but there are too many people out there waiting to take advantage of every possible situation so be careful!

Fuerza Chile!

Related posts:

1. Hawaii Tsunami, Sprecks image gallery
2. Add hashtags support to WordTwit
3. Lifestream for March 2nd

While the actual waves were thankfully less high than expected, you do notice two distinct surges in the images. The view here is of the Sprecks towards the West Maui mountains.

Here’s a video which will give a better idea of what it looked like on the ground:

I have another set (with a smoother timeline) from a different location as well, which may add soon as well. A few images from that set stood out and I will share this one with you here:

Apparently this person wasn’t aware that there was a tsunami warning in effect and that you shouldn’t be on the beach, especially not making any phone calls.

Related posts:

1. Lifestream for March 1st
2. Red Cross’ Citibank details on Twitter could be false.

So I have been keeping myself busy with a number of projects, some small, some big. One project has been updating my blog a bit, giving it a fresh coat of paint and tweaking a few bits and bytes. All this tweaking will give the articles some more room, because in my previous layout it seemed rather cramped. I still don’t have a logo though, so those three overlapping circles in the upper-left corner will have to do for now.

For another project, I’ve put the Amazon S3 Fuse driver on a back burner a bit and will focus a bit more on using another company, namely Diomede Storage. This is because the per-request fees at Amazon make it too expensive for the end user. Diomede Storage simply charges for storage and transfers only, and that’s it. As an added bonus, Diomede Storage makes multiple copies of your file(s); even at the minimum of 3 copies it’s less expensive that Amazon or other Cloud Storage providers like RackSpace. The only issue with Diomede Storage is the lack of a complete documentation and a broken REST API, but I’m sure this will be fixed soon.

There are plenty of other projects on my “To-Do” list, including one that involves data centres in the UK, Netherlands and Japan. And although they could potentially fill every hour that I am awake, I’d rather focus on something more important, which is finding a new career opportunity.

The credit crunch is nearing the end and companies are more confident, so now I feel is a good time for me to make the change and settle in with a company where I can remain until my age demands that I retire. Although I do see myself saying “Why the heck should I retire?” – Just so I can keep busy.

Well, whatever lies in my and your path, I hope it’s all well for 2010!

Related posts:

1. A little silence doesn’t hurt

Someone on the OVH forums made mention of using Amazon’s S3 services for external storage and he’s using  s3fs for this purpose.

Interested, I took a peek at this project and was immediately taken back by the lack of >5 GB file support. I have files that cover 10x that size. So what do you do in this case? Fix it!

I’ve seen another (abandoned) project called S3NBD, which comes closer to what I had in mind of how things should work. But as the website noted — and the reason for abandonment — sending a 1 GB file in 4K chunks is rather costly.

Right now I’ve solved the issues between s3fs and S3NBD on paper and have started with the groundwork. I’ll host the project at SourceForge once I feel confident there are no catastrophic issues. They [SourceForge] may advice to “release early, release often”, but I know that generally people will installing things without reading the documentation. So if someone end up with a trillion billable Amazon S3 requests, who’ll they blame first? Yes, me. So I’d rather want to do some initial testing done before I release it in the open.

What’s different

So what’s going to be different? Well, for starters it will not be a NBD but use FUSE, similar to s3fs. It will also support 0-byte files, networked POSIX locks and most importantly, files larger than 5 GB. Yes, files larger than 5 GB at Amazon S3 – in fact, its current upper limit is 16 Exabytes (16,384 Petabytes or 16,777,216 Gigabytes). You never know when this alien drops by to give us more than just Velcro, like a 10 Petabyte hard drive or so.

There are some technical hurdles to overcome because Amazon S3 wasn’t particularly meant to be used in this way. It’s not just overcoming the file limit barriers, but also trying to keep performance at reasonable levels whilst also making sure it remains cost effective opposed to having your own multi-terabyte SAN array. Simpler said than done, really.

So when should you expect this to appear here / at SourceForge? Well, the short answer is: Never ask an open source developer “is it done yet?”.  But the way things are progressing so far, I expect at least something to be released in a week or two. Want to be the guinea pig?

Related posts:

1. Yet another year!

NginX outperforms Apache on small- to mid-range servers when it comes to static file handling, particularly because it is event driven.

The downside of NginX is that PHP can only be used with FastCGI. In general, most how-to’s explain how to implement PHP FastCGI with NginX using TCP. This is adding extra overhead and slows PHP to a crawl. A better solution is to use the UNIX sockets instead, which is explained well in Till’s blog.

But even using UNIX sockets, the PHP FastCGI and NginX combination is not as fast as Apache can handle PHP requests. For this reason, NginX can act as a great accelerator for static files while Apache deals with all the PHP requests. Even with the extra TCP overhead between NginX and Apache, this makes for quite a speedy combination.

Thinking logically, some people figured that loading static files from RAM memory instead of the harddrive must make things even faster. But that really depends…

Using Memcached

Loading static files from RAM memory is accomplished using the memcached daemon and the NginX memcached module. Various how-to’s describe the procedure along these lines:

• A script that’s run at boot time, using a CRON or other method, that loads static files from the harddrive into memcached (RAM).
• NginX is configured to load a requested file from memcached and if failed to do so, load it directly from the harddrive instead.

But unfortunately the NginX memcached module is only capable of TCP communications. If memcached is located on the same server, it would have made more sense to use UNIX sockets instead (just like PHP FastCGI over UNIX sockets).

See, in my case there was so much overhead that NginX slowed to less than 8,000 requests per second. To put this in perspective, Apache was capable of serving 18,898 static 100-byte files per second on the same server.

So using memcached is only worth it if you are caching files that are spread over several back-end servers or are dynamic of nature (ie., PHP output that changes very little). Not if these files are local to NginX, especially with NginX’s highly efficient caching methods.

Speedy NginX

Now, how much faster is NginX compared to Apache when it comes to static files anyway? Well, I’ve have some non-definitive numbers for you, obtained on a low-range server:

Server:

Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz, 2x750GB Seagate Barracuda 7200.11 32M RAID-1, 4GB RAM, Debian Lenny (5.0) i386 (2.6.24-7 Ubuntu-based, back-ported kernel)

Test parameters:

ab -k -c5 -t10000 http://<server>/100.html

Apache:

Server Software:        Apache/2.2.9

Server Hostname:        <server>

Server Port:            80



Document Path:          /100.html

Document Length:        100 bytes



Concurrency Level:      5

Time taken for tests:   2.646 seconds

Complete requests:      50000

Failed requests:        0

Write errors:           0

Keep-Alive requests:    49508

Total transferred:      22577856 bytes

HTML transferred:       5000000 bytes

Requests per second:    18898.08 [#/sec] (mean)

Time per request:       0.265 [ms] (mean)

Time per request:       0.053 [ms] (mean, across all concurrent requests)

Transfer rate:          8333.56 [Kbytes/sec] received



Connection Times (ms)

              min  mean[+/-sd] median   max

Connect:        0    0   0.0      0       0

Processing:     0    0   0.5      0      49

Waiting:        0    0   0.5      0      49

Total:          0    0   0.5      0      49



Percentage of the requests served within a certain time (ms)

  50%      0

  66%      0

  75%      0

  80%      0

  90%      0

  95%      0

  98%      1

  99%      1

 100%     49 (longest request)

NginX:

Server Software:        nginx/0.7.61

Server Hostname:        <server>

Server Port:            80



Document Path:          /100.html

Document Length:        100 bytes



Concurrency Level:      5

Time taken for tests:   1.928 seconds

Complete requests:      50000

Failed requests:        0

Write errors:           0

Keep-Alive requests:    49502

Total transferred:      19397510 bytes

HTML transferred:       5000000 bytes

Requests per second:    25937.28 [#/sec] (mean)

Time per request:       0.193 [ms] (mean)

Time per request:       0.039 [ms] (mean, across all concurrent requests)

Transfer rate:          9826.54 [Kbytes/sec] received



Connection Times (ms)

              min  mean[+/-sd] median   max

Connect:        0    0   0.0      0       0

Processing:     0    0   0.1      0       5

Waiting:        0    0   0.1      0       5

Total:          0    0   0.1      0       5



Percentage of the requests served within a certain time (ms)

  50%      0

  66%      0

  75%      0

  80%      0

  90%      0

  95%      0

  98%      0

  99%      0

 100%      5 (longest request)

This is the setup I’m using on all the web servers I am deploying, NginX as the front-end and a number of Apache servers at the back-end to deal with non-static files, including PHP.

Related posts:

1. A simplified Nginx-Apache combo with WordPress support
2. Faster WP Super Cache with NginX
3. Compiling NginX on Debian / Ubuntu