精华内容
下载资源
问答
  • 当时一个不爽,自己写了个面向游戏的高性能后端框架,计划用一台8核48G的服务器,跑到百万在线,50万活跃,每秒10万次业务请求的性能,一直压箱底,也没机会拿出来用。 今年又接手了个游戏项目,正好有时间拿这个...

    因起

    大概两年前,半途接手了一个项目,一个Python写的游戏服务器。倒腾倒腾弄上线后,在一台4核16G的服务器上,TPS不满百,平均响应延迟超百毫秒,勉强抗个500-1000人在线。慢的令人发指。业务端反响也不好,没运营多久就下线了,否则要填坑到天明。

    当时一个不爽,自己写了个面向游戏的高性能后端框架,计划用一台8核48G的服务器,跑到百万在线,50万活跃,每秒10万次业务请求的性能,一直压箱底,也没机会拿出来用。

    今年又接手了个游戏项目,正好有时间拿这个框架试试水,整理框架之余,回忆下之前的历程,便有了这一系列的文章,容我慢慢道来。

    目标分解

    关于传统的多线程模型,曾经有个古老的C10K问题。简单点说就是10k在线便开始趴窝,这导致了服务端从异步网络IO到后端处理的一系列结构性变革。异步处理模型解决了高代价的线程切换,却依然难以解决事务的原子性,共享资源争用等问题。在现代的多核CPU环境下,连跨线程间及时更新变量都需要专门通知CPU。高负载下跨线程的共享资源管理必然是一个非常复杂的问题,我不希望,在写业务逻辑的时候,会需要依赖一套严格的规范来保证高并发时的正确性,这对团队编码的要求太高,也不利于错误排查。先规避这个问题,把核心业务处理放到个单一线程使用一颗CPU核心来完成。剩余的7颗核心负责网络IO,数据加载,调度,等外围工作。

    这样,按照10万次每秒的目标来考量,一次请求可以消耗10000纳秒,按照当前的主流CPU,4G左右的主频,每次业务处理共有40000次时钟周期可用,我估计一半的时钟周期,20000个应该就差不多可以处理一次业务了,计算资源应该是够的。而除了这部分,所有前期的数据准备工作和后期的保存输出,尽量设计成可以多线程高并发低争用完成的模式,以便于多核处理。

    根据以往的经验,当数据量或是处理频度大到一定的程度之后,会发生很多奇葩的问题。比方说,某个依赖库报莫名其妙的错误,这种情况下,有时候可以通过自己重新造一个简单但够用的轮子来解决,有时候却不得不去硬啃源代码改现有的库。在系统实现的前期,需要快速的模型实现,验证,测试,重构,开发效率的重要性远高于执行效率,因此,我选择了Java而不是C++来入手编写,后期如果真的要做到极致,再考虑逐步移植到C++上。

    与C++ 相比,Java主要有两个方面的问题,一是略低的执行效率,这个本质上关系不大,这不是一个计算密集型的程序,大量的时间应是消耗在内存访问和I/O上,就算Java执行速度是C++的一半,也够用了,而且,不断进化的JIT编译器,工作的还蛮给力的;另一个则是绕不过去的硬伤,GC,垃圾收集是服务器端永远的痛,尤其在高并发大业务量海量内存的时候,来个秒级的Stop The World绝对欲哭无泪。

    还是按照每秒10万次请求计算,假设每个业务请求需要用20k内存(已经估计的很小了, 来两个Json串就没了),那么每秒钟,就有20k * 100k = 2G内存需要GC。随便一个minor gc都要上秒。所以,把内存管理全丢给JVM是肯定不靠谱的,必须小心处理。三个方面,一是精心调整JVM关于垃圾收集的相关参数;二是自行维护对象池来管理内存,减少临时对象的生成和回收;三是尽可能避免任何未纳入对象池管理,不可重用的对象,进入老年代(Old Generation),甚至在老年代不断累积。前两点很好理解,第三点,避免一些不可重用对象进入老年区,是个略复杂的问题,后续会在讲具体模块时专门提及。

    每秒100k业务的问题想好了,再来想想1M的连接,正常点的连接(不把缓冲区弄到完全不够正常使用)大概需要占用8G左右的内存。再把数据加密,session信息等加上,轻松突破10G,然后,针对TCP堆栈内核还有一系列的管理开销。在游戏服务器可能面临大量小数据包请求响应的情况下(大量请求及响应的实际数据小于40字节),UDP可能会是一个比TCP更合适的选择。

    业务并发,连接,好像没啥了? 不,还漏了最重要的数据,每个请求读写n次数据库?读写n次redis?sql语句生成,返回数据的解析。高并发下,就算redis能抗住,Json的序列化,反序列化都是灾难。这些操作还会生成大量的临时对象,又是垃圾收集的灾难。一个巨大的内存数据缓存,是必不可少的。我n年前针对频繁调用的中型配置数据库,写过一个全库引导进内存的OR Mapping,而游戏服务器显然不可能将所有数据都拉到内存里来,这里必然需要一个有较好的缓存维护能力和清晰的模型关系的缓存管理系统。按照之前的系统内存约束,平均每个在线用户,一共也就30k的总体内存可用,如果用户数据复杂到一定的程度,JVM用32G的堆估计不太够,但高于32G之后又会因为指针扩张的问题,带来更进一步的内存需求,这个问题暂时搁置,到时候根据业务情况看,如果内存不够再优化/增加。

    主机考量完了,看看网络,假设100k请求中,90%是小于40字节的小请求,10%是平均1500字节的大请求,算上layer 4/3/2/1 的包头,每秒的出站流量大概是 72B * 90k + 1526B * 10k = 6480kB + 15260kB= 21740kB = 173920kb = 173mb 这不是一个太夸张的数字。

    资源准备

    Java NIO 说了这么多年,肯定是很成熟的东西了。但是异步的数据访问驱动(拟使用Mysql + redis),似乎没有那么好找。网上找了一会,Mysql似乎只有看上去有些坑还没填上的mysql-async 和Mysql 8 的X DevAPI,Redis的异步驱动倒是很多,但我不太了解,没有什么选择思路。找了一会之后发现Vert.x 正好有完整的对网络IO,Mysql,Redis的异步访问封装,那就先用Vert.x吧,这三个模块在都是准备抽象出来只放在框架中使用的,未来替换成本及低(结果没多久就真的要换了-_-! )。

    框架思路

    异步模型的思路从来都很简单,只是很多时候代码阅读起来会有点复杂。对于大部分服务器端程序来说,每个请求的主线基本都是: (1)读取网络数据 ->(2) 按需读取持久化数据 ->(3) 业务处理及保存数据 -> (4)网络数据输出,这里的(1)(2)(3)(4),前期拟各用一个/或几个线程来完成,所有的 -> 通过队列通讯。其中,第(2)步牵涉到和数据缓存的一些交互,第(3)步结束后有一些数据保存的需求。图我先不画了,以后有空再补上,

    思路有了,先开工吧,边写边想边细化。

    第一个坑

    搭环境、建工程和一些基础代码就不废话了,先写(1),读取网络数据包并预处理。收到数据包后应该干什么? ——基本的session和用户信息维护。那么,应该用什么数据结构维护session? 我的第一反应是HashMap(后来改了,以后慢慢说),key - object映射,灵活,快捷,高性能。

    不管什么语言,基本都有现成的HashMap库可以调用,Java里比较典型的是自带的HashMap和线程安全的ConcurrentHashMap,信手拈来。

    可感觉那里有点不对劲,HashMap和ConcurrentHashMap貌似都和前面我提到的高性能服务器垃圾收集三大套路中的两个相违背。以下便是这两个Map的原罪:
    1 创建了大量的,无用对象。Java里的HashMap泛型是<Object, Object>,除非key使用String(对象缓存),否则会需要新建一个Key对象来做get和put,这个对象会被保存在HashMap的节点中。Java并没有提供类似于 int/long - Object 这样的,用基本数据类型做主键的key-value HashMap。而如果用String做key,内存占用增加,性能下降(需要查找一次String对象),也会对通讯部分有性能(转换成数值)或带宽(String传输字节数较多)资源占用的影响。
    2 HashMap内部用了HashEntry/Node来包装Key和Value,每次put新key,都会新建一个Entry/Node,如果一个HashMap中有100k数量级的对象, 也会有100k个对应的Entry/Node对象。而如果某个key - value对长时间保存在HashMap中之后才被移出,其对应的Key和Entry/Node都应该已被移入老年代,成为非FullGC难以清除的对象。增大FullGC的概率。

    重复写轮子已是迫不得已,写基础类库更是吃力不讨好。从可靠性到性能,很多基础类库都是大神们浸淫数年的精华所在。但该填的坑总得填,从HashMap开始吧,没想到,本系列文章的第一篇正文,将会是,写一个高性能,低内存,线程安全,GC友好的HashMap

    本文所涉及的部分代码,会随着文章进度逐步整理并放到 github上。
    其中,高性能基础数据结构的代码见 https://github.com/Lofint/tachyon

    展开全文
  • 10万条数据进行请求如何处理

    千次阅读 2019-02-27 21:50:35
    首先,用netty进行NIO处理(相当于在收费站前修一个停车场),来的车都进停车场,然后叫号缴费通行,解决20个收费站收费,来的车辆过多,直接服务器崩溃,报504错误。 然后,过了收费站的车辆用消息队列...

     

    首先,用netty进行NIO处理(相当于在收费站前修一个停车场),来的车都进停车场,然后叫号缴费通行,解决20个收费站收费,来的车辆过多,直接服务器崩溃,报504错误。

     

    然后,过了收费站的车辆用消息队列(RabbitMQ)来进行处理。

     

    最后,我们将经常查数据库的数据,用redis来做缓存,减少服务器的压力。

     

    展开全文
  • 支持高并发的IIS Web服务器常用设置 适用的IIS版本:IIS 7.0, IIS 7.5, IIS 8.0 适用的Windows版本:Windows Server 2008, Windows Server 2008 R2, Windows Server...完成上述4设置,就可以支持10万个并发请求

    支持高并发的IIS Web服务器常用设置

    适用的IIS版本:IIS 7.0, IIS 7.5, IIS 8.0

    适用的Windows版本:Windows Server 2008, Windows Server 2008 R2, Windows Server 2012

    1、应用程序池(Application Pool)的设置: 

    • General->Queue Length设置为65535(队列长度所支持的最大值)
    • Process Model->Idle Time-out设置为0(不让应用程序池因为没有请求而回收)
    • Recycling->Regular Time Interval设置为0(禁用应用程序池定期自动回收)

    2、.Net Framework相关设置

    a) 在machine.config中将

    <processModel autoConfig="true" />

    改为

    <processModel enable="true" requestQueueLimit="100000"/>

    (保存后该设置立即生效)

    b) 打开C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\Browsers\Default.browser,找到<defaultBrowser id="Wml" parentID="Default" >,注释<capabilities>部分,然后运行在命令行中运行aspnet_regbrowsers -i。

    复制代码

    <defaultBrowser id="Wml" parentID="Default" >
        <identification>
            <header name="Accept" match="text/vnd\.wap\.wml|text/hdml" />
            <header name="Accept" nonMatch="application/xhtml\+xml; profile|application/vnd\.wap\.xhtml\+xml" />
        </identification>
    <!--
        <capabilities>
            <capability name="preferredRenderingMime"              value="text/vnd.wap.wml" />
            <capability name="preferredRenderingType"              value="wml11" />
        </capabilities>
    -->
    </defaultBrowser>

    复制代码

    以解决text/vnd.wap.wml问题。

    3、IIS的applicationHost.config设置

    设置命令:

    c:\windows\system32\inetsrv\appcmd.exe set config /section:serverRuntime /appConcurrentRequestLimit:100000

    设置结果:

    <serverRuntime appConcurrentRequestLimit="100000" />

    (保存后该设置立即生效)

    4、http.sys的设置

    注册表设置命令1(将最大连接数设置为10万):

    reg add HKLM\System\CurrentControlSet\Services\HTTP\Parameters /v MaxConnections /t REG_DWORD /d 100000

    注册表设置命令2(解决Bad Request - Request Too Long问题):

    reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters /v MaxFieldLength /t REG_DWORD /d 32768
    reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters /v MaxRequestBytes /t REG_DWORD /d 32768

    (需要在命令行运行 net stop http  & net start http & iisreset 使设置生效)

    5、针对负载均衡场景的设置

    在Url Rewrite Module中增加如下的规则:

    复制代码

    <rewrite>
        <allowedServerVariables>
            <add name="REMOTE_ADDR" />
        </allowedServerVariables>
        <globalRules>
            <rule name="HTTP_X_Forwarded_For-to-REMOTE_ADDR" enabled="true">
                <match url=".*" />
                <serverVariables>
                    <set name="REMOTE_ADDR" value="{HTTP_X_Forwarded_For}" />
                </serverVariables>
                <action type="None" />
                <conditions>
                    <add input="{HTTP_X_Forwarded_For}" pattern="^$" negate="true" />
                </conditions>
            </rule>
        </globalRules>
    </rewrite>

    复制代码

    相关博文:迁入阿里云后遇到的Request.UserHostAddress记录IP地址问题

    6、 设置Cache-Control为public

    在web.config中添加如下配置: 

    复制代码

    <configuration>
        <system.webServer>
            <staticContent>
                <clientCache cacheControlCustom="public" />
            </staticContent>
        </system.webServer>
    </configuration>

    复制代码

    7、ASP.NET线程设置

    在machine.config的<processModel>中添加如下设置: 

    <processModel enable="true" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50" minIoThreads="50"/>
     
    说明:
     

    我们来看一下ASP.NET中线程相关的设置——machine.config中的processModel(位于C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config)。

    有4个相关设置:maxWorkerThreads(默认值是20), maxIoThreads(默认值是20), minWorkerThreads(默认值是1), minIoThreads(默认值是1)。(这些设置是针对每个CPU核)

    我们用的就是默认设置,由于我们的Web服务器是8核的,于是实际的maxWorkerThreads是160,实际的maxIoThreads是160,实际的minWorkerThreads是8,实际的minIoThreads是8。

    基于这样的设置,是不是如果瞬间并发请求是169,就会出现排队?不是的,ASP.NET没这么傻!因为CLR 1秒只能创建2个线程,等线程用完时才创建,黄花菜都凉了。我们猜测ASP.NET只是根据这个设置去预测线程池中的可用线程是不是紧张,是不是需要创建新的线程,以及创建多少线程。

    那什么情况下会出现“黑色30秒”期间那样的大量请求排队?假如并发请求数平时是300,突然某个瞬间并发请求数是600,超出了ASP.NET预估的所需的可用线程数,于是那些拿不到线程的请求只能排队等待正在执行的请求释放线程以及CLR创建新的线程。随着时间的推移,释放出来的线程+新创建的线程足以处理这些排队的请求,就恢复了正常。

    那如何验证这个猜测呢? 修改maxWorkerThreads, maxIoThreads, minWorkerThreads, minIoThreads的设置,让ASP.NET提供更多的可用线程,目前我们采用的设置如下:

    <processModel enable="true"  requestQueueLimit="5000" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50" minIoThreads="50"/>

    如果采用这个设置之后,“黑色30秒”现象几乎不出现,就能验证问题出在这个地方。现在主站www.cnblogs.com已经使用了这个设置,需要观察一段时间进行验证。

     
     
    ===================================================================================================================================================
     
     

    服务器最多只能处理5000个同时请求,今天下午由于某种情况造成同时请求超过5000,从而出现了上面的错误。

    为了避免这样的错误,我们根据相关文档调整了设置,让服务器从设置上支持10万个并发请求。

    具体设置如下:

    1. 调整IIS 7应用程序池队列长度

    由原来的默认1000改为65535。

    IIS Manager > ApplicationPools > Advanced Settings

    Queue Length : 65535

    2.  调整IIS 7的appConcurrentRequestLimit设置

    由原来的默认5000改为100000。

    c:\windows\system32\inetsrv\appcmd.exe set config /section:serverRuntime /appConcurrentRequestLimit:100000

    在%systemroot%\System32\inetsrv\config\applicationHost.config中可以查看到该设置:

    <serverRuntime appConcurrentRequestLimit="100000" /> 

    3. 调整machine.config中的processModel>requestQueueLimit的设置

    由原来的默认5000改为100000。

    <configuration>
        <system.web>
            <processModel enable="true" requestQueueLimit="100000"/>

    参考文章:ht

    4. 修改注册表,调整IIS 7支持的同时TCPIP连接数

    由原来的默认5000改为100000。

    reg add HKLM\System\CurrentControlSet\Services\HTTP\Parameters /v MaxConnections /t REG_DWORD /d 100000 

    5. 运行命令使用设置生效 

    net stop http  & net start  http & iisreset 

    完成上述4个设置,就可以支持10万个并发请求

    展开全文
  • 遍历10万条数据,每一条都请求接口。之前的文章里已经记录 有些一个递归方法,来进行请求失败的重复请求。但同时,发现了一个问题,就是for循环里的请求,有一定的几率会线程假死掉。。。这是一件多么不科学的事,...

    1.HttpWebReques遇到的问题

    还是最近手上的项目的问题。。。

    遍历10万条数据,每一条都请求接口。

    之前的文章里已经记录 有些一个递归方法,来进行请求失败的重复请求。

    但同时,发现了一个问题,就是for循环里的请求,有一定的几率会线程假死掉。。。


    这是一件多么不科学的事,正在执行任务中的线程怎么可能被莫名其妙的被GC回收,我相信是我的代码原因造成的,但是在做了异常捕获之后。。依旧没有发现问题,整个程序不报错。。。于是采用了简单粗暴的方式,就是打日志。。。

                    HttpWebRequest request = (HttpWebRequest)WebRequest.Create(appseting.AddressMatchUrl + cellValue);  
                    var response = (HttpWebResponse)request.GetResponse();  
                    StreamReader sr;  
                    sr = new StreamReader(response.GetResponseStream());  
                    responseString = sr.ReadToEnd();  
                    sr.Close();  
                    response.Close();  
                    return responseString; 
    开始执行,执行了3万多行请求之后,程序果然停止了运行,经过日志判断,是停在了
    sr.ReadToEnd();

    这里,就没往下执行。

    很是恼火啊。。。于是百度,找到了同样的情况出现,当时的博主尝试了多种解决方案。

    文章链接如下 点击打开链接

    参考博主的做法,添加了读写超时的限制

    request.ReadWriteTimeout = 10000; 

    至于ReadWriteTimeout和Timeout 的区别这里就不过多赘述。

    但是遗憾的是,这种方式在我这里并不生效,程序依然无限的卡死,并不出现异常。


    2.更换请求方式为HttpClient请求

    基于上面的原因,无法解决ReadToEnd卡死的问题,因此选择了HttpClient做同步的get请求。

    代码如下:

    using (HttpClient client = new HttpClient())
    {
             client.Timeout = new TimeSpan(0, 0, 30000);//设置超时时间
             for (int i = 0; i <= sheet.LastRowNum; i++)  //对工作表每一行  
             {
                ............//其他操作
                responseString = RecursionHttpRequest(0, cellValue, maxreapet, client,obj.AppSettings.AddressMatchUrl);
                ............
             }
    
    }

    递归请求的方法如下

    /// <summary>
            /// 递归请求地址匹配引擎 
            /// </summary>
            /// <param name="n"></param>
            /// <param name="cellValue">请求参数</param>
            /// <param name="maxRepeatRequestNum">请求失败最大重复尝试请求次数</param>
            /// <returns></returns>
            public static string RecursionHttpRequest(int n, string cellValue, int maxRepeatRequestNum, HttpClient client,string url)
            {
                Thread th = Thread.CurrentThread;//获取当前工作线程
                string responseString = string.Empty;
                if (n == maxRepeatRequestNum)
                {
                    return responseString;
                }
                try
                {
                    WriteLog(string.Format("线程名称{0}线程状态{1}开始匹配参数是{2},第{3}次匹配", th.Name, th.ThreadState, cellValue, n));
                    WriteLog("1");
                    Byte[] resultBytes = client.GetByteArrayAsync(url + cellValue).Result;
                    WriteLog("2");
                    responseString = Encoding.UTF8.GetString(resultBytes);
                    WriteLog("3");
                    return responseString;
    
                }
                catch (Exception ex)
                {
                    //捕获异常线程休眠一下 降低请求频率
                    Thread.Sleep(100);
                    Console.WriteLine(ex.Message);
                    n++;
                    return RecursionHttpRequest(n, cellValue, maxRepeatRequestNum, client,url);
                }
    
            }

    这里要说明的是 HttpClient与 HttpWebRequest区别是:

    HttpClient一次连接可以进行n个url的请求,所以我在for循环的外层就实例化了HttpClient,这样大大节约了成本开销,而HttpWebRequest则是一个连接对应一个url请求。

    所以其实针对这次的需求 HttpClient更为合适。

    至于这十万行数据能不能顺利的请求完成,匹配到相应的地址坐标,现在正在测试中...

    祝我好运吧,但愿线程不会假死....








    展开全文
  • 看标题就可以理解,请求合并就是将请求收集起来,进行一个批量的处理。哪请求收集,怎么收集?收集多少?什么时候收集?又什么时候结束呢? 想想一下,你喊来100个小伙伴,在某个时间段里,请求我的接口。我是不...
  • 一个程序员如何快速赚到一百

    万次阅读 多人点赞 2014-05-12 08:51:08
    一个程序员如何快速赚到一百,说的详细点儿就是: 一个固定工作者怎么跳出固有的模式,靠其他途径(投资、理财、生意、创意、外包等)赚得相对殷实的钞票? 80% 人都会问这种赚钱问题,但这种问题却太难回答,...
  • 最近接手一个电视节目晚会的活动需求,跟以往做的有很大区别,因为活动时间短,请求峰值高,而且现场活动的风险非常大。 对我来说也算是一很好的锻炼机会吧,虽然风险也很大。 刚好看到微信团队推送的这篇...
  • 如何扛住100亿次请求?后端架构应该这样设计!

    千次阅读 多人点赞 2019-08-11 17:31:00
    点击上方“朱小厮的博客”,选择“设为星标”回复”1024“获取独家整理的学习资料1. 前言前几天,偶然看到了 《扛住100亿次请求——如何做一个“有把握”的春晚红包系统”...
  • 前段时间有朋友问我一个他们公司遇到的问题, 说是后端由于某种原因没有实现分页功能, 所以一性返回了2条数据,让前端用select组件展示到用户界面里. 我听完之后立马明白了他的困惑,...
  • 某些App怎么扛住1分钟10亿请求? 架构的演进路线 百万级并发:1秒100万次...(2)集群(一个软件部署在多台服务器,并作为一个整体,提供一类服务) (3)高可用(系统中部分节点失效,其他节点能够接替它继续...
  • IIS7.5 真正解决PUT、DELETE请求问题

    万次阅读 热门讨论 2017-02-26 22:00:23
    、首先描述一下生成环境 ... IIS10默认支持http PUT和DELETE请求,但IIS7.5默认不接收PUT、DELETE等不常见的http谓词,如何让asp.net webform或者asp.net webapi在IIS7.5上支持这些请求呢? 三、解决
  • 10万+条Json数据写入到数据库

    万次阅读 2016-06-02 18:15:11
    10万+条Json数据写入到数据库 101254条数据据耗时近10分钟(5677368毫秒)终于插入到...一开始想的是,将这10万多条数据分页查询然后插入到数据库中,于是写了一个循环,准备不断访问那个网站分页获得数据;,但由于不
  • 原文链接:... 一个线程一个连接支持1个并发连接是可以做到的。但需要注意如下问题: (1) 一个线程一个客户连接,当客户退出时需要,删除线程,当新的线程
  • 高并发请求和抢购的解决方案

    千次阅读 2018-01-17 20:00:50
    一个Web系统,在一秒钟内收到数以万计甚至更多请求时,系统的优化和稳定至关重要。这次我们会关注秒杀和抢购的技术实现和优化,同时,从技术层面揭开,为什么我们总是不容易抢到火车票的原因? 一、大规模并发...
  • 一个Web系统,在一秒钟内收到数以万计甚至更多请求时,系统的优化和稳定至关重要。这次我们会关注秒杀和抢购的技术实现和优化,同时,从技术层面揭开,为什么我们总是不容易抢到火车票的原因? 一、大规模并发...
  • 如果控制器是使用单例形式,且controller中有一个私有的变量a,所有请求到同一个controller时,使用的a变量是共用的,即若是某个请求中修改了这个变量a,则,在别的请求中能够读到这个修改的内容。。 有几种解决方法...
  • 最近在研究性能测试,公司有一个项目需要进行性能测试。  这个帖子的内容比较典型,大家有兴趣可以也思考一下。帖子源于51testing论坛 先是楼主提出问题: 最近公司一个项目,是个门户网站,需要做性能测试,根据...
  • 本来我的MyEclipse运行起来速度什么的还是可以的,这运行速度跟电脑配置相关(主要cpu) 进入正题吧! 周码农今天晚上也是被整的死去活来的,现分享一下经验...解决办法: window-->preferences-->General-->startupAndS
  • 每秒处理10万订单支付架构

    千次阅读 2017-11-09 16:47:58
    一、库分表在redis,memcached等缓存系统盛行的互联网时代,构建一个支撑每秒十只读的系统并不复杂,无非是通过一致性哈希扩展缓存节点,水平扩展web服务器等。支付系统要处理每秒十笔订单,需要的是每秒数十...
  • Web大规模高并发请求和抢购的解决方案

    万次阅读 多人点赞 2016-04-12 20:48:57
    一个Web系统,在一秒钟内收到数以万计甚至更多请求时,系统的优化和稳定至关重要。这次我们会关注秒杀和抢购的技术实现和优化,同时,从技术层面揭开,为什么我们总是不容易抢到火车票的原因? 一、大规模...
  • 微信——腾讯战略级产品,创造移动互联网增速记录,10个月5000手机用户,433天之内完成用户数从零到亿的增长过程,千万级用户同时在线,摇摇每天次数过亿……在技术架构上,微信是如何做到的?日前,在腾讯大...
  • 一次下载多文件的解决思路-JS

    千次阅读 2018-10-23 14:38:18
    一次下载多文件的解决思路(iframe) - Eric 真实经历 最近开发项目需要做文件下载,想想挺简单的,之前也做过,后台提供下载接口,前端使用window.location.href就行了呗。不过开发的时候发现,有些文件有附属文件...
  • 每秒处理10万的架构

    千次阅读 2016-09-04 08:26:56
    所以在15年11月,我们对整个支付系统进行了全面的架构升级,使之具备了每秒稳定处理10万订单的能力。为乐视生态各种形式的抢购秒杀活动提供了强有力的支撑。  、库分表  在redis,memcached等缓存系统盛行的...
  • 10万TPS高并发订单的支付系统架构

    千次阅读 2019-03-20 16:54:14
    干货:每秒处理10万高并发订单的支付系统架构 随着各类抢购的不断升级,支付面临的请求压力百倍乃至千倍的暴增。作为商品购买的最后环,保证用户快速稳定的完成支付尤为重要。我们对整个支付系统进行了全面的架构...
  • PHP解决高并发问题

    万次阅读 多人点赞 2020-05-27 12:10:04
    我们通常衡量一个Web系统的吞吐率的指标是QPS(Query Per Second,每秒处理请求数),解决每秒数万次的高并发场景,这个指标非常关键。举个例子,我们假设处理一个业务请求平均响应时间为100ms,同时,系统内有20台...
  • 基于Nginx实现10万+并发,你应该做的Linux内核优化 由于默认的Linux内核参数考虑的是最通用场景,这明显不符合用于支持高并发访问的Web服务器的定义,所以需要修改Linux内核参数,是的Nginx可以拥有更高的性能; ...
  • 用 Python 做到每秒处理上百万 HTTP 请求,可能吗?也许不能,但直到最近,这已成为现实。 很多公司都在为了提升程序的执行性能和降低服务器的运营成本,而放弃 Python 去选择其它编程语言,其实这样做并不是...
  • 一次NoHttpResponseException问题分析解决

    万次阅读 2018-06-29 11:38:11
    新项目上线遇到NoHttpResponseException的问题,大概11000笔发到C系统的交易会出现15笔会因这种异常而导致失败,对月交易量在近三亿的系统来说,按照这样的比例也会有4多笔的交易失败,这种严重影响客户体验的现象...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 98,326
精华内容 39,330
关键字:

如何解决一个10万次的请求