大型网站架构改进历程:存储的瓶颈(五)

摘要:什么是大型网站,从网站的技术角度考虑这个问题人们很容易犯一个毛病就是认为网站的访问量是衡量的指标,懂点行的人也许会认为是网站在单位时间里的并发量的大小来作为指标,如果按这些标准那么像hao123网站就是了。 【编者按】本文转自博客园的 夏天的森林,在看这篇之前,大家可以移步看 大型网站架构改进历程:存储的瓶颈(一)、(二)、(三)、(四)。 上文里我遗留了两个问题,一个问题是数据库做了水平拆分以后,如果我们对主键的设计采取一种均匀分布的策略,那么它对于被水平拆分出的表后续的查询操作将有何种影响,第二个问题就是水平拆分的扩容问题。这两个问题在深入下去,本系列就越来越技术化了,可能最终很多朋 […]

大型网站架构改进历程:存储的瓶颈(四)

摘要:什么是大型网站,从网站的技术角度考虑这个问题人们很容易犯一个毛病就是认为网站的访问量是衡量的指标,懂点行的人也许会认为是网站在单位时间里的并发量的大小来作为指标,如果按这些标准那么像hao123网站就是了。 【编者按】本文转自博客园的 夏天的森林,在看这篇之前,大家可以移步看 大型网站架构改进历程:存储的瓶颈(一)、(二)、(三)。 如果数据库需要进行水平拆分,这其实是一件很开心的事情,因为它代表公司的业务正在迅猛的增长,对于开发人员而言那就是有不尽的项目可以做,虽然会感觉很忙,但是人过的充实,心里也踏实。

大型网站架构改进历程:存储的瓶颈(三)

摘要:什么是大型网站,从网站的技术角度考虑这个问题人们很容易犯一个毛病就是认为网站的访问量是衡量的指标,懂点行的人也许会认为是网站在单位时间里的并发量的大小来作为指标,如果按这些标准那么像hao123网站就是了。 【编者按】本文转自博客园的 夏天的森林,在看这篇之前,大家可以移步看 大型网站架构改进历程:存储的瓶颈(一)、大型网站架构改进历程:存储的瓶颈(二)。 存储的瓶颈写到现在就要进入到深水区了,如果我们所做的网站已经到了做数据库垂直拆分和水平拆分的阶段,那么此时我们所面临的技术难度的挑战也会大大增强。

大型网站架构改进历程:存储的瓶颈(二)

【编者按】本文转自博客园的夏天的森林,在上一篇中,作者介绍了大型网站的定义、存储瓶颈及如何解决读写分离等问题。而本篇着重详解存储瓶颈及解决之道。大家一起来看下。 503错误 在上篇,我讲到某些网站在高并发下会报出503错误,503错误的含义是指网站服务端暂时无法提供服务,503还表达了网站服务端现在有问题,但是以后可能会提供正常的服务,对http协议熟悉的人都知道,5开头的响应码表达了服务端出现了问题,在我们开发测试时候最为常见的是500错误,500代表的含义是服务端程序出现了错误导致网站无法正常提供服务,500通常是服务端异常和错误所致,如果生产系统里发现了500错误,那么只能说明网站存在逻 […]

大型网站架构改进历程:存储的瓶颈(一)

摘要:什么是大型网站,从网站的技术角度考虑这个问题人们很容易犯一个毛病就是认为网站的访问量是衡量的指标,懂点行的人也许会认为是网站在单位时间里的并发量的大小来作为指标,如果按这些标准那么像hao123网站就是了。 前不久公司请来了位互联网界的技术大牛跟我们做了一次大型网站架构的培训,两天12个小时信息量非常大,知识的广度和难度也非常大,培训完后我很难完整理出全部听到的知识,今天我换了个思路是回味这次培训,这个思路就是通过本人目前的经验和技术水平来思考下大型网站技术演进的过程。

【性能测试】不同阶段的性能测试实施

一、开发阶段的性能测试实施 性能测试不是特别重要的项目,这一阶段的性能测试较多关注于软件功能而引起的缺陷。因此主要进行用户并发性能测试,即核心模块并发用户测试与组合模块并发用户测试。此外,可能还会进行一些预期性能指标的性能测试。通过开发阶段的性能测试可以发现一些核心算法问题,最大限度地排除由软件本身引起的问题。 对于系统类软件或特殊应用系统的性能测试,解决其性能问题可能很耗时,所以应该较早地组织硬件资源进行各类性能测试,例如疲劳强度与大数据量测试、服务器性能测试等

为什么压力测试会耗费我们如此多的时间

我遇到很多客户做过压力测试 – 有大规模的,也有小规模的 – 有用开源工具的,也有用商业软件的。 压力测试本身变得越来越容易,越来越可以支付的起——因为出现了很多很好用的压力测试工具。还有一些公司提供在线压力测试服务。尽管做压力测试越来越容易、越来越有效率、而能花很小的代价产生很大的压强,但是我的所有客户都遇到了同样一个问题:压力测试并不会报告是什么导致了问题。它只会报告这有了问题,例如:查询页面在并发50个用户使用时变慢下来,但它不会显示什么导致了变慢。捕获到的性能统计数据例如CPU和内存使用量只是强调了潜在的问题区域,但并不会指出实际的根源在应用程序的什么地方。 标准的压力测试报告只提供黑 […]

【性能测试】HTTP负载测试

有很多人在谈论HTTP服务器软件的性能测试,也许是因为现在有太多的服务器选择。 这很好,但是我看到有人很多基本相同的问题,使得测试结果的推论值得怀疑。在日常工作中花费了很多时间在高性能代理缓存和源站性能测试方面之后,这里有我认为比较重要的一些方面来分享。 希望能抛砖引玉。   0、一致性 最最重要的是,每次都测试同一个时间点。因为系统发生的每个改变,无论是OS升级还是运行了其它消耗带宽和CPU的应用,都会影响测试的结果,所以一定要把测试环境固定下来。

【性能测试】性能测试知多少:性能分析与调优的原理

最近一直纠结性能分析与调优如何下手,先从硬件开始,还是先从代码或数据库。从操作系统(CPU调度,内存管理,进程调度,磁盘I/O)、网络、协议(HTTP, TCP/IP ),还是从应用程序代码,数据库调优,中间件配置等方面入手。 单一个中间件又分web中间件(apache 、IIS),应用中间件(tomcat 、weblogic 、webSphere )等,虽然都是中间件,每一样拎出来往深了学都不是一朝一夕之功。但调优对于每一项的要求又不仅仅是“知道”或“会使用”这么简单。起码要达到“如何更好的使用”。

【性能测试】性能测试知多少:并发用户

在做性能测试的时候,我们常常听到并发用户、响应时间、吞吐量专业术语,也许大家都理解,这里有一个理解的层次与深度概念。最近有看断念《软件性能详解与案例分析》一书,看了他的讲解,原来我对这些术语的理解还是比较肤浅,其实,这里也主要受制于自己的知识面。所以,再拿出来与大家重温一下。 ps:按照惯例先上个图,因为看纯文字的文章比较累!^_^

【性能测试】80~20原理测试强度估算

基本概念:每个工作日80%的业务在20%的时间内完成。 例如:每天工作8个小时,那么每天80%的业务在8*20%=1.6小时内完成。 例1: 去年全年处理业务约100万笔,其中,15%的业务处理中,每笔务需对 应用服务器提交7次请求;70%的业务处理中,每笔业务需对应用服务器提交5次请求;其余15%的业务处理中,每笔业务对应用服务器提交3次请求。根据以往的统计结果,每年的业务增量为15%,考虑到今后3年业务发展的需要,测试需按现有业务量的两倍进行。 强度估算如下:

【性能测试】理发店模型看性能测试的概念和理论

《“理发店模型”看性能测试的概念和理论》 在我们的这个理发店中,我们事先做了如下的假设: 1. 理发店共有3名理发师; 2. 每位理发师剪一个发的时间都是1小时; 3. 我们顾客们都是很有时间观念的人而且非常挑剔,他们对于每次光顾理发店时所能容忍的等待时间+剪发时间是3小时,而且等待时间越长,顾客的满意度越低。如果3个小时还不能剪完头发,我们的顾客会立马生气的走人。