优化

magento的网站实在是太慢了，想了好多办法，参考了好多资料，做了很多测试，总结一下大概的步骤如下 （继续） ： １、压缩js,css代码，如果有必要把所有的css,js分别综合到一个文件中，并压缩，缓存 ２、清除magento模板中不必要的注释，为所使用到的图片瘦身 ３、 优化magento代码，这个步骤工作量大，但可能是效果显著的步骤，不过前提是你非常熟悉magento，彻底删除不用的模块，关闭没用的block， 清除无效，无用的xml（解析xml非常昂贵的），在一个页面中尽量不要大量调用magento的image resize功能，非常消耗内存，除非你自己优化代码。 ４、mysql配置优化，充分发挥你的硬件资源，下面的数值要根据你的配置调整 key_buffer_size = 512M max_allowed_packet = 64M table_cache = 512 sort_buffer_size = 4M net_buffer_length = 8K read_buffer_size = 4M read_rnd_buffer_size = 2M myisam_sort_buffer_size = 64M tmp_table_size = 128M query_cache_size = 96M query_cache_type = 1 thread_cache

关于io调优 在海量数据的情况下，数据库的性能问题有80%以上和IO有关，因此I/O优化是贯穿海量数据库管理全过程的重要工作。 I/O优化牵涉的面比较广，现在就从Oracle 数据库优化的一些主要方面详细阐述一下。在海量数据库环境下，Oracle数据库优化 面临的最重要的任务是I/O优化，因为绝大多数大型数据库都或多或少存在I/O性能问题。 数据库的I/O性能涉及面十分广，因此I/O性能优化也是ORACLE数据库优化工作中最复杂的工作。进行I/O性能优化，基本的步骤是 这样的: 采集系统数据，定位I/O性能问题； 分析并制订解决方案； 调整系统，解决问题； 评估优化结果。 优化ORACLE数据库的I/O性能，不能简单地从I/O入手，需要遵循数据库优化工作的基本原则。首先数据库优化的目的是提高系统的 整体处理能力，提高事务响应速度。所有的优化工作都需要围绕这个目的来进行。数据库性能优化的手段有两个方面，一是减少处理 时间，二是减少等待事件。减少处理时间要求应用编写得高效合理。减少等待时间要求系统的各种资源合理分配，不出现任何瓶颈。 数据库使用的系统资源包括CPU、内存、存储和网络。数据库优化的目的是合理分配这些资源，确保任何一种资源都不出现瓶颈。 根据上述原则，Oracle数据库的I/O性能优化不能只通过重新组合系统资源来达到提升数据库总体性能（包括I/O性能）的目的。 另一个方面

这里的原则 只是针对mysql数据库，其他的数据库 某些是殊途同归，某些还是存在差异。我总结的也是mysql普遍的规则，对于某些特殊情况得特殊对待。在构造sql语句的时候养成良好的习惯 原则1、仅列出需要查询的字段，这对速度不会明显的影响，主要是考虑节省应用程序服务器的内存。 原来语句： select * from admin 优化为： select admin_id,admin_name,admin_password from admin 原则2、尽量避免在列上做运算，这样导致索引失效 原语句： select * from admin where year(admin_time)>2014 优化为： select * from admin where admin_time> '2014-01-01' 原则3、使用JOIN 时候，应该用小的结果驱动大的结果（left join 左边表结果尽量小 如果有条件应该放到左边先处理，right join 同理反向），同事尽量把牵涉到多表联合的查询拆分多个query(多个连表查询效率低，容易到之后锁表和阻塞) 原来语句 select * from admin left join log on admin.admin_id = log.admin_id where log.admin_id>10 优化为： select * from

昨天偶遇自然计算这个词，原来之前了解的启发式优化算法都属于自然计算的范畴，因次顺藤摸瓜又搜索了一把，发现它与人工智能关系非常密切。 1、自然计算 自然计算（Nature Inspired Computation），是指以自然界包括生命、生物及生 态系统，物理与化学，经济以及社会文化系统等，特别是 生物体的功能、特点和作用机理为基础，研究其中所蕴 含的丰富的信息处理机制，抽取相应的计算模型，设计相应的算法，研制革新计算系统，并在各相关领域加以 应用。从自然计算要素角度看，每种自然计算方法都对 应一种实际的启发源，要将启发源中所包含的内在的特殊规律，如生物进化规律、离子进出细胞膜的规律等，利用数学或逻辑符号建模描述成一种特殊计算过程；而从其启发源的属性来分，又 包括了自然界全部的物质（物理和化学）、生命（生命系统、生物群和生态系统等）和文化（社会、文化、语言以及情感等）三个层次 。 “进化计算”这一 术语 １９９０年代初才被提出，它是模拟生物进化过程中 的自然选择法则和信息遗传机制等技术或算法的总称生命系统模拟计算是对自然界生命体或系统的各 种机制进行抽象和模拟，并用于提出智能计算方法的 一个多主题松散连接的研究领域，其理论构建于生物 学、计算机及数学基础上．此领域包含了对从生物分子 到细胞到功能（器官）系统再到生命体不同层次上的生 命智能机制的模拟．生命系统模拟计算的层次模型

一、Android性能优化的方面 针对Android的性能优化，主要有以下几个有效的优化方法： 1.布局优化 2.绘制优化 3.内存泄漏优化 4.响应速度优化 5.ListView/RecycleView及Bitmap优化 6.线程优化 7.其他性能优化的建议 下面我们具体来介绍关于以上这几个方面优化的具体思路及解决方案。 二、布局优化 关于布局优化的思想很简单，就是尽量减少布局文件的层级。这个道理很浅显，布局中的层级少了，就意味着Android绘制时的工作量少了，那么程序的性能自然就提高了。 如何进行布局优化？ ①删除布局中无用的控件和层次，其次有选择地使用性能比较低的ViewGroup。 关于有选择地使用性能比较低的ViewGroup,这就需要我们开发就实际灵活选择了。 例如：如果布局中既可以使用LinearLayout也可以使用RelativeLayout，那么就采用LinearLayout，这是因为RelativeLayout的功能比较复杂，它的布局过程需要花费更多的CPU时间。FrameLayout和LinearLayout一样都是一种简单高效的ViewGroup，因此可以考虑使用它们，但是 很多时候单纯通过一个LinearLayout或者FrameLayout无法实现产品效果，需要通过嵌套的方式来完成。这种情况下还是建议采用RelativeLayout

项目遇到一个MySQL查询特别慢的语句： SELECT * FROM ( SELECT DISTINCT t.vc_date, t.c_bankno, t.vc_bankacco, t.vc_moneytype, t.en_totalbala FROM tbankaccobala t WHERE 1 = 1 AND t.id IN ( -- 这个查询需要3s: -- SELECT SUBSTRING_INDEX(GROUP_CONCAT(id ORDER BY d_importtime DESC), ',', 1) -- FROM tbankaccobala -- GROUP BY vc_bankacco -- 但改成下面这样只要0.006s: SELECT hhhh from( SELECT SUBSTRING_INDEX(GROUP_CONCAT(id ORDER BY d_importtime DESC), ',', 1) as hhhh FROM tbankaccobala GROUP BY vc_bankacco ) as sbstr -- 对IN的子查询做二次查询，或者把IN改为JOIN都可以解决IN速度奇慢的问题 ) ) t WHERE 1 = 1 上面语句空行处省略了一系列的其他表和 INNER JOIN 语句。 原语句导致前端页面10秒左右才有响应

记忆得不太清楚了，不过一些基本问过的题目还是记得住的，就写一点吧。 maven的使用情况问一点。 snapshot和release版本的区别？ maven的生命周期有了解过吗？ 如何把自己写的架包推送到私服上？maven有一个deployed命令 maven有一个mirrors对吧，配置多个镜像的时候，多个镜像之间是怎么产生作用的？互相之间的作用是怎样的？调用顺序是。 如果有冲突会怎样？mirror本身是排除冲突的，我说的是你使用的哪一个插件的冲突，你配置的都是centre只会取一个。 mirror里面有一个mirror of 标签，就是中心镜像，只会取这里的。 项目的依赖，本地，远程，私服顺序应该是怎样的，（本地，私服，远程吧) java的内存模型了解过吗？ 堆跟栈分别存储的内容是什么？ 方法名是存在于哪里？ public void 名字() 这个名字存在于哪里 堆里面的结构了解吗？内存垃圾回收的过程了解吗? JVM最大的标准是什么？最小1/16的内存 最大1/4的内存 怎么修改java进程起的内存，控制他的范围大小？ 线程的一些问题？ 你可以说出几种线程安全的类型？ hashtable？stringbuffer？ConcurrentHashMap，vector。 我们为什么需要线程安全？ 乐观锁，悲观锁的概念？ 乐观锁局部操作的范围内，悲观锁首先觉得所有都可能出现线程安全问题。

导读 自从2015年以来，中国直播行业进入了高速发展的道路，巨额资本加持直播行业也使得直播行业进入了快车道，而移动直播则是个中翘楚。 引言 当前直播已经不是国内的私事，海外的人群也积极主动的加入国内的大联欢中。然而，由于长距跨国网络的链路质量问题，海外直播经常出现卡顿、传输失败等问题。面对着这高速发展的行业，越来越多的直播场景也挑战这直播背后的技术实现。 网易视频云将使用大数据技术对海量海外链路数据进行分析，并针对海外节点配置大量源站、拉设专线，多级调度等手段来解决这些瓶颈，为用户提供更好的服务质量。 简介 传统直播链路一共分为三块： ◆当主播通过移动端设备采集摄像头、麦克风数据，并进行相应的音视频编解码，网络传输协议的封装后，会先将音视频数据发送到CDN的源站服务器上，这里称为第一公里。 ◆当源站服务器收到数据后，需要与所有边缘节点共享自己所收到的内容，这里称为中间一公里。 ◆当观众加入主播的房间后，会向CDN的边缘节点发起请求，边缘节点会将其从源站服务器收到的消息转发给观众，这里称为最后一公里。 这三公里构成了整体CDN网络的传输，通过这三公里，间接的连通了主播与观众，即使主播和观众相距甚远，但是观众收看的直播质量并不会随着这距离而越变越差。 最后一公里解决了不同观众的接入问题，不同的边缘节点的分布会使不同的观众在其各自的网络环境(如不同运营商，不同地域，不同的带宽

MySQL 通过 慢查询日志 定位那些执行效率较低的SQL 语句，用--log-slow-queries[=file_name]选项启动时，mysqld 会写一个包含所有执行时间超过long_query_time 秒的SQL语句的日志文件，通过查看这个日志文件定位效率较低的SQL 。 慢查询日志在查询结束以后才记录，所以在应用反映执行效率出现问题的时候查询慢查询日志并不能定位问题，可以使用show processlist命令查看当前MySQL在进行的线程，包括线程的状态、是否锁表等，可以实时地查看SQL 的执行情况，同时对一些锁表操作进行优化。 下面我们举例说明一下，如何通过慢查询日志定位执行效率低的SQL 语句： 开启慢查询日志，配置样例: [mysqld] log-slow-queries 在my.cnf 配置文件中增加上述配置项并重启mysql服务，这时mysql慢查询功能生效。慢查询日志将写入参数DATADIR（数据目录）指定的路径下，默认文件名是host_name-slow.log 。 和错误日志、查询日志一样，慢查询日志记录的格式也是纯文本，可以被直接读取。下例中演示了慢查询日志的设置和读取过程。 首先查询一下 long_query_time 的值 。 mysql> show variables like 'long%'; +-----------------+----

在 web 应用中 , 提倡 sql 简单 , 避免复杂度。所以在我们公司的应用中看不到 jon, 子查询等语句的存在 , 所以间接 GROUP BY 与 索引的使用占据大多数 , 其实很多技巧 , 别人都是总结过的 , 仔细分析 , 仔细学习别人的经验才是正道 . 而不可浮躁 , 凭经验主义 . 满足 GROUP BY 子句的最一般的方法是扫描整个表并创建一个新的临时表，表中每个组的所有行应为连续的，然后使用该临时表来找到组并应用累积函数 ( 如 果有 ) 。 ( 用通俗的语言就是，建立一个临时表。然后利用 mysql 内部算法。算出来结果 ) 在某些情况中， MySQL 能够做得更好，通过索引访问而不用创建临时表。 （其实就是因为临时表的东西，我们才应该优化。） 一般 GROUP BY 优化分为 2 种优化方式： 1 。松散索引扫描 2, 。紧凑索引扫描 何为松散索引扫描： 其实就是 : 通过该访问方法， MySQL 使用某些关键字排序的索引类型的 属性。该属性允许使用 索引中的查找组而不需要考虑满足所有 WHERE 条件的索引中的所有关键字。既然该访问方法只考虑索引中的关键字的一小 部分，它被称为松散索引列表。(官方语言就是精辟) 例如： explain select TeamID from competeinfo where TeamID >10 group by