小规模、低性能、低流量的网站该如何搞

2021-01-08 10:08:19 阅读（237） 评论（0）

另一个副作用是很容易让人兴奋。如果他们不学走路，他们会先学跑步。在许多条件仍然不具备的情况下，过度设计和扩展（高德纳叔叔也说过，"过早优化是万恶之源")，因此，这里反弹琵琶，讨论小规模、低性能、低流量的网站该怎么办。如果站点的起步阶段可能是机器(或虚拟机)，如JobsDigggg.com)，此时，要注意什么数据分割啊，负载平衡啊，没有阴影。许多大网站的经验不能复制，辩证参考是*道理。拥抱熟悉的技术来建立一个网站，不要问别人应该使用什么，熟悉什么，如果你使用他们不擅长的技术手段来写网站，当你完成它时，黄花菜可能会很酷。因此，如果有现成的软件组件可用，不要重新发明轮子。人们说Python牛，但他们只懂PHP，那么PHP就好了，如果熟悉的话.net?，那也不错。用烂技术不丢人，用烂技术才丢人。架构层次清晰起步阶段应明确确定架构层次。如果都混在一起，一旦业务扩大，原来的一堆东西拆不开就很痛苦了。WebServer (AppServer)Cache(eg.Memcached)DB层次清晰度的体现是(以LAMP架构为例)：即使只有一台机器，也要举个Memcached的例子，效果真的很好——我不告诉普通人。...一旦I/O压力到达磁盘，不要把一切都压在DB上。问题很快就会暴露出来。是的，DB本身也会使用自己的Cache，但DB的Cache和Memcached设计的起点毕竟是不同的。是的，DB本身也会使用自己的Cache，但DB的Cache和Memcached设计的起点毕竟是不同的。数据冗余有必要，许多人不是数据库设计专家。如果应用程序需要设计自己的表结构，它们基本上是临时的。然而，许多人记得这三种范式。这是大多数小型Web网站头疼的问题。一个小应用程序制作了几十个表...忘记范式这个东西！记住，尽可能多的冗余数据，你在数据层中的时间越多，你在产品上的投资就越少。用户更关心产品的设计。前端优化非常重要，因为流量低，访问者可能不多。此时，值得注意的是，页面不应该太大。大多数流量低的网站在一个页面上遭受损失（两天前我看到Startup的主页有4M，这是惊人的）。用户不能在半分钟内打开页面。你觉得怎么发展？先满足基本条件，再研究前端优化。要谨慎增加功能不是有80/20的原则吗？把最重要的精力放在最能给你带来商业价值的地方。一些花哨的功能带来了巨大的开支，但收效甚微。记住，最有价值的小网站是商业模式，而不是你的技术有多好。服务于业务的技术，不要炫耀技术。一些网站不断添加功能，正是把这些新功能变成了压死自己的稻草。从一开始就考虑性能是可选的，但也很重要。在设计应用时，一开始就要考虑Profile。一套应用能否在后期有效优化和扩展，很大程度上取决于是否有更合适的Profile机制。需要补充的是，必须考虑相关的历史数据来考虑性能。此外，请参考网站运维方式的容量规划等小帖子。好的结构不是设计出来的，这是最后要补充的。良好的结构与最初的设计有关，但最重要的是发展的演变：发展-->发现问题-->反馈-->解决问题(执行)-->改进->进化到下一阶段——新问题出现(循环)。有些网站在某个阶段停滞不前，可能卡在执行力上。用户反馈出来后，没有改进的动力。最后，死猪不怕开水烫。最怕听到的就是"业务不允许"想象一下，如果不改进业务，业务还允许吗？其实是一层心理障碍。这篇文章有很强的山寨风格，所以不要太认真。如果你以一种短、平、快的方式建立一些模仿网站，你可以参考对你有益的观点，不同意的地方可以直接忽略，没有必要留下评论来争论。

以上就是关于小规模、低性能、低流量的网站该如何搞的相关介绍，更多小规模、低性能、低流量的网站该如何搞相关内容可以咨询我们或者浏览页面上的推荐内容。我们将让你对小规模、低性能、低流量的网站该如何搞有更深的了解和认识。

内容来源:网络，以上内容来源于网络，不代表本站观点，如有侵权，请联系删除。

上一条：想对国内站长说的一些心里话下一条：安全漏洞，导致域名轻易遭窃