2020-07
17

为什么慢

By xrspook @ 8:53:45 归类于: 烂日记

要把9000多篇文章,准确来说,是9498篇文章生成一个静态网站实在太难了。如果只是几天,哪怕是几百天,放在哪里,用什么表达,都不成问题,无论是哪个编程语言都可以做到,只是快慢有所不同而已。到现在为止,我已经试过三种编程语言了,首先是go,然后新都javascript,最后是python。

go对应的是hugo,hugo的建站速度是最快的,但快的代价就是电脑的所有性能都会被用到极限。生成网站的时候,CPU飞到顶,内存一直往上走,最后当我看到内存到达90%以上,CPU的使用率反而下降,说明已经到顶了。因为我在做建站服务器测试,那些虚拟的东西全部都放在内存里,显然,我8GB内存的小电脑没办法在某些模板之下,hold住这9000多篇东西,但并不是所有hugo的模板都做不到,有些简单的模板可以做到。另外一些,别说9000多,一两千,都很困难。具体反映出来的效果就是建站的时间很长,其次是内存封顶,结束时间遥遥无期。

第二快的是python。python是我的老熟人了。而生成静态网站,我用的是mkdocs。这是一个python脚本,但实际上脚本自己又调用了很多东西。所以你以为你只是装一个脚本就完事,但实际上你得连串装一堆脚本。只有几个markdown文件的时候,mkdocs建站是很快的,但没到达hugo那种秒杀的地步,但是就建站构成来说最简单的。初始化以后,会自动生成了一个配置文件和一个文件夹,你把markdown文件放到文件夹,然后建站,就可以看到网站的雏形,虽然那个效果肯定不是你想要的。配置文件只有一个,所以也没什么好让你发挥的地方。正是因为够简单,所以我觉得,对那些纯粹写作的人来说,而且,是纯粹写书的人来说,mkdocs这个东西要比hugo实在。但其中一个不友好的地方是mkdocs自带的搜索对中文不友好。搜索英文的时候杠杠的,但是中文就无能为力。如果丢进去mkdocs的文件非常多,到达几百几千的时候。你会很崩溃,跟hugo不一样,mkdocs的CPU的使用率永远只耗尽我其中一个CPU,所以CPU的使用率永远只是25%,至于内存,貌似我一直都没有看到变化有多大。生成一个几页的网站,需要几秒,生成一个200多页的网站,需要十几秒。但是生成一个2000多页的网站,却需要1000多秒。为什么会有这种指数式的增长呢?我觉得跟他们的搜索索引有关。总的来说我觉得gitbook和mkdocs的思路类似。他们会建立一个json文件。而那个东西我感觉就像是一个字典。之所以能自带站内搜索,就是因为他们建立了这个东西。读取写入其它文件,再怎么慢,也有个限度,而且是匀速的,但是如果要不断的增加字典内容,把新的文件内容全部写入到json里,然后存起来,这就很变态。思路很简单,但执行起来的时候相当费劲。

其中一个让其更加费劲的地方在于,但markdown文件非常多,就肯定有一个不断打开文件关闭文件的操作,还得递归某个文件夹里面的所有东西,想想都知道这有多累。但如果有个大文件,全部都已经结合在一起的话,就没有这个烦恼。之所以我有这种感觉,是因为之前我写了一个脚本,专门用来输出9498篇文章的标题与文件名,作用是造一个目录。当时我没有把脚本输出文件的代码缩进,结果仅仅输出目录,居然需要20多秒。目录很小,但是运行时间却跟我把全部内容都输出一样过。昨天我才发现缩进的问题,那就意味着每次增加内容,文件都打开写一遍。这就意味着那个文件被反复的打开关闭9000多次。紧紧减少一个缩进,等于把写入的次数从9000多变成1,于是那个运行时间就缩短为了6秒。读取一个二十几MB的XML文件并输出目录仅仅需要6秒。可想而知,如果不是频繁打开关闭9000多个markdown文件,而是直接用完整的一个大XML文件生成json,速度会相当快。那不就是跟字典类似的东西吗,简单到没朋友。如果我不想进行全文搜索,我只需要进行标题搜索,事情会变得更简单。简单到跟我生成那个目录没啥区别。

经过了这一番折腾以后,让我明白到明细数据与汇总数据使用起来真的很不一样,虽然就总量来说,二者是等价的。

接下来,或许,我真的会像网友所说,自己写一个脚本,把已经进行wordpress标准格式化的XML转为一个静态网站。

天下大势,分久必合,合久必分。这次我算是深切体会到了。

© 2004 - 2024 我的天 | Theme by xrspook | Power by WordPress