案例研究:光年日志分析工具_SEO网站优化有哪些工具

　　案例研究:光年日志分析工具_SEO网站优化有哪些工具

　　SEO网站优化有哪些工具？作为一个网站优化器，网站优化工具肯定是必不可少的，优化工具可以提高我们的工作效率，所以网站优化工具的利用率很重要，那么SEO有哪些工具呢？ 网站 优化？下面小编将为大家介绍网站的优化工具。

　　1.百度站长工具

　　百度站长工具现在越来越好，增加了多种功能，如网站索引量、准确率、服务器状态、关键词呈现和点击状态，而且站长还可以提交各种数据直接通过这个工具去百度，比如提交死链接，提交网站的修改，提交和robots文件等等。还有比较具体的，总之所有站长都要熟练使用。

　　2.Chinaz站长工具

　　相信所有站长都应该非常了解这个工具。功能非常强大，几乎囊括了站长日常的所有优化操作。比如可以查询网站，及时监控网站的大概流量，看网站的优化状态等。另外还有更多的功能，比如查询网站中的收录、反向链接、友情链接等，这里不再详述。这是所有站长必须熟练使用的工具。

　　3. 网站日志分析工具

　　这里特别推荐的是光年测井分析工具。使用这个工具，可以清晰的分析自己的网站蜘蛛爬取状态，比如蜘蛛是否经常爬那些无用的页面，尤其是可以看到蜘蛛返回http状态码、停留时间、爬取页面等。通过这些，你可以在网站这个网站上清楚的看到有没有问题。

　　以上就是小编分享的SEO网站优化所需要的工具，而且不止这些优化工具，但是这些都是比较常用的工具。只有善用这些优化工具，才能提高工作效率。会大大提高。

　　解决方案:关于PHP批量采集----采集小说站有感

　　概述：我一直在帮助周的小说采集。一开始是直接从其他网站页面写到采集，后来慢慢改成采集别人提供的API。

　　环境：CENTOS+NGINX+PHP5.2.17。基于杰奇新颖的管理系统。

　　我直接采集other网站页面的时候，主要是改了JIEQI自带的采集系统。增加了判断章节顺序的功能，以及其他修改，给我留下了深刻的印象。“BUG”（是的，还有什么具体的事情来了，我现在差点忘记了，我已经做了很久了）。这一次，我感受更深的是采集API。

　　背景：采集 几十个新站点的API（目前有5个，预计40个、50个）

　　设计：共享一个显示页面和单独的逻辑。批处理 采集，单个 采集。

　　最后一张图：

　　其中，两个实体是我自己根据需要的信息定义的。之所以指定这个实体（或接口），主要是因为各个API给出的信息不同，统一后才能操作。

　　单个 采集 VS 多个 采集

　　单篇采集比较简单，想写什么就写什么，问题不大。

　　还有很多批次采集，这次写了四个版本。

　　V1：所有操作都写在同一个PHP进程中。

　　优点：逻辑简单，易于实现。

　　缺点：PHP进程容易庞大，容易挂。

　　问题：最多只能设置5篇文章，看不到采集的进程。

　　V2：用file_get_contents分离所有操作，遍历访问。

　　优点：类似于“异步”采集，所有操作都分离到各个进程中，单个进程不容易挂掉。高效率。

　　缺点：采集进程会生成N多个PHP进程，NGINX会出现504等错误。

　　问题：如前所述，如果一部作品有很多章节，短时间内（0.1S以内）产生数百个HTTP请求，NGINX出现问题，服务器无法承受。

　　改进：在 PHP 中添加 sleep 会使 NGINX 不稳定，并且会大量消耗资源。file_get_contents 也偶尔会出现错误。

　　V3：结合V1和V2，使用JS进行计时。

　　思路：使用iframe，定时刷新采集的各个页面（V2），根据页面返回信息，进行下一步。即：循环设置iframe的SRC。

　　优点：分散采集集中时对服务器的压力，章节按顺序存放在库中。

　　缺点：采集的间隔时间不是很容易设置。即使是根据iframe的返回值来判断，也应该多加一些时间（定期刷新父页面，定期抓取iframe的数据来判断）。

　　问题：setTimeout存在各种问题，会出现不可控的情况。因为 JS 也是单线程的。setInertval 也是如此。

　　V4：结合前面三个，主要改进是在V3的基础上，再次分离出来。

　　思路：与其循环设置iframe的SRC，不如创建N多个iframe。

　　优点：可以方便的控制时间（即：多少个S间隔，打开一个新的iframe）。

　　缺点：如果前几章的操作比较慢（即：比如第一章卡住了，2S还没有连接到采集的PHP URL。而第二章，0.5S之后，有已经开始，并已连接，则第二章将存储在第一章之前），这涉及到章节的顺序。还有，如上，第一章已经连接，但是运行很慢，2S可以搞定；而第二章，字数少（或其他原因），1S搞定，问题同上。

　　问题：正如上面提到的缺点，还有一个问题需要注意。由于某些字段，必须在 采集 完成后更新表。SO，采用一种方法：就是子页面的JS，调用父页面的JS的方法，在父页面中设置一个iframe（类似ajax或者脚本）来访问修改后的URL工作。

　　实用：果然，实用的时候，缺点造成的问题就已经出现了。

　　更正：章节排序字段与章节信息相同，放入数组，同步更新。这样，即使第二章先入库，它的顺序仍然是2。第一章之后，顺序是1。在显示的时候，第一章仍然在前面。问题解决了。

　　每个 采集 站的 API 和模板是分开的。这样做的好处是界面统一，其他人可以自由发挥。好几次周同学都跟我说要做这个东西，但是想想，确实，刚开始做的时候，并没有想的那么仔细，做的还不够好。看来我还是没有足够的经验。

　　当然对于采集，推荐使用.net制作EXE。我跟周同学提过，他觉得比较麻烦，也懒得重来了。现在这个版本已经够用了，符合要求。仍有待优化的地方继续优化。

　　这抛砖引玉，期待大牛们的指点。