优化

原创博客，欢迎转载，转载请注明： http://my.oschina.net/BreathL/blog/62519 最近研究Mahout比较多，特别是里面协同过滤算法；于是把协同过滤算法的这个实现思路与数据流程，总结了一下，以便以后对系统做优化时，有个清晰的思路，这样才能知道该如何优化且优化后数据亦能正确。 推荐中的协同过滤算法简单说明下： 首先，通过分析用户的偏好行为，来挖掘出里面物品与物品、或人与人之间的关联。 其次，通过对这些关联的关系做一定的运算，得出人与物品间喜欢程度的猜测，即推荐值。 最后，将推荐值高的物品推送给特定的人，以完成一次推荐。 这里只是笼统的介绍下，方便下边的理解，IBM的一篇博客对其原理讲解得浅显易懂，同时也很详细 《 深入推荐引擎相关算法 - 协同过滤》 ，我这里就不细讲了。 协同过滤算法大致可分为两类，基于物品的与基于用户的；区分很简单，根据上面的逻辑，若你挖掘的关系是物品与物品间的，就是基于物品的协同过滤算法，若你挖掘的关系是用户与用户间的，就是基于用户的协同过滤算法；由于它们实现是有所不同，所以我分开整理，先来看看基于物品的协同过滤实现，我自己画了一幅图： 我通过数字的顺序，来标示数据变化的方向（由小到大）；下面分析下每一个步骤的功能以及实现。 首先，说明下两个大的数据源， 用户偏好数据 ：UserID、ItemID、Preference

温馨提示：本篇内容均来自网上，本人只做了稍微处理，未进行细致研究，仅当做以后不备之需，如若你喜欢可尽情转走。 一、问题的提出 在应用系统开发初期，由于开发数据库数据比较少，对于查询SQL语句，复杂视图的的编写等体会不出SQL语句各种写法的性能优劣，但是如果将应用系统提交实际应用后，随着数据库中数据的增加，系统的响应速度就成为目前系统需要解决的最主要的问题之一。系统优化中一个很重要的方面就是SQL语句的优化。对于海量数据，劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍，可见对于一个系统不是简单地能实现其功能就可，而是要写出高质量的SQL语句，提高系统的可用性。 在多数情况下，Oracle使用索引来更快地遍历表，优化器主要根据定义的索引来提高性能 。但是，如果在SQL语句的where子句中写的SQL代码不合理，就会 造成优化器删去索引而使用全表扫描 ，一般就这种SQL语句就是所谓的劣质SQL语句。在编写SQL语句时我们应清楚优化器根据何种原则来删除索引，这有助于写出高性能的SQL语句。 二、SQL语句编写注意问题 下面就某些SQL语句的where子句编写中需要注意的问题作详细介绍。在这些where子句中，即使某些列存在索引，但是由于编写了劣质的SQL，系统在运行该SQL语句时也不能使用该索引，而同样使用全表扫描，这就造成了响应速度的极大降低。 1. 操作符优化 (a) IN

前言 本人在这家公司已经三年多了，这款三年多我一直在做的APP也烂熟于心，APP也0到1到目前的500万的用户量；对于APP的功能来说也是比较全面的，用到的技术知识点也比较多吧，APP的优化也是一直在做的事情，而且APP性能的优化也不是一朝一夕的事情，在此离别之际，我将详细说明讲解一下我在三年里对APP性能优化方面做过的一些事，大家仁者见仁智者见智，也欢迎大家进群提供宝贵的意见和建议！ 这里我主要讲性能方面的优化，代码方面的优化或者说API包方面的优化请看我的另一篇博文： ? iOS-APP包的瘦身之旅（从116M到现在的36M的减肥之路） ? 基础优化 使用ARC，现在的iOS开发大家用的都是ARC，几乎没有人再去使用MRC了，使用ARC的好处就是不用再时时刻刻注意要释放创建的对象了；避免使用xib或者storyboard。 这里说一下xib和sb的缺点吧，如下： 1.占用API包比较大； 2.导致APP启动时间比较耗时，因为在APP启动main()以前需要加载他们； 3.加载速度比较慢； 4.后期的版本更新迭代维护时间成本比较高； 5.多人开发容易引起冲突。 列表图片优化 列表不论在哪一个APP中是使用最为广泛的一款控件了，在我的APP中也不例外，我们的APP只要功能列表类似于微信的朋友圈，图片有0~9张的形式还可以是视频文件，如下图： 先说一说图片吧，如果一个列表都是9张图片

tomcat 的Connector配置如下 <</span> Connector port ="8080" protocol ="HTTP/1.1" connectionTimeout ="20000" redirectPort ="8443" maxThreads ="800" acceptCount ="1000" /> 其中最后两个参数意义如下： maxThreads ：tomcat起动的最大线程数，即同时处理的任务个数，默认值为200 acceptCount ：当tomcat起动的线程数达到最大时，接受排队的请求个数，默认值为100 这两个值如何起作用，请看下面三种情况 情况1：接受一个请求，此时tomcat起动的线程数没有到达maxThreads，tomcat会起动一个线程来处理此请求。 情况2：接受一个请求，此时tomcat起动的线程数已经到达maxThreads，tomcat会把此请求放入等待队列，等待空闲线程。 情况3：接受一个请求，此时tomcat起动的线程数已经到达maxThreads，等待队列中的请求个数也达到了acceptCount，此时tomcat会直接拒绝此次请求，返回connection refused maxThreads如何配置 一般的服务器操作都包括量方面：1计算（主要消耗cpu），2等待（io、数据库等） 第一种极端情况

一期优化取得了显著的效果，从优化前的1.9s，现在稳定在1.5s，基本保持在达标线内 偶尔的抖动观察了下，与后端服务的稳定程度有关 但是感觉优化还是有提升的可能 这里有几个优化方向的思路 一 关于白屏 目前小程序采用了loading组件过度，但是，由于是资讯类的小程序，页面的内容严重依赖后端接口 如果后端服务不稳定，就像上图所见，很多时候是有波动的，所以对白屏的优化成为了下一个可以优化的点 白屏检测说明 白屏定义：用户触发页面打开后，间隔一定时间后仍然没有任何页面绘制，则认定为白屏。 白屏检测原理：从用户点击小程序入口开始计算时间，6s后进行截图分析。当截图为空白页面或只有背景色，则记为一次白屏。请注意：此统计规则在2019年9月6日发生变更，变更前为从小程序页面框架创建时开始计时。 白屏监控范围：仅针对小程序进入时的首个页面进行检测。 数据解读：白屏率 = 白屏发生PV / 小程序冷启动打开PV，开发者可以在小程序平台上看到自己小程序白屏率的数据情况。在上述检测机制下，无论小程序启动时出现异常还是页面加载过程较慢，6S时被监测到无内容展示，都会视为白屏。因此在进行白屏优化时，需要从两方面着手，一方面对页面异常问题进行排查，另一方面着重优化页面的性能。 白屏优化 排查异常 小程序白屏数据出现异常上涨时，可以从以下三个方面着手排查分析： 服务稳定性 小程序页面数据请求是否正常：

公司换成华为服务器后，新环境出现这个问题，一旦人多点 访问特别卡，刚开始很不爽 一通cnm，还是静下心来解决问题吧 后来找到来apache 优化配置多文章，配置后解决问题，持续观察中 如果apche访问量过大，将会导致页面打开迟缓，下载速度也降低，如果由于经费和环境问题，集群方案没有得以应用。可以通过对Apache2增加模块MPM来进行优化, 这里我选择线程型MPM加以优化： 开启mpm：在httpd.conf文件中去掉 Include conf/extra/httpd-mpm.conf 前面的“#”号（提示：如果没有此段代码可以新加。没有此文件httpd-mpm.conf可以新建，也可以直接加代码到） 优化配置： 服务器启动时建立的线程数 StartServers 200 空闲子进程的最小数量 MinSpareServers 100 空闲子进程的最大数量 MaxSpareServers 200 允许同时伺服的最大接入请求数量 MaxClients 800 每个子进程在其生存期内允许伺服的最大请求数量 MaxRequestsPerChild 3000 代码（前提是apache的工作模式是prefork）： <IfModule mpm_prefork_module> StartServers 200 MinSpareServers 100 MaxSpareServers 200

温馨提示：本篇内容均来自网上，本人只做了稍微处理，未进行细致研究，仅当做以后不备之需，如若你喜欢可尽情转走。 很多数据库系统性能不理想是因为系统没有经过整体优化，存在大量性能低下的SQL 语句。这类SQL语句性能不好的首要原因是缺乏高效的索引。没有索引除了导致语句本身运行速度慢外，更是导致大量的磁盘读写操作，使得整个系统性能都受之影响而变差。 解决这类系统的首要办法是优化这些没有索引或索引不够好的SQL语句。 一、创建索引的关键 优化SQL语句的关键是尽可能减少语句的logical reads。这里说的logical reads是指语句执行时需要访问的单位为8K的数据页总数。logical reads 越少，其需要的内存和CPU时间也就越少，语句执行速度就越快。不言而喻，索引的最大好处是它可以极大减少SQL语句的logical reads数目，从而极大减少语句的执行时间。 创建索引的关键是索引要能够大大减少语句的logical reads。一个索引好不好，主要看它减少的logical reads多不多。 运行set statistics io命令可以得到SQL语句的logical reads信息。 set statistics io on select au_id,au_lname ,au_fname from pubs..authors where au_lname =

减少文件搜索范围 （1）优化resolve.extensions配置 在导入语句没带文件后缀时，Webpack 会自动带上后缀后去尝试询问文件是否存在。 在配置 resolve.extensions 时你需要遵守以下几点，以做到尽可能的优化构建性能： l 后缀尝试列表要尽可能的小，不要把项目中不可能存在的情况写到后缀尝试列表中。 l 频率出现最高的文件后缀要优先放在最前面，以做到尽快的退出寻找过程。 l 在源码中写导入语句时，要尽可能的带上后缀，从而可以避免寻找过程。例如在你确定的情况下把 require('./data') 写成 require('./data.json') 。 （2）优化 resolve.modules 配置 resolve.modules 用于配置 Webpack 去哪些目录下寻找第三方模块。 resolve.modules 的默认值是 ['node_modules']，会采用向上递归搜索的方式查找 （3）优化resolve.alias配置 resolve.alias 配置项通过别名来把原导入路径映射成一个新的导入路径。 （4）缩小文件匹配范围 Include：需要处理的文件的位置 Exclude：排除掉不需要处理的文件的位置 2.设置noParse 防止 webpack 解析那些任何与给定正则表达式相匹配的文件。忽略的文件中不应该含有 import,

姓名 学号 周期计划安排 每周实际工作记录 自我打分 yh 062609 连接点的优化，内部衔接过渡精细 进一步学习了原型设计优化的细节 共同商议加上的连接点适宜实用，对整体的体验有很大的优化 91 lp 071324 优化页面设计，使其大气美观 对初始的登录和注册界面做了调整，将ps技术应用在原型设计上 做到美观、大方，不包含非法内容 88 wxh 092324 收集其他优秀的原型进行借鉴 进一步提升自己的产品 借阅其他优秀原型，取其精华应用在自己的产品上 90 xr 061409 寻找人员测试，优化用户体验 在同学们中找到随机的人员进行测试，对他们的问题进行解答 并根据其建议优化产品 95 来源： https://www.cnblogs.com/npc1158947015/p/11879271.html

在 ListView 的使用中，有时候还需要在里面加入按钮等控件，实现单独的操作。也就是说，这个 ListView 不再只是展示数据，也不仅仅是这一行要来处理用户的操作，而是里面的控件要获得用户的焦点。读者可以试试用 SimpleAdapter 添加一个按钮到 ListView 的条目中，会发现可以添加，但是却无法获得焦点，点击操作被 ListView 的 Item 所覆盖。这时候最方便的方法就是使用灵活的适配器 BaseAdapter 了。 ▲ 图 4-35 BaseAdapter 中的方法 使用 BaseAdapter 必须写一个类继承它，同时 BaseAdapter 是一个抽象类，继承它必须实现它的方法。 BaseAdapter 的灵活性就在于它要重写很多方法，看一下有哪些方法，如图 4-35 所示为继承自 BaseAdapter 的 SpeechListAdapter 所实现的方法，其中最重要的即为 getView() 方法。这些方法都有什么作用呢？我们通过分析 ListView 的原理来为读者解答。 当系统开始绘制 ListView 的时候，首先调用 getCount() 方法。得到它的返回值，即 ListView 的长度。然后系统调用 getView() 方法，根据这个长度逐一绘制 ListView 的每一行。也就是说，如果让 getCount() 返回 1