对于小的并发量,我们能做的一些简单的优化,特别实际

其实很多时候,我们在现实生活中遇到的很多并发量并没有像淘宝双十一一样,可能只有它的1%而已,不要总想着,要么你的项目并发量特别大,要么你的项目并发量基本没有。

其实在实际中,我们应该尽可能的去优化我们的系统。

这里我就只列举那些现实可用的,简单的,我们能力范围之内的。这些优化方案其实对于小的并发来说足够了。

1、CDN,这个可能实现起来需要条件,它能缓存你系统的所有静态的页面数据,注意只有那些静态的页面,CSS,JS等可以缓存,CDN能减少你从主要服务器取数据的操作。而且真的很快,其实很多时候,我们可以使用网上的一些CDN的jQuery也是同样的道理。

2、redis,缓存数据库,它能帮助缓存一些后端方法极其频繁的数据,他的访问速度很快,并发量抗的很高,类似的这种也有很多。存放的方式多数都是以键值对的方式存放读取,很方便。

3、存储过程,其实访问很多时候,时间慢是因为网络的延迟,而对于数据库的访问,如果一个sql非常复杂,那么它的传输和执行就特别受网络延迟的影响,所以解决的方式就是使用存储过程,它把你的sql预先放在了数据库上面,这样减少了sql的数据量,执行的速度就能提高,也减少了对于网络延迟的影响。

4、前端控制,利用简单的js其实就可以限制一些正常用户的操作,防止用户的频繁操作等,这里我就不列举了,总之,控制用户的访问也特别重要。

5、地址控制,有时可以通过加密,先保存真正的操作地址,让用户无法真正访问到,等到时间到,再开启访问。

对于服务器的负载均衡什么的,涉及架构方面的,本人能力有限,还没有研究到那步,暂时我觉得如果能做到以上的优化,至少对于小的并发量来说,还是很有效果的。

时间: 2024-12-15 07:09:00

对于小的并发量,我们能做的一些简单的优化,特别实际的相关文章

系统吞吐量(TPS)、用户并发量、性能测试概念和公式

系统吞吐量(TPS).用户并发量.性能测试概念和公式 PS:下面是性能测试的主要概念和计算公式,记录下: 一.系统吞度量要素: 一个系统的吞度量(承压能力)与request对CPU的消耗.外部接口.IO等等紧密关联. 单个reqeust 对CPU消耗越高,外部系统接口.IO影响速度越慢,系统吞吐能力越低,反之越高. 系统吞吐量几个重要参数:QPS(TPS).并发数.响应时间 QPS(TPS):每秒钟request/事务 数量 并发数: 系统同时处理的request/事务数 响应时间:  一般取平

提升高并发量服务器性能解决思路

刚刚在网上淘了一个提升高并发量服务器性能解决思路,个人感觉非常不错,给大家分享出来,希望给您有所帮助. 提升高并发量服务器性能解决思路 一个小型的网站,可以使用最简单的html静态页面就实现了,配合一些图片达到美化效果,所有的页面均存放在一个目录下,这样的网站对系统架构.性能的要求都很简单.随着互联网业务的不断丰富,网站相关的技术经过这些年的发展,已经细分到很细的方方面面,尤其对于大型网站来说,所采用的技术更是涉及面非常广,从硬件到软件.编程语言.数据库.WebServer.防火墙等各个领域都有

性能测试之QPS、TPS、并发量、系统吞吐量的概念

QPS: 每秒钟处理完请求的次数:具体是指发出请求到服务器处理完成功返回结果. TPS:每秒钟处理完的事务次数,一般TPS是对整个系统来讲的.一个应用系统1s能完成多少事务处理,一个事务在分布式处理中,可能会对应多个请求,对于衡量单个接口服务的处理能力,用QPS比较多. 并发量:系统能同时处理的请求数 RT:响应时间,处理一次请求所需要的平均处理时间 计算关系: QPS = 并发量 / 平均响应时间 并发量 = QPS * 平均响应时间 TPS: (每秒事务处理量(TransactionPerS

并发量计算公式

并发的基本概念 并发的概念: 指网站在同一时间访问的人数,人数越大,瞬间带宽要求更高. 服务器并发量分为: 1.业务并发用户数:2.最大并发访问数:3.系统用户数:4.同时在线用户数: 估算业务并发量的公式: C=nL/T C^=C+3×(C的平方根) 其中:C是平均的业务并发用户数.n是login session的数量.L是login session的平均长度.T是指考察的时间段长度.C^是指业务并发用户数的峰值. 例子分析 假设OA系统有1000用户,每天400个用户发访问,每个登录到退出平

根据PV量来确定需要进行压测的并发量

在实际做压力测试的过程中,我们有时不知道用怎样的并发量比较好,下面是几个用PV量去确定并发量的公式,这个在我们公司是比较适用的,大家可以根据自己的业务进行运算. 方法一:这个方法是我在网上查到的80-20原则,具体运算方法为: X*0.8/(8*60*60*0.2) 说明:X为要压测页面的PV量 方法二:这个是将PV量除以高峰时段小时(比如9:00-17:00,就是8个小时),再除以60*60细化到秒,然后乘以12倍,已获得想要的并发量 (X/8/60/60)*12 说明:X为要压测页面的PV量

处理大并发量订单处理的 KafKa部署总结

处理大并发量订单处理的 KafKa部署总结 今天要介绍的是消息中间件KafKa,应该说是一个很牛的中间件吧,背靠Apache 与很多有名的中间件搭配起来用效果更好哦 ,为什么不用RabbitMQ,因为公司需要它. 网上已经有很多怎么用和用到哪的内容,但结果很多人都倒在了入门第一步 环境都搭不起来,可谓是从了解到放弃,所以在此特记录如何在linux环境搭建,windows中配置一样,只是启动运行bat文件. 想要用它就先必须了解它能做什么及能做到什么程度,先看看它是什么吧. 当今社会各种应用系统诸

大流量高并发量网站的之解决方案

一.对于网站访问速度影响的条件如下: 瓶颈主要有: 1.磁盘搜索 优化方法是:将数据分布在多个磁盘上 2.磁盘读/写 优化方法是:从多个磁盘并行读写. 3.CPU周期 优化方法:扩充内存 4.内存带宽 二.大流量高并发量网站的解决方案 1.确认服务器硬件是否足够支持当前的流量. 2.使用memcache缓存技术,将动态数据缓存到内存中,动态网页直接调用这些文件,而不必在访问数据库. 3.禁止外部的盗链. 4.外部网站的图片或者文件盗链往往会带来大量的负载压力,因此应该严格限制外部对自身图片或者文

使用gevent提高IO繁忙型wsgi服务的并发量(转)

add by zhj: 个人认为gevent还是更牛逼一些,当然,这只是我简单的分析,没有试验过.对比分析如下: 使用Tornado,启动一个进程,N个线程 使用Gevent,启动一个进程,N个协程 CPU除了执行用户代码外,就是调用调用程序进行线程/协程切换.而协程切换要比线程切换的开销小,速度快,所以Gevent的并发性能应该更好. 原文:https://co-ding.com/?p=356#comment-6036 我的一个线上web服务在生产中遇到一个性能问题:当初为了方便选择了wsgi

Loadrunner根据PV量来确定需要进行压测的并发量

在实际做压力测试的过程中,我们有时不知道用怎样的并发量比较好,下面是几个用PV量去确定并发量的公式,这个在我们公司是比较适用的,大家可以根据自己的业务进行运算. 方法一:这个方法是我在网上查到的80-20原则,具体运算方法为: X*0.8/(8*60*60*0.2) 说明:X为要压测页面的PV量 方法二:这个是将PV量除以高峰时段小时(比如9:00-17:00,就是8个小时),再除以60*60细化到秒,然后乘以12倍,已获得想要的并发量 (X/8/60/60)*12 说明:X为要压测页面的PV量