如果是的话,可以尝试把常用的网站域名和IP地址保存在DNS服务器里面,可以解决一部分问题。但是速度的问题不好说。有些网站一个域名对应多个CDN加速服务器的时候,他的IP地址是在CDN终端去判定的,如果你写死一个IP地址的话,那么当它压力大的时候你访问就是会慢
首先,在选择之后,先确定下自己网站的需求,规模大小什么的先确定好,后续选择的合适的配置就可以,不用太高配,合适的网站空间与流量、Linux *** 作系统和cPanel的安全加密增加了的服务器安全性、最重要还是服务器的稳定,稳定性强速度快的云服务器就是你要选择的服务器。像bluehost云服务器这块做的就是非常不错的,稳定性强,速度快,是非常多的站长选择的,现在上主机侦探通过专属链接加购更享超值~
数据和日志文件分开存放在不同磁盘上
数据文件和日志文件的 *** 作会产生大量的I/O 在可能的条件下 日志文件应该存放在一个与数据和索引所在的数据文件不同的硬盘上以分散I/O 同时还有利于数据库的灾难恢复
tempdb数据库单独存放在不同磁盘上
tempdb数据库是其他所有数据库都有可能使用的临时数据库 当使用select into 在没建立索引的列上执行Orderby时就会在tempdb数据库中产生临时表来存储中间数据 由于建立和填充临时表会严重降低系统性能 所以在尽可能的情况下应该为要排序的列建立索引 同时 tempdb数据库是为所有的用户和应用程序共享 所以如果一个用户占据了tempdb数据库的所有空间 则其他数据库将不能再使用 在可能的情况下 tempdb数据库应该单独放置在一个速度更快的硬盘或者RAID阵列上 分离tempdb数据库的I/O *** 作以加快性能 tempdb数据库应该有适当的容量 以满足用户的需要 应该允许tempdb数据库的空间自动增长 如果设置为不允许自动增长 当查询 *** 作建立了超过tempdb数据库容量的临时表时 *** 作将无法完成
适当设置tempdb数据库的增长幅度 过小的增长幅度会产生更多的外部碎片 会占用更多的资源
避免热点数据的发生
在SQLServer 之前 对于没有聚集索引的表(堆集表) 新插入的数据行总是放置在磁盘中表的物理结尾处 如果并发的用户很多 同时在对表执行插入或者更新数据的 *** 作 这将使得十分繁忙的表的末尾有可能产生数据热点 并发的I/O *** 作集中对少数页面进行 *** 作 将导致数据库性能的下降
在SQLServer中 新的数据行的物理存储空间的分配是通过PFS页面来进行的 PFS页面的管理算法将插入 *** 作进行分散来尽量避免产生数据热点
在设计应用系统和数据库时 要避免在自然增长的列上建立主键 这样有可能导致热点数据的发生
数据类型要少
在设计表时 尽可能少用数据类型 这样一个数据页面上可以保存最多的信息 数据页面就少 检索数据页面的I/O *** 作就少 所以效率会高
监控和整理空间碎片
文件空间的自动增长提高了自动管理性 但可能导致空间碎片 物理空间与数据的逻辑空间不再连续 定期的监控和空间碎片整理有利于提高I/O性能
使用主数据文件和次要数据文件
每个数据库的一个主数据文件属于主文件组 对于 GB左右规模的数据库 一个数据文件就够了 如果有次要数据文件 主数据文件中有管理次要数据文件的指针
采用多个数据文件时 主数据文件用于存储系统对象和表 次要数据文件用于存储用户数据和索引 在可能的情况下 主数据文件和次要数据文件可以单独存放在不同的磁盘上以分散I/O
如果采用多个数据文件 推荐主数据文件存储系统数据 次要数据文件存放用户数据和索引 这样会有助于提高I/O性能
利用文件组改善性能
在大型数据库系统中 可以考虑建立文件组来管理数据文件 将表和索引通过存放在不同的物理磁盘上进行性能监控比较 最后得出优化的存储方案
重视自动增长和自动收缩可能导致的性能问题
数据库文件的自动增长和自动收缩功能对于小型数据库的管理十分有用 但可能导致大型数据库的性能问题 因为文件的自然增长的同时会导致存储碎片的发生 当文件空间变大时 新分配的空间不一定和原来的空间连续 当文件空间收缩时 释放了部分空间 然而当文件又需要增长存储空间却不能利用原先释放的空间 也会导致碎片的发生
分离系统数据和用户数据
将系统数据库和用户数据库分开存放在不同的物理磁盘上有助于改善I/O性能 有助于数据库备份和恢复
优化索引设计
索引的设计对数据库的性能十分重要 具体不再阐述 可参见本博相关文章
定期更新统计信息
SQLServer默认使用基于代价的优化 所以统计信息的及时更新对于查询优化十分重要
定期的一致性检查
lishixinzhi/Article/program/SQLServer/201311/224341、静态文件优化
网站的静态文件一般有两种:第一种是网站的 CSS,Javascript 和一些主题的常用背景和按钮文件,这些如果网站不进行改版或者其他改动,基本上是不会修改的,第二种是每天更新的网站内容中上传的或者附件,这些文件也是基本不会改动的。
解决好静态文件存储和加速,网站性能就首先能得到基本的保证了,WordPress 构建的网站和博客也是一样的。对于这些静态文件来说,最好的解决方案永远是使用 CDN 网络进行加速,这样服务器的压力将大大降低,因为访问页面只有当前页面是在自己服务器上,其他所有 JS CSS 都是从 CDN获取的。
2
服务器优化
优化好静态文件之后,就要开始对网站的动态内容进行优化,优化动态内容,首先要有一个稳定网络环境,稳定的主机供应商和服务器性能的优化。
选择一个靠谱的主机托管商,在国内这个很多时候让你抓狂,但是只要努力还是可以的。个人选择 BGP 或者多线机房,让全国用户访问都能有不错的速度,然后尽量选择独立的服务器,再不济,也得 VPS, :-) 因为你没有服务器的 Root 权限很多东西是无法进行的(个人博客可以考虑选择我爱水煮鱼目前使用的 Media Temple 这类的 VPS 主机),当然你也可以找我合租,速度肯定非常强悍。
WordPress 缓存机制和如何缓存
要彻底明白和搞懂 WordPress 性能优化,首先要理解 WordPress 缓存机制,WordPress 默认是一种叫做 WordPress Object Cache 的对象缓存机制,它是把需要缓存的内容按照 Key-Value 这样的模式进行缓存(和 No-SQL 的 key-value 的有点类似),当然它还支持按照 Group 来划分和避免缓存的内容冲突。
所以最基础的 WordPress 缓存插件就是,把 WordPress 产生的 Key-Value 存起来,如果是使用 Memcached,就是存到内存,如果使用 Flie 就是存到硬盘中,当然高级的 WordPress 插件还能做更多,比如 WP Super Cache把整个页面缓存到硬盘中,下次直接访问静态的 HTML 文件,让服务器直接绕过 PHP,节约 CPU 时间。 Batcache 会把整个页面当做一个对象存到内存里面。
App每日推送 由于注册用户 *** 作比较频繁,不适合 WP Super Cache 这样的静态缓存,对硬盘读写太多,讨论区又无法缓存,我们使用 Memcached 和 Batcache 搭配的内存缓存模式:
对于已登陆的用户,Memcached 会把 WordPress 的对象存到内存里面,服务器的内存足够大,读取和存储速度也够快,并且内存缓存命中率也大于 94%。另外我们 WordPress 程序经过优化,每个页面的查询一般在 2 条左右,所以整个网站效率很高。
WordPress 程序优化
WordPress 程序优化是基于 WordPress Object Cache 的机制对 WordPress 插件和主题进行优化,主要经验有以下几点:
只使用必须的 WordPress 插件,安装太多的 WordPress 插件很容易引起性能问题。从正规站点下载 WordPress 主题,这样下载的主题才能保证质量和安全。WordPress 主题和插件尽量使用模板函数,因为 WordPress 模板函数如果可能都已经做好了 WordPress Object Cache。比如 get_the_terms 和 wp_get_object_terms 这两个函数,功能基本一样,但是 get_the_terms 直接从对象缓存中取数据,无查询,而 wp_get_object_terms 每次都从数据库中取数据。WordPress 插件和主题如果一定要直接查询数据库,请做好 Object Cache,将查询的结果使用 wp_cache_set 存到 Object Cache 中,下次直接使用 wp_cache_get 获取。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)