Tarotoast’s Stuff

Recently, 1&1 released Fedora Core 3 with Plesk 7.5 as one of the images server administrator can restore to. Since I've messed up the server a lot, instead of spending more time trying to figure out how to fix it and upgrade it, a quicker solution is to reimage it to FC3. This leads to backuping things up. I tried to get ftpfs working so there would be easy access to 1&1's backup server, but the process seems like this: I'm getting close the solution, but there is this one problem which leads to another problem, and then as I get close to the solution of this another problem, there's another one problem that leads to another another problem. You get the idea. Anyway, I ended up using tar and ftp command to manually backup files and upload them onto the backup server.

Directories backuped:

• /etc
• /home/httpd
• /var

1&1's FAQ has an article "What should I backup?" and I think… yeah… well… it's a 1&1's FAQ, as long as you're happy. I use the standard tar zcvf to add each directory info one .tgz file and then upload it onto the backup server. After these, simply go to the admin panel's Server ReImage page, and select Fedora Core 3 w/ Plesk 7.5, then click the button. In about 40 minutes? Maybe less? The refreshed page finally shows Server Ready.

These are what I really used during restore:

• /etc/csh.cshrc
• /etc/screenrc
• /home/httpd
• /var/lib/mysql

I tried to restore mysql database through the dumped out database via phpmyadmin by uploading them into the sql query window. It doesn't work (orz). What I found out that worked way easier is to create the database & user via Plesk first, and then copy the old database files onto the new ones. Files are located under /var/lib/mysql/[databasename]/. Since I'm getting my old files back from the FTP backup server, installing FTPFS helps a lot.

Additionally, there are other things to do after the newly reimaged server:

• Move /opt to allow Plesk 8.0 update: For some mysterious reason, Plesk 8.0 refuse to install unless you have enough space under /opt. Ironically, by default, there is not enough space. So to make Plesk 8.0 happy in this FC3, link /opt to /home/opt.
• Change the timezone: relink the file /etc/localtime to the correct timezone listed under /usr/share/zoneinfo. For mine:
  ln -sf /usr/share/zoneinfo/US/Pacific /etc/localtime
• Add ntpdate into root's cron:
  0 * * * * /usr/sbin/ntpdate time.ucla.edu
• Essential packages: yum install cvs firefox openssl python-devel subversion vim xterm
• Essential Packages not available via yum: apt, ncftp. rpm -iv files.

Also within /etc/my.cnf under [mysql.server], add in:

set-variable = max_connections = 300
set-variable = max_user_connections = 300

Do they work? I haven't get a chance to try yet.

To be updated later if new things came across.

1&1's Dedicate Servers come with a free FTP backup account that is only accessible within the server, and has a capacity matching the server's harddrive. Wouldn't it be nice if I don't have to use text-only ftp command to put, get files from that server? Yeah, mount it as an directory.
There are couple options available:

• FTP File System (FTPFS)
• UserLand FileSystem (LUFS)
• Filesystem in Userspace (FUSE)

FTPFS is obsolete. Since FUSE is merged into Linux Kernel 2.6.14, it seems reasonable to choose FUSE than LUFS. So the task now is to recompile a Linux Kernel version 2.6.14 and up with FUSE support. As far as how to compile the kernel, there are way too many articles detailing step by step howtos. Since this dedicated server is using FC3, I followed this article. If you have a kernel 2.6.14 and up and want to enable FUSE, simply add this into your kernel's .config file.

CONFIG_FUSE_FS=y

Reboot with the new FUSE-enabled kernel, then we're ready to use all the Filesystem based on FUSE. There were quite many. Since the focus is to mount FTP access as a directory, using FTP as keyword and search through the page brings us to two choices:

• FuseFTP: Written in Perl.
• CurlFtpFs: Using libcurl.

CurlFtpFs seems to be more feature-rich, so I went with it. Note that on SF's Project Detail, the Development Status is 3-Alpha, so use it with your own risk. Since I'm only working on occasional copying and retrieving of backups, and it works fine, I'm happy with it. Installation of CurlFtpFs is simple, given that libcurl and dependencies are installed correctly. These are the steps:

• Download and extract the latest version of CurlFtpFs here.
• Configure: ./configure
• Compile: make
• Install: make install

So it's done. Mounting procedure is as followed:

• mkdir MountPoint (eg: mkdir /backup)
• curlftpfs -o user=USERNAME:PASSWORD ftp://FTPHost/ MountPoint/
  (eg: curlftpfs -o user=testusr:mypass ftp://127.0.0.1/ /backup/)

Done. Now that FUSE is installed, here are some other interesting filesystems available under FUSE:

• SMB for FUSE
• GmailFS
• CvsFS
• User-level Versioning File System
• SshFS
• BitTorrent File System
• WikipediaFS
• Flickrfs
• BlogFS
• CryptoFS

I was trying to get Flickrfs working has no success at the authentication part where I need to authorize the Flickr API to access my Flickr photos. If you succeed, please tell me how.

When a site was dugg to the front page of Digg, the amount of requests to the server will usually take down small sites running on relatively low end hardwares (small RAM, slow CPU, HDD). To prevent this from happening to your site (specifically, WP blogs), there are things you can do to maximize what low end hardwares can manage, and therefore prevent the Digg Effect.

From last experiment, I am very aware this $69/mo (now $99/mo) 1&1 Dedicated Root Server with 2.0Ghz Celeron, 512MB RAM and 40GB HDD cannot take on Digg Effect without doing some tweaking. Here are the measures I’ve gathered:

1) Cache it: WP-Cache 2.0

A very-easy-to-install-and-use plugin. By creating cached pages, it reduce the php code parsed by the web server, and also eliminate the query to mysql database. Both speeds up the page load dramatically.

You can test to see the difference by doing very simple test, this is what I get:

Without cache:

time wget http://blog.tarotoast.com/
>> 0.005u 0.007s 0:01.36 0.0% 0+0k 0+0io 0pf+0w

With cache:

time wget http://blog.tarotoast.com/
>> 0.003u 0.012s 0:00.02 50.0% 0+0k 0+0io 0pf+0w

I don’t really know what all numbers mean, but I know the time for the request is reduce from 1.36 second to .02 second. Keep in mind, however, counter plugins (like Counterize) will not count requests for cached pages (so you don’t feel as good).

2) Apache 2: MPM Worker

Taken directly from Apache’s website:

This Multi-Processing Module (MPM) implements a hybrid multi-process multi-threaded server. By using threads to serve requests, it is able to serve a large number of requests with less system resources than a process-based server. Yet it retains much of the stability of a process-based server by keeping multiple processes available, each with many threads.

In order to use the php module, you need to compile it with thread safety.

3) Stress Test with ab

ab stands for Apache Benchmarking

ab -n 100 -c 100 -d http://URL

This will give you an idea how your webserver can handle traffic.

*Warning: set the number small and increase it slowly.

4) Additional Tweakings

• Configuring Apache for Maximum Performance: easy to read article giving a lot of tips in configuring your apache server.
• eAccelerator: cache php pages at compiled level, which means your php codes will stil be executed. Much faster than no cache at all.

Digg

基於好玩加測試的心態, 把上一篇丟上 Digg.com, 希望看會不會拼上首頁. 結果大約兩個小時後, 還真的上了… Orz

在解釋發生了什麼事情之前, 值得一題的是, 阿幹看了後馬上指出這篇一個禮拜前 gslin 大大已經 po 過了. 我剛收到信阿.. OTZ… lag 真大.

• 丟上 Digg 之後就開始觀察大家如何點進網頁, 大致上是在剛 post 的 30 分到 1 小時時候會由 diggall 那邊進來
• 到了第二頁以後, 由於已經有了一些 digg, 所以在 diggclound 那邊會變的多很顯眼, 所以大部分的人會經由 diggcloud 連到 digg page, 然後再連進來.
• 過了 40 的那一瞬間, 就跑到首頁去了

那 Servre 端有什麼反應:

• 在 1~15 digg 之間大約每分鐘都會有一兩個人逛上來
• 然後 16~39 之間大約每分鐘約 10 個吧
• 然後 40 後的約 10 秒, 主機就爛掉了.. XD

因為後來在 32 digg 之後 (約 1.5 hr after post) 我就發現怎麼 digg++ 的速度便快了, 所以就連進 server 裡面觀察好了. top 按下去放著. 忽然間, httpd 洗整排 Orz:

然後接這就是 MySQL 死掉了, too many connection, 所以 wordpress 也掛了…

估計上首頁的那瞬間, 大概上百人一次湧進來然後 db 馬上就超過 max_connection=100 然後就死掉了… 於是我很天真的想說, 那來把 max_connection 改成 1000 然後重開 mysql 好了. 結果我發現 ssh session 開始 lag 了, 沒搞錯吧 orz, 好歹主機也給 100Mbit, 1000GB/mo 的線路阿.. XD 不過 top 觀察結果顯示:

512MB 的 mem 像大便一樣, 一點用也沒有 Orz, 然後 Swap 1G 耶 Orz… 看來 1&1 的 $69.99 Dedicated Server (現在已經變成 $99.99) 一點也不耐操阿 XD. 我想即使我一開始把 mysql max_connection 改成 1000, 再來也會因為 mem depleted 和 hdd swap 而網頁一樣爛掉吧. 說不定得改 httpd.conf 的 keepalive? timeout? 隨便, 反正我也沒那種時間去研究那些參數 orz. 死掉後觀察了約 4, 50 分鐘, 放棄了, 睡覺吧.. XD 睡醒後就退啦~
真是一次有趣的經驗阿.. XD

PS. 上首頁後約 15 分內大概就太多人 report bad link, 於是就從首頁上消失了.. XD 還好有這東西阿.. XD 不然現在還在死當吧.. XD

四處找了找, Joomlashack 裡面有幾個還可以看的免費 template , 於是順手將診所原本使用的那個預設 template 換掉. 診所文章內容順便也重新分類了一次, 並直接由 HTML 修改了一些編輯不完善的文章, 看來 Joomla 本身的 WYSIWYG Editor 還有待加強阿. 雖然說多了 table 與 class 和其他的支援, 但是問題還是一大堆. 相對比起來 Wordpress 的強太多了.

在著手開始弄診所網站之前, 剛好在 Digg 上面看到了這篇 Image Cross Fader, 於是呢, 就整合進診所首頁了… XD

比較好奇的是 javascript 裡面 .innerHTML 的用法. 雖然這應該不是什麼新的東西, 但是對不常接觸這些東西的我來說很神奇了.

考完 (不知道多久以後的事情) 之後再來弄個比較像樣的 Logo.