If you use pgcc and compile everything with -O6, the mysqld server is 1% faster than with gcc 2.95.2. If you link dynamically (without -static), the result is 13% slower on Linux. Note that you still can use a dynamically linked MySQL library for your client applications. It is the server that is most critical [...]
Posts Tagged ‘优化’
可以在不影响页面显示效果的前提下减少你的CSS代码,我测试了一个css,还真有效果,优化掉近10%。[ 链接 http://flumpcakes.co.uk/css/optimiser/ ] 这个则可以把CSS紧凑化[ 链接 http://www.cssdrive.com/index.php/main/csscompressor ] [Copy From : http://cnc.sablog.net/blog/]
(本文是Monty在O’Reilly Open Source Convention 2000大会上的演讲) MySQL的优化(本文是Monty在O’Reilly Open Source Convention 2000大会上的演讲) [晏子 编译整理] 一、我们可以且应该优化什么? 硬件 操作系统/软件库 SQL服务器(设置和查询) 应用编程接口(API) 应用程序 ——————————————————————————– 二、优化硬件 如果你需要庞大的数据库表(>2G),你应该考虑使用64位的硬件结构,像Alpha、Sparc或即将推出的IA64。因为MySQL内部使用大量64位的整数,64位的CPU将提供更好的性能。 对大数据库,优化的次序一般是RAM、快速硬盘、CPU能力。 更多的内存通过将最常用的键码页面存放在内存中可以加速键码的更新。 如果不使用事务安全(transaction-safe)的表或有大表并且想避免长文件检查,一台UPS就能够在电源故障时让系统安全关闭。 对于数据库存放在一个专用服务器的系统,应该考虑1G的以太网。延迟与吞吐量同样重要。 ——————————————————————————– 三、优化磁盘 为系统、程序和临时文件配备一个专用磁盘,如果确是进行很多修改工作,将更新日志和事务日志放在专用磁盘上。低 寻道时间对数据库磁盘非常重要。对与大表,你可以估计你将需要log(行数)/log(索引块长度/3*2/(键码长度 + 数据指针长度))+1次寻到才能找到一行。对于有500000行的表,索引Mediun int类型的列,需要log(500000) / log(1024/3*2/(3 + 2))+1=4次寻道。上述索引需要500000*7*3/2=5.2M的空间。实际上,大多数块将被缓存,所以大概只需要1-2次寻道。然而对于写入(如上),你将需要4次寻道请求来找到在哪里存放新键码,而且一般要2次寻道来更新索引并写入一行。对于非常大的数据库,你的应用将受到磁盘寻道速度的限制,随着数据量的增加呈N log N数据级递增。将数据库和表分在不同的磁盘上。在MySQL中,你可以为此而使用符号链接。条列磁盘(RAID 0)将提高读和写的吞吐量。带镜像的条列(RAID 0+1)将更安全并提高读取的吞吐量。写入的吞吐量将有所降低。不要对临时文件或可以很容易地重建的数据所在的磁盘使用镜像或RAID(除了RAID 0)。在Linux上,在引导时对磁盘使用命令hdparm -m16 -d1以启用同时读写多个扇区和DMA功能。这可以将响应时间提高5~50%。在Linux上,用async (默认)和noatime挂载磁盘(mount)。对于某些特定应用,可以对某些特定表使用内存磁盘,但通常不需要。 ——————————————————————————– 四、优化操作系统 不要交换区。如果内存不足,增加更多的内存或配置你的系统使用较少内存。不要使用NFS磁盘(会有NFS锁定的问题)。增加系统和MySQL服务器的打开文件数量。(在safe_mysqld脚本中加入ulimit -n #)。增加系统的进程和线程数量。如果你有相对较少的大表,告诉文件系统不要将文件打碎在不同的磁道上(Solaris)。使用支持大文件的文件系统(Solaris)。选择使用哪种文件系统。在Linux上的Reiserfs对于打开、读写都非常快。文件检查只需几秒种。 ——————————————————————————– 五、选择应用编程接口 PERL可在不同的操作系统和数据库之间移植。适宜快速原型。应该使用DBI/DBD接口。PHP比PERL易学。使用比PERL少的资源。通过升级到PHP4可以获得更快的速度。CMySQL的原生接口。较快并赋予更多的控制。低层,所以必须付出更多。C++较高层次,给你更多的时间来编写应用。仍在开发中ODBC运行在Windows和Unix上。几乎可在不同的SQL服务器间移植。较慢。MyODBC只是简单的直通驱动程序,比用原生接口慢19%。有很多方法做同样的事。很难像很多ODBC驱动程序那样运行,在不同的领域还有不同的错误。问题成堆。Microsoft偶尔还会改变接口。不明朗的未来。(Microsoft更推崇OLE而非ODBC)ODBC运行在Windows和Unix上。几乎可在不同的SQL服务器间移植。较慢。MyODBC只是简单的直通驱动程序,比用原生接口慢19%。有很多方法做同样的事。很难像很多ODBC驱动程序那样运行,在不同的领域还有不同的错误。问题成堆。Microsoft偶尔还会改变接口。不明朗的未来。(Microsoft更推崇OLE而非ODBC)JDBC理论上可在不同的操作系统何时据库间移植。可以运行在web客户端。Python和其他可能不错,可我们不用它们。 ——————————————————————————– 六、优化应用 应该集中精力解决问题。在编写应用时,应该决定什么是最重要的:速度操作系统间的可移植性SQL服务器间的可移植性使用持续的连接。.缓存应用中的数据以减少SQL服务器的负载。不要查询应用中不需要的列。不要使用SELECT [...]
作者:Fenng | English Version 【可以任意转载, 转载时请务必以超链接形式标明文章原始出处和作者信息及本声明】网址:http://www.dbanotes.net/web/flickr_web_tech.html Cal Henderson 是大名鼎鼎的 Flickr 网站的开发者之一.在一篇名为 Serving JavaScript Fast 的文章中,他介绍了用于 Flickr 站点应用优化的技巧,读罢感觉获益良多."嚼一下别人的馍",概括一下该文的主要内容. Flickr 是 Web 2.0 的代表站点。面对的网络问题除了一般 Web 站点都会有的内容优化之外, 还有必须要灵活处理 JavaScript 与 CSS 的频繁变化后部署分发带来的复杂性。 设定文件大小的策略 首先面临的一个问题是把所有的 JavaScript 与 CSS 放到一个文件中好呢,还是分割成多个文件 ? 从减少网络请求的角度上考虑, 前者更好,后者差。但是从并行的角度考虑, IE 与 Firefox 默认情况下都只能同时从一个域请求两个资源. 这会在很多情况下给用户带来不良的使用体验–必须所有的文件都下载完毕才可以看到像样的页面. Flickr 采用了折衷的办法–在保持文件数量尽可能少的情况下,把 JavaScript 与 CSS 分成多个子文件. 这在开发上带来了复杂性,但是对性能的收益是巨大的。 压缩的优化问题 毫无疑问,对站点内容进行压缩是一个比较常用的 Web 优化手段.但是并不一定都能达到理想的效果.原因在于 mod-gzip [...]
RSS
twitter