URL 刷新
原理:强制回源拉取更新的文件,并更新CDN Cache节点上的指定文件。
任务生效时间:5-10 分钟之内生效。
注意事项:
输入的 URL 必须带有 http://或者 https://
同一个 ID 每天最多只能预热刷新共 2000 个 URL。
目录刷新
原理:强制回源拉取更新的目录,并更新CDN Cache节点上的指定文件目录,适用于多内容较多的的场景。
任务生效时间:5-10 分钟之内生效。
注意事项:
一天最多提交 100 个刷新请求。
所输入内容,需以 http://或者 https://开始,以”/”结束。
URL 预热
原理:将源站的内容主动预热到L2 Cache节点上,用户首次访问可直接命中缓存,缓解源站压力。
任务生效时间:5-10 分钟之内生效。
注意事项:
输入的 URL 必须带有 http://或https://
同一个 ID 每天最多只能预热刷新共 2000 个 URL。
资源预热完成时间将取决于用户提交预热文件的数量、文件大小、源站带宽情况、网络状况等诸多因素。
要说可以支持多少用户,是无法得到一个准确答案的。用户支持的数量由许多因素组成,例如使用的语言、架构、处理的业务类型 数据大小等。这是一个需要连续调整优化过程的。
第一需要确定业务类型
1、不同的服务有不同的特性,有些CPU占用比较高,有些内存比较高,还比如数据处理,有些需要大量带宽,例如网络爬虫,有些磁盘很高,例如图片和数据库类。
2、同一配置的机器运行不同的业务,效果会有所不同,而且未使用的资源将大大浪费。
3、根据自己的业务类型调整机器的资源比率是节省资金和改善支持的好方法。
第二确定数据大小
1、网络传输的数据大小决定了带宽占用。尺寸越小,带宽越大,每单位时间可以访问和处理的用户请求越多。
2、然后,减少无效数据传输并减小请求分组的大小是必须考虑的地方以改善用户访问能力。
第三连续测算和调整
1、支持的TPS数量,是不断监控并不断调整的。很多时候,小参数调整可以带来多重性能提升。几十秒的业务请求,可能会在几十毫秒内完成调整。
2、真正的在线服务,持续监控和持续调整是一个长期的过程的。
第四使用恰当的语言架构
1、设计良好的系统,与随便设计的系统,终端能力是全然有所不同的。
2、克服资源浪费问题,可使用Docker之类的容器化,微服务化,能精确的提高资源使用率,减少服务器压力。
3、使用Nginx或是Tengine、打开NIO、打开压缩、及设立静态与局部缓存等,减少服务器负载。
4、使用MongoDB、NoSQL数据库,减少数据查询压力提升响应速度。
总之,减少前端无效请求,后端请求在靠近用户侧解决掉,避免业务过长,堆积在后端底层。
扩展资料:
1、服务器,也称伺服器,是提供计算服务的设备。由于服务器需要响应服务请求,并进行处理,因此一般来说服务器应具备承担服务并且保障服务的能力。
2、服务器的构成包括处理器、硬盘、内存、系统总线等,和通用的计算机架构类似,但是由于需要提供高可靠的服务,因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。
3、在网络环境下,根据服务器提供的服务类型不同,分为文件服务器、数据库服务器、应用程序服务器、WEB服务器等。
参考资料来源:百度百科–服务器
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)