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

2021-01-08 10:08:19 阅读（238） 评论（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机制。需要补充的是，必须考虑相关的历史数据来考虑性能。此外，请参考网站运维方式的容量规划等小帖子。好的结构不是设计出来的，这是最后要补充的。良好的结构与最初的设计有关，但最重要的是发展的演变：发展-->发现问题-->反馈-->解决问题(执行)-->改进->进化到下一阶段——新问题出现(循环)。有些网站在某个阶段停滞不前，可能卡在执行力上。用户反馈出来后，没有改进的动力。最后，死猪不怕开水烫。最怕听到的就是"业务不允许"想象一下，如果不改进业务，业务还允许吗？其实是一层心理障碍。这篇文章有很强的山寨风格，所以不要太认真。如果你以一种短、平、快的方式建立一些模仿网站，你可以参考对你有益的观点，不同意的地方可以直接忽略，没有必要留下评论来争论。

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

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

商标/知识产权

网站服务

CRM/销售管理

ERP/智慧办公

财税系统

安全/技术支持

其他应用

商标版权

小程序

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

推荐阅读

猜你喜欢

分类

最新文章