# 扩大早期创业规模 > 原文： [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> 这样可以使您的公司扩展过程更有趣。