易栈网-膘叔

本来。。。VPS已经换到budgetVM上面去了，但不幸的是，这两天VPS出了点问题。

结果。。。数据丢失了。
所以我现在又切换到了linode上面。果然，linode还是最好的VPS，没有之一啊。。。

准备利用google的搜索来一一恢复我这段时间的数据。当然。还有googlereader。。。
他们的support里面这么说：

Dear Customers;

We are aware that some of your systems are offline, or failing to reboot, we are working to correct this issue immediatly and we will update you once it has been completed.

This does not affect all of our customers but it appears to be ~5 Virtual Machines per Hardware Node which are failing to boot.

We will update you via your support ticket once it has been resolved. I can assure you we are working dillegintly twords a solution at this time.

Regards,

Nick Rose

Enzu Inc.

然后:

Status update: Node Maintenance Continues

Our administrators are still working on restoring your account to service. We apologize for the inconvenience.

We will be providing a 1 Month SLA Credit for this outage. Further details will arrive when your ticket is resolved.

If you do not need the data on your current vps and would like it reinstalled we can do this for you which will bring it back into service immediately. If you would prefer to wait for the admins to complete their work no further action on your part is required.

We will continue to send updates as they become available.

Thank you for your patience.
-----------------

看到这个就让我感觉纠结了

在讲今天的内容前，请允许我说几句：what the fuck，再说一句：“你哭著對我說童話裡都是騙人的”
前两天说过为了速度我建了索引，虽然给id建了unique的索引，但是数据还是不由分说的插了重复的。好吧。因为数据在unique前就进数据库了。所以。。。我必须要再加上dropDups这个条件。

于是乎，我就先开始删除索引，然后灾难就来了：

b.archive.dropIndex({id:1,unique:true})
{ "errmsg" : "index not found", "ok" : 0 }
> db.archive.dropIndex({"id":1,"unique":true})
{ "errmsg" : "index not found", "ok" : 0 }
> db.archive.dropIndex({"id":1,"unique":true},{name:"id"})
{ "errmsg" : "index not found", "ok" : 0 }
> db.archive.dropIndex({"id":1,"unique":true},{"name":"id"})
{ "errmsg" : "index not found", "ok" : 0 }
> db.archive.dropIndex({category_id:1})
{ "errmsg" : "index not found", "ok" : 0 }
> db.archive.dropIndex({"category_id":1})
{ "errmsg" : "index not found", "ok" : 0 }
> db.archive.dropIndex({"key":{"status":1}})
{ "errmsg" : "index not found", "ok" : 0 }

为什么为什么？？？？
为什么我会这么做？是因为：http://www.mongodb.org/display/DOCS/Indexes
这里面写着：

Dropping Indexes

To delete all indexes on the specified collection:

db.collection.dropIndexes();

To delete a single index:

db.collection.dropIndex({x: 1, y: -1})

Running directly as a command without helper:

// note: command was "deleteIndexes", not "dropIndexes", before MongoDB v1.3.2 // remove index with key pattern {y:1} from collection foo db.runCommand({dropIndexes:'foo', index : {y:1}}) // remove all indexes: db.runCommand({dropIndexes:'foo', index : '*'})

我晕啊。这是肿么了。。。
后来还是神仙和赵拂衣说了一句，试一下dropIndex("xxx")，果然。。。Over了。你说，你这不是忽悠人嘛 ，为了这个，我折腾了一个晚上啊。。。。
害得我当时只能dropIndexes，先删除所有的，再重建索引。。。数据又多，我等了好久好久啊。

前段时候做了个一万条数据的对比，这回做了个2000000条数据的对比：
测试方式还是和以前一样：

测试开始：
1、order by id ASC  limit 25，很常见的查询吧。每页显示25条。
没有索引的时候：0.05秒左右（1万条是0.88秒，很奇怪）
用了id,unique索引后，0.004,第一次的时候0.08，后面稳定在0.00x左右（与1W左右一致）

2、where category_id = 1 limit 25，某个条件
无索引时：24秒左右 (很夸张。。。)
有索引：第一次0.06左右，后面稳定在0.00x(x>6)，即在0.006~0.01之间(与1W左右一致）

3、where category_id = xx order by pubdate limit 25
无索引：20秒左右，最慢的一次达到了70秒
有索引的时候，与条件2差不多。。

虽然不是特别的深入测试，但这样也几乎足够了。不过，这带来另一个问题。内存消耗比较大啊。果然是吃内存大户

在手册里，关于header函数的说明是说服务端会输出一系列的头，用firebug也可以看得很清楚
一般来说，我们用header控制的情况不是特别多，毕竟不会主动去改什么：一般也就设置设置编码、跳转、压缩等，不太会过多的干涉。下载的时候也会设置头，黑黑

手册上，我们对于cache都是写着如何设置，以便让代码不被cache：

header("Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0"); // HTTP/1.1
header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date in the past
header("Pragma: no-cache"); // Date in the past

而且在设置的时候还得注意在header前不能有输出，否则header设置无效，但都没有写过，如何给页面设置Cache，虽然我们知道有一些办法，比如 E-TAG之类的。当然也有简单的设置：
比如我们在输出前，对内容进行md5，将它当成e-tag只要没变化，就不会有影响。也有其他的方式：

$seconds_to_cache = 3600;
$ts = gmdate("D, d M Y H:i:s", time() + $seconds_to_cache) . " GMT";
header("Expires: $ts"); header("Pragma: cache");
header("Cache-Control: max-age=$seconds_to_cache");

缓存1小时，主要是过期时间得用gmdate来设置，而不是date，这个要注意，其他都差不多。maxage要和expire能够对得上。

不算笔记的笔记。

有时候会用到gzip函数，只是有时候而已。。。
于是。。有些函数就会直接用上了。比如 ：gzencode,gzdecode,gzcompress,gzuncompress,gzdeflate,gzinflate
在用的时候。。有些是想当然的。。。比如有Gzencode，就一定会有gzdecode吧？错。。。gzdecode暂时还没有正式版本支持，只存在于svn中，虽然手册上有。。但也说明了不能用

gzcompress与gzdeflate的区别，一个是基于RFC1950协议，一个是基于RFC1951，gzcompress因为是用的1950协议，手册上说了，它需要zlib库。gzdeflate就不需要
所以，gzcompress现在用的相对又少了一点。

好吧，现在说说我的粗心了，大家都知道Gzip压缩是有等级的（压缩软件都有，1~9，1最低压缩，9是最高压缩比），用9的话压缩出来的文件最小，但是解压的时候最耗CPU。所以一般 都是level4，其实就算是1也不错了。

粗心的就在于gzinflate的时候，想当然的将第二个参数length想成level了。结果一直在报错。居然我5分钟后才反应过来。NND，太粗心了。。。
第二个参数是length，不是level啊。