The schedule for the 2009 Percona Performance Conference has been released. Take a look, see what interests you, and (optionally) register to come. We look forward to seeing you all there!
Entry posted by Ryan Lowe | No comment
Add to: 
| 
| 
| 
| 
A couple of weeks ago Sphinx Technologies, a company behind Sphinx Full Text Search Engine launched Sphinx Support Packages which I think is a great value for everyone using Sphinx in Production. This is also a great way to support the project and get something in return - even if you’re not actively using support it looks better than donation for accounting people.
The Support approach was closely modeled from MySQL Support of the early days - simple service lever differentiation with no per server pricing or different editions. This is exactly how I think Support for Open Source project should be structured. Of course such service offering may be lacking the “leverage” but how much leverage do you really need if you do not have sales and marketing teams or venture capitalists to feed? If money you pay go directly to people providing you the service you can get a very good value for fair price.
You may note at Percona we also have Sphinx Support so how are these different ?
Support from Sphinx Technologies is based on traditional support model with limit (or no limits) on number of incidents submitted. If you have Full or Premium support you also get priority bug fixes for any repeatable bug fixes.
Support from Percona uses our standard “you pay for the time” billing approach. We have great Sphinx experts internally including people involved in some of the earliest and largest Sphinx installations and we will escalate the the Sphinx Development team on partnership basics if it is required. This escalation to Sphinx Developers is also a way we handle bug fixes and custom Sphinx development which are all covered by standard Percona agreements and paid on “actual work required” basis.
Entry posted by peter | No comment
Add to: | | | |
Scalability Perspectives is a series of posts that highlights the ideas that will shape the next decade of IT architecture. Each post is dedicated to a thought leader of the information age and his vision of the future. Be warned though – the journey into the minds and perspectives of these people requires an open mind.
Lew Tucker is the Vice President and CTO of Sun Microsystems’ Cloud Computing initiative.
Lew’s career has been focused on scalable computing and web development. Lew worked at Sun Microsystems through the 1990’s. In 2002, Lew joined Salesforce.com and led the design and implementation of App Exchange. After Salesforce.com, Lew was CTO at Radar Networks, where he focused on the scalable design and build out of its semantic web service.
Sun has recently announced its open RESTful API for creating and managing cloud resources, including compute, storage, and networking components. Lew and his team is busy implementing Sun's cloud offering. His background and experience from the creation of Salesforce App Exchange has helped the team to create a simple but flexible set of APIs. Lew envisions open, interoperable clouds based on community standards such as the Cloud API.
Lew Tucker has demonstrated the use of the Sun Cloud by building a Virtual Data Center built of virtual servers, switches and storage. He commented on the announcement in this interview.
我很喜歡以太空站來類比部落格，因為兩者都是為了「存在」：建造太空站的目的是讓人類能夠永久存在於太空中，經營部落格的目的則是讓個人永久存在於網路上。兩者都是長期的工程，成果是逐漸累積的。有必要時，兩者也都會面臨銷毀舊站、重建新站的決定。
由七個模組組成的前蘇聯和平號太空站，是人類在太空中永久存在的第一個成功嘗試。和平號的建造期間長達十年（1986-1996），也創下了連續十年（1989-1999）有人員駐站的紀錄。但就像所有人造建築一樣，和平號後來開始老化。駐站人員幾乎每天都在修東西，根本沒時間做實驗。2001 年 3 月，俄羅斯政府終於決定將和平號太空站推向地球大氣層銷毀，結束了人類太空探索的一段輝煌歷史。
和平號的生命結束了，但和平號在太空中 15 年為人類累積的知識，及其象徵的人類在太空中永久存在的精神，都沒有結束。1998 年，美國、俄羅斯、日本、加拿大與十幾個歐洲國家開始合作建造國際太空站。建造這個新的太空站的工程與科學基礎，正是來自和平號太空站累積的經驗。國際太空站的建造期間同樣漫長，至今仍在增加新的模組。而國際太空站從 2000 年底開始連續有人員駐站至今，也已超過 8 年。
我們可以預見，國際太空站也會有老舊的一天，也終將面臨重返大氣層銷毀的命運。但我們也知道，屆時必定會有新的太空站取代國際太空站，而人類也會繼續在太空中永久存在。
不論是 20 世紀最後 10 年的個人網站或是 21 世紀前 10 年的部落格，都是一種個人在網路上永久存在的方式。我們把自己思考的一部分轉換為文章、照片、影片、或程式碼，一點一點地送上網路。然後，像建造太空站一樣，在網路中將它們組織起來，形成一個完整的結構。這個結構，就是個人在網路上的表徵或代理人。換句話說，就是個人在網路上存在的形式。
這個建造的過程是漫長的。我們的大腦中儲存了大量的資訊，而且每天都還會增加新的經驗。但我們一次只能送出極小的一部分到網路上，因為寫作、拍照、錄影、編程都需要時間。這就好像太空站的建設，每一次美國太空梭或俄羅斯火箭升空，都只能運送一個模組到太空站。人們應該體認，個人在網路上永久存在，跟人類在太空中永久存在一樣，是一個必須永續經營的任務。
人們尋求在網路上永久存在的同時，相關的資訊技術也在進步。在個人網站的時代，我們用 FTP 軟體上傳自己編輯的網頁與其他資料到網路空間中，還需要自己修改首頁的連結以反映新增的內容。我從 1994 年開始以純手工的方式建造個人網站，就這樣做了 10 年。到了後期，資料量越來越大，維護的工作也變得更繁瑣。這種狀況，就像和平號太空站一樣。於是，我在五年前砍掉經營了 10 年的個人網站，改用 WordPress 部落格系統來建設、管理與呈現網路上的自我。
在今天的網路世界中，20 世紀最後 10 年建立的個人網站多半不是廢棄了就是消失了。但對我來說，過去的文章換了一種形式後仍然持續存在於網路上。從個人網站到部落格的改變也許是在很短的期間發生的，但個人的成長是長期的、連續的。部落格之於個人網站，就像國際太空站之於和平號太空站一樣。個人在網路上永久存在的目標沒有改變，就像人類在太空中永久存在的目標沒有改變一樣。
部落格總有一天會被新的技術所取代。多年以前我們砍掉了個人網站，多年以後我們終將再度砍掉部落格。我不確定那一天什麼時候會到來，也不確定新技術會有如何的樣貌。但可以確定的是，當那一天到來，我會準備好以新的技術繼續在網路上存在。希望你也一樣。
没人愿意等待。
所以，没有访问者真的能够忍受一个打开速度极慢的网站。但是，网页打开速度到底对用户行为有什么影响，恐怕没几个人能够说清楚吧。
前几天，我读到一篇这方面的文献综述，感到非常别开生面。下面就是一点摘录。
网页打开的最佳速度
2秒！
许多研究都表明，用户最满意的打开网页时间，是在2秒以下。用户能够忍受的最长等待时间的中位数，在6～8秒之间。这就是说，8秒是一个临界值，如果你的网站打开速度在8秒以上，那么很可能，大部分访问者最终都会离你而去。
研究显示，如果等待12秒以后，网页还是没有载入，那么99%以上的用户会关闭这个网页，不再等待。
但是，如果在等待载入期间，网站能够向用户显示反馈消息，比如一个进度条，那么用户可以忍受的时间会延长到38秒。
对访问者的心理影响
根据一些抽样调查，访问者倾向于认为，打开速度较快的网站质量更高，更可信，也更有趣。
相对应地，网页打开速度越慢，访问者的心理挫折感就越强，就会对网站的可信性和质量产生怀疑。在这种情况下，用户会觉得网站的后台可能出现了一些错误，因为在很长一段时间内，他没有得到任何提示。而且，缓慢的打开速度会让用户忘了下一步要干什么，不得不重新回忆，这会进一步恶化用户的使用体验。
这个指标对电子商务网站尤其重要。载入速度越快，就越容易使访问者变成你的客户，降低客户选择商品后、最后却放弃结账的比例。
不过，网站反应速度也不宜太快，否则用户会增加与服务器互动的频率，这可能加大出现错误的概率。
一些实证结果
Google做过一个试验，显示10条搜索结果的页面载入需要0.4秒，显示30条搜索结果的页面载入需要0.9秒，结果后者使得Google总的流量和收入减少了20%。
Google地图上线的时候，首页大小有100KB，后来下降到70~80KB。结果，流量在第一个星期上升了10%，接下来的3个星期又再上升了25%。
Amazon的统计也显示了相近的结果，首页打开时间每增加100毫秒，网站销售量会减少1%。
宽带与窄带的区别
有研究显示，宽带用户比窄带用户更没有耐心。宽带用户愿意忍受的最长等待时间，往往只有4～6秒。
网站制作者必须记住，在ADSL条件下，3~5秒就能载入的网页，在窄带条件下需要20~30秒才能打开。因此，网页总的大小——包括图片、Javascript和CSS文件的大小——不宜过大，这样对宽带和窄带用户都有利。
（完）
| 三月 2009 | ||||||
| 一 | 二 | 三 | 四 | 五 | 六 | 日 |
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 | |||||