如果愿意与本站交换友情链接,请先加上本站链接,然后按以下格式填写信息并留言。
参考格式:
Blog标题名称: Nickyhu
Blog链接地址: http://www.nickyhu.com
Blog简短介绍: 网站优化和网站策划
谢谢支持!
继“2008上海互联网草根大会”( 官方论坛 )的成功,上海站长联谊会进一步巩固为中小网站的服务能力,拓展为中小网站的服务渠道,决定在2008年11月至2009年1月期间举办“2009首届上海中小网站文化节”活动。
中小网站是一个数量庞大的群体,是推进中国互联网发展不可忽视的一支重要力量。中小网站是一个最富有创新与创业精神的群体,通过突出特色经营和个 性定位,重点满足小众的细分用户需求,占有大型网站无法满足或无暇顾及的个性化市场区域,从而在优胜劣态的快速与激烈互联网竞争中占有一席之地。
中小网站文化节汇集了各项在线赛事、网络评选、知识讲座、特色展览、创业论坛、草根大会等系列活动。全面展示最具进取与执著精神的中小网站风尚, 促进中小网站同行间论道与切磋,揭示2009互联网发展潮流趋势,促使外界更关注与支持中小网站的生存与发展,创造更有利于中小网站创业的市场环境。中小 网站文化节,在宣扬健康、创新的互联网草根文化的同时,也必将有助于我国互联网整体产业的发展。
codeigniter升级到1.7之后,有几点需要注意。原先的validation进行了大调整,虽然保留了旧的class,但还是建议按照新的规则来重新编写代码。session的类也有调整。
Nickyhu觉得CI正在变得强壮,从原来轻快敏捷的身段上,加入了肌肉。正在把更多细节落实。Bug也在不断修补。
下面是CI 1.7的官方更新说明:
Release Date: October 23, 2008
SVN Revision: 1541
wordpress已经升级到2.6.3了。我还在使用2.6.1,落后2个版本了。要不要update?自己手动update真的很烦很危险。弄不好就哪里出错了,整个blog崩溃。还是免了吧。
什么时候wordpress能够提供自动update啊?
如果愿意与本站交换友情链接,请先加上本站链接,然后按以下格式填写信息并留言。
参考格式:
Blog标题名称: Nickyhu
Blog链接地址: http://www.nickyhu.com
Blog简短介绍: 网站优化和网站策划
谢谢支持!
Nickyhu一直推崇PHP作为网站的编程语言,原因自不待言。今天,就来介绍一个国内很优秀的“只经营”PHP虚拟主机的盘古网络,推荐给广大个人站长,作为建站时选择虚拟主机的参考。
下面我先来介绍一下盘古网络的情况:
盘古网络成立于2005年2月,是一家以提供虚拟主机,租用服务器服务为主的公司。
盘古网络作为一家专业的服务商,专业稳定的主机和良好持续的售后服务是公司的重点。
专业稳定的主机:
盘古网络从2005年开始,坚持以Linux,cPanel和Directadmin控制面板搭建专业的PHP虚拟主机,对PHP及CGI程 序真正做到了完美支持,打破了Windows主机对一些建站程序的枷锁。盘古网络几年间从没有推出过一款ASP主机,这也为盘古网络的专业性提供了长足的 累积。
盘古网络的主机线路丰富,包括电信线路,网通线路以及移动双线线路,适合各种线路的客户选用。
盘古网络的主机硬件配置高,全部采用4核至强处理器和4G-8G内存作为服务器的标准搭配,这也保证了所有服务器的长时间稳定运行。
作为专业主机的一部分,盘古网络提供给客户的主机控制面板采用目前最强大的cPanel控制面板,使得客户对自己主机的操作极为方便和快捷。
良好持续的售后服务:
盘古网络实行的是国内很少有虚拟主机服务商拥有的真正的7×24小时售后服务,服务内容包括主机故障解决,程序安装,调试,数据导入导出等等 一系列和主机有关或无关的内容。在7×24小时服务之下,在各种时间快速解决客户,服务器的各种问题得到了有力的保障。
盘古网络服务团队的专业素质是公司努力的重点,提供标准化专业服务是让盘古网络始终在客户中获得良好口碑的关键。
盘古网络的服务器遇到问题,或者有重要事件,都会主动在第一时间通知客户,通知方式包括Email通知和会员中心通知系统通知,从来不让客户对任何问题无从了解。
细节一样是盘古网络所关注的,盘古网络提供的售后服务还含有一系列免费增值服务,例如一站式ICP备案服务,让客户只需要在盘古网络提交相关信息即可完成备案,例如手机通知服务,盘古网络会对已开通手机通知服务的客户进行重要事件的手机短信通知,等等。
此外,盘古网络的服务联系方式多样,可供客户在不同条件下选择,包括电话服务,QQ/MSN服务,在线客服系统服务,会员中心提问服务,Email服务。
专业稳定的主机和良好持续的售后服务,都是盘古网络的一直以来的运营重点和长远的目标。
现在和未来,盘古网络会在专业化主机和服务的道路上做出更大的努力。
盘今网络
盘今网络是盘古网络的简化版,于2008年初推出,提出了“做最具性价比主机”的目标。
除了硬件配置稍低和服务内容简化一些之外,7×24小时专业售后服务的内容并不缩水,而由于价格较低,非常适合刚刚入门的站长和学生的使用。
下面是盘古网络提供的主机服务:
1 虚拟主机
2 特别主机
3 合租服务器
4 独立服务器
特别推荐:Nickyhu是盘古网络的忠实用户,因此能够获得盘古的特殊优惠码:NICKYHU。只要你在购买php虚拟主机提交页的优惠码一栏填写“NICKYHU”!就能获得10%的优惠噢!
REST架构风格是全新的针对Web应用的开发风格,是当今世界最成功的互联网超媒体分布式系统架构,它使得人们真正理解了Http协议本来面貌。随着 REST架构成为主流技术,一种全新的互联网网络应用开发的思维方式开始流行。
目前,51,校内,海内,阿里软件等都通过REST架构来实现平台数据的开放,与第三方的数据交换。REST已然成为sns开放平台的首要开放标准。下面简单介绍一下REST的原理和使用准则。
wiki介绍见此:http://en.wikipedia.org/wiki/Representational_State_Transfer
REST是什么
REST是英文Representational State Transfer的缩写,中文翻译为“表述性状态转移”,他是由Roy Thomas Fielding博士在他的论文 《Architectural Styles and the Design of Network-based Software Architectures》中提出的一个术语。REST本身只是为分布式超媒体系统设计的一种架构风格,而不是标准。
基于Web的架构,实际上就是各种规范的集合,这些规范共同组成了Web架构。比如Http协议,比如客户端服务器模式,这些都是规范。每当我们在原有规 范的基础上增加新的规范,就会形成新的架构。而REST正是这样一种架构,他结合了一系列的规范,而形成了一种新的基于Web的架构风格。
传统的Web应用大都是B/S架构,它包括了如下一些规范 。
客户-服务器
无状态性
缓存
B/S架构的优点是其部署非常方便,但在用户体验方面却不是很理想。为了改善这种情况,我们引入了REST。
REST在原有的架构上增加了三个新规范:统一接口,分层系统和按需代码。
统一接口
分层系统
按需代码
REST的设计准则
REST架构是针对Web应用而设计的,其目的是为了降低开发的复杂性,提高系统的可伸缩性。REST提出了如下设计准则:
REST中的资源所指的不是数据,而是数据和表现形式的组合,比如“最新访问的10位会员”和“最活跃的10为会员”在数据上可能有重叠或者完全相同,而 由于他们的表现形式不同,所以被归为不同的资源,这也就是为什么REST的全名是Representational State Transfer的原因。资源标识符就是URI(Uniform Resource Identifier),不管是图片,Word还是视频文件,甚至只是一种虚拟的服务,也不管你是xml格式,txt文件格式还是其它文件格式,全部通过 URI对资源进行唯一的标识。
REST是基于Http协议的,任何对资源的操作行为都是通过Http协议来实现。以往的Web开发大多数用的都是Http协议中的GET和POST方 法,对其他方法很少使用,这实际上是因为对Http协议认识片面的理解造成的。Http不仅仅是一个简单的运载数据的协议,而是一个具有丰富内涵的网络软 件的协议。他不仅仅能对互联网资源进行唯一定位,而且还能告诉我们如何对该资源进行操作。Http把对一个资源的操作限制在4个方法以内:GET, POST,PUT和DELETE,这正是对资源CRUD操作的实现。由于资源和URI是一一对应的,执行这些操作的时候URI是没有变化的,这和以往的 Web开发有很大的区别。正由于这一点,极大的简化了Web开发,也使得URI可以被设计成更为直观的反映资源的结构,这种URI的设计被称作 RESTful的URI。这位开发人员引入了一种新的思维方式:通过URL来设计系统结构。当然了,这种设计方式对一些特定情况也是不适用的,也就是说不 是所有的URI都可以RESTful的。
REST 之所以可以提高系统的可伸缩性,就是因为它要求所有的操作都是无状态的。由于没有了上下文(Context)的约束,做分布式和集群的时候就更为简单,也 可以让系统更为有效的利用缓冲池(Pool)。并且由于服务器端不需要记录客户端的一系列访问,也减少了服务器端的性能。
使用REST架构
对于开发人员来 说,关心的是如何使用REST架构,这里我们来简单谈谈这个问题。REST不仅仅是一种崭新的架构,它带来的更是一种全新的Web开发过程中的思维方式: 通过URL来设计系统结构。在REST中,所有的URL都对应着资源,只要URL的设计是良好的,那么其呈现的系统结构也就是良好的。这点和TDD (Test Driven Development)很相似,他是通过测试用例来设计系统的接口,每一个测试用例都表示一系列用户的需求。开发人员不需要一开始就编写功能,而只需要 把需要实现的功能通过测试用例的形式表现出来即可。这个和REST中通过URL设计系统结构的方式类似,我们只需要根据需求设计出合理地URL,这些 URL不一定非要链接到指定的页面或者完成一些行为,只要它们能够直观的表现出系统的用户接口。根据这些URL,我们就可以方便的设计系统结构。从 REST架构的概念上来看,所有能够被抽象成资源的东西都可以被指定为一个URL,而开发人员所需要做的工作就是如何能把用户需求抽象为资源,以及如何抽 象的精确。因为对资源抽象的越为精确,对REST的应用来说就越好。这个和传统MVC开发模式中基于Action的思想差别就非常大。设计良好的URL, 不但对于开发人员来说可以更明确的认识系统结构,对使用者来说也方便记忆和识别资源,因为URL足够简单和有意义。按照以往的设计模式,很多URL后面都 是一堆参数,对于使用者来说也是很不方便的。
既然REST这 么好用,那么是不是所有的Web应用都能采取此种架构呢?答案是否定的。我们知道,直到现在为止,MVC(Model-View-Controller) 模式依然是Web开发最普遍的模式,绝大多数的公司和开发人员都采取此种架构来开发Web应用,并且其思维方式也停留于此。MVC模式由数据,视图和控制 器构成,通过事件(Event)触发Controller来改变Model和View。加上Webwork,Struts等开源框架的加入,MVC开发模 式已经相当成熟,其思想根本就是基于Action来驱动。从开发人员角度上来说,贸然接受一个新的架构会带来风险,其中的不确定因素太多。并且REST新 的思维方式是把所有用户需求抽象为资源,这在实际开发中是比较难做到的,因为并不是所有的用户需求都能被抽象为资源,这样也就是说不是整个系统的结构都能 通过REST的来表现。所以在开发中,我们需要根据以上2点来在REST和MVC中做出选择。我们认为比较好的办法是混用REST和MVC,因为这适合绝 大多数的Web应用开发,开发人员只需要对比较容易能够抽象为资源的用户需求采取REST的开发模式,而对其它需求采取MVC开发即可。这里需要提到的就 是ROR(Ruby on Rails)框架,这是一个基于Ruby语言的越来越流行的Web开发框架,它极大的提高了Web开发的速度。更为重要的是,ROR(从1.2版本起)框 架是第一个引入REST做为核心思想的Web开发框架,它提供了对REST最好的支持,也是当今最成功的应用REST的Web开发框架。实际上,ROR的 REST实现就是REST和MVC混用,开发人员采用ROR框架,可以更快更好的构建Web应用。
对开发人员来说,REST不仅仅在Web开发上贡献了自己的力量,同时也让我们学到了如何把软件工程原则系统地应用于对一个真实软件的设计和评估上
Release Date: In development
SVN Revision: XXXX
Scaling and Optimizing your CodeIgniter Application, with Benchmarks
There’s been a few discussions recently about optimizing CodeIgniter applications to make them faster, more reliable, and scalable.
So, let’s look at some methods of doing this, with ‘real’ numbers and benchmarks.
First of all, we need to build a little controller that does ’stuff’.
It’s not extremely intensive, but it gives us a good base to test these optimization techniques.
function index() { $query = $this->db->get('module_pages'); $links = ''; if ( $query->num_rows > 0) { foreach ($query->result_array() as $page): $links .= '<a href="'.site_url($page['uri']).'">'; $links .= ucwords($page['title']).'</a><br />'; endforeach; $data['links'] = $links; } for ($i=0; $i < 10; $i++) { $this->db->like('title', 'London'); $query = $this->db->get('module_pages', 1); if ( $query->num_rows == 1 ) { $row = $query->row_array(); $row['body'] = str_replace('Getting', 'booya', $row['body']); $data['body'] = $row['body']; } } $this->load->view('welcome2', $data); }
And our view file is like this:
<?=$links?> <?=str_replace('booya', 'Getting', ucwords($body))?>
So, now let’s benchmark this little app… with the default CodeIgniter settings… no caching, active record debug on.
Concurrency Level: 10 Time taken for tests: 22.206642 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 857000 bytes HTML transferred: 665000 bytes Requests per second: 45.03 [#/sec] (mean) Time per request: 222.066 [ms] (mean) Time per request: 22.207 [ms] (mean, across all concurrent requests) Transfer rate: 37.65 [Kbytes/sec] received
So, 45.03 Requests per second, not bad… but I think we can make some changes and see that number improve.
First off, let’s change:
foreach ($query->result_array() as $page):
to:
$pages = $query->result_array(); foreach ($pages as $page):
Let’s have a look at the performance difference:
Concurrency Level: 10 Time taken for tests: 21.391068 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 857000 bytes HTML transferred: 665000 bytes Requests per second: 46.75 [#/sec] (mean) Time per request: 213.911 [ms] (mean) Time per request: 21.391 [ms] (mean, across all concurrent requests) Transfer rate: 39.08 [Kbytes/sec] received
So, as we can see… the improvement is very small, just 1.75 request/second quicker…
But they do all add up, so make sure you take a note of this optimization and use it from now on.
Now, onto Memcache, the ‘king’ of caching objects, arrays, you-name-it, in PHP
I start up the memcache service, then change the controller code accordingly:
$memcache = new Memcache; $memcache->connect('localhost', 11211) or die ("Could not connect"); $data = $memcache->get('view_data'); if ( !$data ) { $query = $this->db->get('module_pages'); $links = ''; if ( $query->num_rows > 0) { $pages = $query->result_array(); foreach ($pages as $page): $links .= '<a href="'.site_url($page['uri']).'">'; $links .= ucwords($page['title']).'</a><br />'; endforeach; $data['links'] = $links; } for ($i=0; $i < 10; $i++) { $this->db->like('title', 'London'); $query = $this->db->get('module_pages', 1); if ( $query->num_rows == 1 ) { $row = $query->row_array(); $row['body'] = str_replace('Getting', 'booya', $row['body']); $data['body'] = $row['body']; } } $memcache->set('view_data', $data, false, 3600) or die ("Failed to save data at the server"); } $this->load->view('welcome2', $data);
Now, let’s run the benchmark to see how this improves things.
Concurrency Level: 10 Time taken for tests: 17.124866 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 857000 bytes HTML transferred: 665000 bytes Requests per second: 58.39 [#/sec] (mean) Time per request: 171.249 [ms] (mean) Time per request: 17.125 [ms] (mean, across all concurrent requests) Transfer rate: 48.82 [Kbytes/sec] received
Well, it’s faster, but not by much… I wonder how an opcode cache could improve things?
eAccelerator is an opcode cache extension for php… basically, the way that it works in ’stupid’ terms is like this:
eAccelerator interrupts just after PHP converts our code to its machine code and ‘caches’ it, so next time, it can skip the whole translation phase of execution.
Pretty simple huh?
Lets try the baseline code, with eaccelerator on the top of it.
Concurrency Level: 10 Time taken for tests: 10.122468 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 857000 bytes HTML transferred: 665000 bytes Requests per second: 98.79 [#/sec] (mean) Time per request: 101.225 [ms] (mean) Time per request: 10.122 [ms] (mean, across all concurrent requests) Transfer rate: 82.59 [Kbytes/sec] received
Now, that’s more like it… here we’re still doing our SQL queries, and rendering all the data dynamically, but just caching the machine code, with a drastic improvement.
My main reason for doing this test was just to show off one of the features that I love most in CI, output caching.
Let’s see how well full-output caching works in CodeIgniter…
Some people believe that the overhead involved in writing the cache file outweighs the speed increase of actually rendering from a cache file.
$this->output->cache(3600);
Now we run our benchmark again, (baseline code, with the output caching on) and see if there’s a difference.
Concurrency Level: 10 Time taken for tests: 6.221538 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 857000 bytes HTML transferred: 665000 bytes Requests per second: 160.73 [#/sec] (mean) Time per request: 62.215 [ms] (mean) Time per request: 6.222 [ms] (mean, across all concurrent requests) Transfer rate: 134.37 [Kbytes/sec] received
So, the difference huge, serving 160.73 requests per second, that’s a massive improvement… but I’m not going to stop there!
How about the ultimate? - Output caching, and opcode caching! - eAccelerator with CI Output caching:
Concurrency Level: 10 Time taken for tests: 2.565136 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 857000 bytes HTML transferred: 665000 bytes Requests per second: 389.84 [#/sec] (mean) Time per request: 25.651 [ms] (mean) Time per request: 2.565 [ms] (mean, across all concurrent requests) Transfer rate: 325.91 [Kbytes/sec] received
Who’s the daddy then?
CodeIgniter!
For those of you struggling to digest those numbers… here’s a pretty little graph (made with codeigniter… yeah, I’m hardcore!)

As requested, here’s the results from a couple of other tests.
First off, serving the exact same output as static index.html:
1834.95 Requests per second… Amazingly fast.
And, replacing:
foreach ($query->result_array() as $page): $links .= '<a href="'.site_url($page['uri']).'">'; $links .= ucwords($page['title']).'</a><br />'; endforeach;
with:
foreach ($query->result() as $page): $links .= '<a href="'.site_url($page->uri).'">'; $links .= ucwords($page->title).'</a><br />'; endforeach;
Produces 46.19 [#/sec] (mean)…. again, a slight improvement over using arrays..
But hell, I love arrays!
Elliot
Nickyhu给博客换了新主题,有2个原因:新theme更有设计感,新theme的seo优化比老主题好些。
以下是我总结的写博客为什么要用wordpress的原因:
1 安装方便,身材苗条
2 管理舒适,插件很爽
3 界面丰富,换装省心
4 写得流畅,看得舒心
5 开源支持,畅你所想