# 擴大早期創業規模 > 原文： [http://highscalability.com/blog/2007/10/28/scaling-early-stage-startups.html](http://highscalability.com/blog/2007/10/28/scaling-early-stage-startups.html) [的 Mark Maunder 不需要 VC](http://novcrequired.com) -倡導不收取 VC 資金，以免您變成青蛙，而不是您夢 dream 以求的王子（或公主）–具有出色的[滑蓋[](http://novcrequired.com/scalingEarly.ppt) ，了解如何擴展早期啟動。 他的博客還提供了一些不錯的 SEO 技巧和一個非常怪異的小部件，顯示了讀者的地理位置。 完美的萬圣節！ 馬克對創業公司的其他世俗化擴張策略是什么？ 網站：http：//novcrequired.com/ ## 信息來源 * [西雅圖技術啟動對話](http://novcrequired.com/scalingEarly.ppt)的幻燈片。* [擴展早期創業[Mark Marker]的博客文章](http://novcrequired.com/2007/scaling-early-stage-startups/)。 ## 該平臺 * Linxux* ISAM 類型數據存儲。* 佩爾* [Httperf](http://www.hpl.hp.com/research/linux/httperf) 用于基準測試。* [Websitepulse.com](http://websitepulse.com/) 用于性能監控。 ## 架構 * 性能很重要，因為速度過慢可能會浪費您 20％的收入。 UIE 的人不同意這不一定。 他們在[可用性工具播客：頁面下載時間的真相](http://www.uie.com/brainsparks/2007/09/24/usability-tools-podcast-the-truth-about-page-download-time/)中解釋了其原因。 這個想法是：“我們的研究還有另一個令人驚訝的發現：下載時間與用戶是否在網站上成功完成任務之間存在很強的相關性。但是，實際下載時間與任務成功之間沒有相關性，這導致我們 放棄我們最初的假設。似乎，當人們完成了他們打算在某個網站上進行的工作時，他們會認為該網站是快速的。” 因此，最好將時間用于改進前端而不是后端。 * MySQL 因性能問題而被棄用：MySQL 無法處理大型表上的大量寫入和刪除操作，寫入操作浪費了查詢緩存，不完全支持大量小表（超過 10,000 個），使用了大量內存 高速緩存索引，以每秒 200 個并發讀/寫查詢的最大速度，記錄超過 100 萬條記錄。 * 對于數據存儲，它們演變成固定長度的 ISAM 樣記錄方案，允許直接查找數據。 仍然使用文件級鎖定，其基準測試為 20,000 多個并發讀取/寫入/刪除。 考慮使用性能非常好并且被許多大型網站使用的 BerkelyDB，尤其是當您主要需要鍵值類型查詢時。 我認為，如果很多數據最終顯示在網頁上，則存儲 json 可能會很有趣。 * 已移至 httpd.prefork for Perl。 在應用程序服務器上沒有 keepalive 的服務器使用更少的 RAM，并且運行良好。 ## 得到教訓 * 正確配置數據庫和 Web 服務器。 MySQL 和 Apache 的內存使用很容易失控，隨著交換的增加，導致網格性能緩慢下降。 以下是一些有助于解決[配置問題](http://www.possibility.com/epowiki/Wiki.jsp?page=VpsConfiguration)的資源。 * 只服務您關心的用戶。 阻止使用大量有價值的資源免費爬行您網站的內容主題。 監視他們每分鐘獲取的內容頁面的數量。 如果超過閾值，然后對它們的 IP 地址進行反向查找并配置防火墻以阻止它們。 * 盡可能多地緩存數據庫數據和靜態內容。 Perl 的 Cache :: FileCache 用于在磁盤上緩存數據庫數據和呈現的 HTML。 * 在 URL 中使用兩個不同的主機名，以使瀏覽器客戶端可以并行加載圖像。 * 使內容盡可能靜態創建單獨的 Image 和 CSS 服務器以提供靜態內容。 對靜態內容使用 keepalive，因為靜態內容每個線程/進程占用的內存很少。 * 留下大量的備用內存。 備用內存允許 Linux 在文件系統緩存之前使用更多內存，從而使性能提高了約 20％。 * 關閉動態內容的 Keepalive。 增加的 http 請求可能會耗盡為它們服務所需的線程和內存資源。 * 您可能不需要復雜的 RDBMS 來訪問數據。 考慮一個重量更輕的數據庫 BerkelyDB。 “它們演變為固定長度的 ISAM（如記錄方案）”-我不清楚，這是哪個應用程序？ 他們不再使用 BerkleyDB，而不再使用 MySQL，他們說他們正在使用什么嗎？ [http://www.callum-macdonald.com/“](<a rel=) title =” Callum“ target =” _ blank“ > Callum 嗨，卡勒姆， 我收到了托德發來的關于您問題的電子郵件。 :) 我們從頭開始構建了自己的快速文件存儲例程。 它寬松地基于 ISAM 或 MySQL 的 MyISAM，因為它使用固定長度的順序記錄。 對于我們需要的某些特定操作，它要快得多。 不幸的是，目前它還不是開源的，但也許我們會在將來發布它。 問候， Mark Maunder FEEDJIT 創始人& CEO 他在幻燈片“幻燈片”中談到 MySQL，“ MySQL 不支持大量小表（超過 10,000 個）。” 為什么地球上會有超過 10,000 張桌子？ 這聽起來像是糟糕的設計。 @Dimitri：加入有點晚，但是為了回答您的問題，使用多個小表而不是一個大表可以更有效地解決某些情況。 一個典型的例子是 WordPress 多用戶（ [http://mu.wordpress.org/faq/）](http://mu.wordpress.org/faq/))為每個博客創建表。 以防萬一您不想點擊鏈接:-) *WordPress MU 為每個博客創建表，這是我們發現的系統，在經過大量測試，反復試驗后，對于插件的兼容性和擴展性而言，其工作效果最佳。 這利用了現有的 OS 級和 MySQL 查詢緩存，還使分割用戶數據變得更加容易，這是超出單個功能范圍的所有服務最終都必須要做的。 我們是實際的人，所以我們將使用最有效的方法，對于 WordPress.com 上的 2.3m 數據，MU 一直是冠軍。* We built our own fast file storage routines from the ground up. It's loosely based on ISAM or MySQL's MyISAM in that it uses fixed length sequential records. It's a lot faster for certain specific operations that we require. Unfortunately it's not open source at this time but perhaps we'll release it in future. 初學者的好起點 ----- [http://underwaterseaplants.awardspace.com“](<a rel=) >海洋植物 [http：//underwaterseaplants.awardspace .com / seagrapes.htm“](<a rel=) >海葡萄... [http://underwaterseaplants.awardspace.com/plantroots.htm”](<a rel=) >植物根 如果您是一家公司，請閱讀本書： <cite>[http://www.amazon.com/gp/product/0470345233?ie=UTF8 &標簽= innoblog-20 & linkCode = as2 &營地= 1789 & creative = 9325 & creativeASIN = 0470345233“](<a rel=) >如何 Cast 割公牛：有關風險，增長和業務成功的意外教訓 http： //www.assoc-amazon.com/e/ir?t=innoblog-20 & l = as2 & o = 1 & a = 0470345233“ width =” 1“ height =” 1“ border = “ 0” alt =“” style =“ border：none！important; margin：0px！important;” / NetApp 創始人 Dave Hitz 的>提供了直接，誠實，周到的業務建議，適用于整個業務成長周期中的業務創始人和領導者。 他特別強調艱難的選擇和決策過程，并從冒險的一生中獲得了一種理解。 如果您是第一次創業，請閱讀本書。 如果您正在進入公司的成長階段，請閱讀本書。 如果您第一次嘗試失敗并想了解原因，請閱讀本書。 如果您想笑些，請讀這本書。</cite> 這樣可以使您的公司擴展過程更有趣。