12306 这么大的 js 文件,怎么想的...

地址

文本

想想

流量

111 条回复 • 2016-10-11 17:59:18 +08:00

1 2

❮

❯

1

yuankui

2016-10-09 17:54:43 +08:00

不错啊，这个数据~

2

reus

2016-10-09 17:55:20 +08:00

1

train_list ，是车次信息吧？可以减轻服务器压力，其实算正路做法。
那些页游、 flash 之类的资源，比这大的也不少见，没啥的。

3

minbaby

2016-10-09 17:56:08 +08:00

好奇心害死猫。（ chrome 卡死了）

4

bridge45

OP

2016-10-09 17:59:15 +08:00

@reus 这还能减轻服务器压力么?如此大的带宽浪费,为什么不是类似级联方式的查询获得车次结果,将结果缓存下来

5

bridge45

OP

2016-10-09 18:00:43 +08:00

@minbaby 想想普通用户低配电脑或者手机访问,那不是直接挂的节奏

6

wolfan

2016-10-09 18:04:57 +08:00

LZ 小心铁总今年不卖回家的车票你哟~

7

chinawrj

2016-10-09 18:05:33 +08:00

@bridge45 你那样搞更复杂吧。搞个 CDN 加速单个 35M 文件多简单。

8

cheetah

2016-10-09 18:06:24 +08:00

@bridge45 静态文件通过 cdn 分发就可以了，是可以减轻应用服务器的压力的。

9

bridge45

OP

2016-10-09 18:09:33 +08:00

@chinawrj 我想写这代码的兄弟也是这样想的.... 然而也太对不起]上千万]用户的电脑和 [上千万]*[10M] 的带宽浪费了吧

10

bridge45

OP

2016-10-09 18:12:37 +08:00

@cheetah 可以分为多份静态文件,然后用户输入的时候去调取对应区间 CDN 的静态文件,用户内存和带宽都可以降低不少.

11

bridge45

OP

2016-10-09 18:13:12 +08:00

@wolfan 哈哈,今年过年不抢票

12

Arrowing

2016-10-09 18:15:22 +08:00

厉害了我的哥，加载了我 1.2min
然而并没开启 gzip 压缩 GG

@bridge45 你这个方法也可以，就是复杂了一些，做起来难免会有错漏

13

bridge45

OP

2016-10-09 18:19:04 +08:00

@Arrowing 哈哈,坐等官方优化吧... 太卡了我才去看一眼,原来是这样调用的

14

reus

2016-10-09 18:20:50 +08:00

1

@bridge45 从你的回复可以看出你并不是很懂技术，我想这种显而易见的事情，没什么值得讨论的。一个 gzip 后 4M 的资源，怎么就对不起电脑对不起带宽了呢？动态查询难道就不占带宽？动态查询还耗服务器资源。

15

bridge45

OP

2016-10-09 18:28:17 +08:00

@reus 简单个分法:分为 D,T,K,G 四种文件,用户输入第一个字母去加载对应 js 文件,当然还有其他分法...,就可以大为减少一些带宽和内存.我配置不错的台式机 chrome 卡爆了...

16

learnshare

2016-10-09 18:29:22 +08:00

查看文件详情，标签卡死了

17

tscat

2016-10-09 18:30:57 +08:00 via iPhone

4m 的文件根本不占带宽吧和图片之类的比起来

18

reus

2016-10-09 18:31:01 +08:00

@Arrowing 慢在浏览器渲染，实际最多几秒就下完了，解析也不到一秒。你是直接当文本打开来看的吧？

19

qqmishi

2016-10-09 18:34:21 +08:00 via Android

下载下来把我的 gedit 卡死了，，，

20

bugmenein

2016-10-09 18:35:01 +08:00

@reus 4M 不是所有人都是几秒就能下载完，大多数人可能要下十几秒到几十秒。

21

Sasasu

2016-10-09 18:35:51 +08:00 via Android

c++程序里经常有几十兆的表打在内存里， js 里打表怎么了嘛，况且还只能打表的东西。
电脑比你想象的更适合处理这种任务，你觉得卡是渲染的问题，我的手机只会尝试渲染前几百行，剩下的不管。秒开不卡

22

reus

2016-10-09 18:36:25 +08:00

@bridge45 我用 chrome 打开 https://kyfw.12306.cn/otn/queryTrainInfo/init ，占 500 几 M 内存，多是多一些，但也在可以接受的范围内。你可以换其他内核的浏览器试试， chrome 在某些平台某些版本内存泄漏挺严重的。

23

jhaohai

2016-10-09 18:37:09 +08:00 via iPhone

简单粗暴有效

24

bridge45

OP

2016-10-09 18:38:39 +08:00

@reus 嗯嗯用还是可以用的,只是感觉设计不是很合理,拿来讨论下.

25

reus

2016-10-09 18:39:53 +08:00

@bugmenein 我看了它的响应头，是用了 CDN 的，如果离节点近就快吧。 4M 几秒下载完，也就是一秒 1M 左右，我想大部分人的网络都能有这个水平的。

26

bridge45

OP

2016-10-09 18:40:13 +08:00

@Sasasu 嗯嗯只是感觉有点像:我只要查一个数据,你却将整个表数据返回给我.

27

bridge45

OP

2016-10-09 18:41:11 +08:00

@reus 我单开要 10 多秒,打开这个页面五秒左右.电信 100M 带宽.

28

reus

2016-10-09 18:44:36 +08:00

@bridge45 我单独打开显示文本要 30 秒，时间都消耗在渲染文本上了。打开购票页面是不用渲染出脚本的文本的。所以其实单开要多久并不重要

29

youxiachai

2016-10-09 18:46:19 +08:00

简单除暴省事....12306 为了省服务器资源..也是拼了...
简单来说.你电脑差,网络差,买毛线车票.....
好像确实这样..黄牛都是顶配电脑+网络...

30

xfspace

2016-10-09 18:46:40 +08:00 via Android

12306 的特殊性...没什么好说的。
外人评价怎么怎么垃圾，要这样写要这样拆，没考虑到其他因素。

31

youxiachai

2016-10-09 18:48:56 +08:00

@bridge45 其实,例如我可以忍受第一次慢点...而且..以后访问有缓存...也不会慢..
你的方案看上去很好..但是不符合人性..,在等我查的时候,才去下载.在这个过程中..就有了时间的消耗..而现在这个只是第一次加载慢点,以后查就很快了....
还是个人性的问题...

32

iTakeo

2016-10-09 18:54:12 +08:00 via iPhone

为什么我的手机秒开，一点不带卡的？

33

williamx

2016-10-09 18:58:47 +08:00

这种明显是要分级的。太懒了

34

ahkxhyl

2016-10-09 19:00:35 +08:00

1

国家应该再开个卖火车票的类似 12306 的没有竞争永远没有提升！价格始终不降

35

zhihaofans

2016-10-09 19:04:41 +08:00

NOTEPAD++卡住了。。。

36

ChiangDi

2016-10-09 19:06:41 +08:00 via Android

我手机 chrome 也秒开

37

scnace

2016-10-09 19:11:56 +08:00 via Android

和之前那个 SQL 的帖子有异工同曲之妙～

38

bridge45

OP

2016-10-09 19:14:26 +08:00

@youxiachai 哈哈服了

39

jasontse

2016-10-09 19:27:18 +08:00 via iPad

这一点都不节省资源好吧，简直是浪费带宽，有用没用的一起加载。

40

jeremaihloo

2016-10-09 19:29:34 +08:00 via Android

讲道理，我们都是秒开，其实文件和我们平时手机浏览一个网页的图片相比并不大，而且，你说你下载这东西时间长，我只能说你用的网络太垃圾，而且不能代表其他人网络和你一样差，我老家农村 4m 小水管都没问题，你现在用的网络该换换了（手动滑稽并爱抚一下题主）

41

mdzz

2016-10-09 19:34:39 +08:00

$ python
Python 2.7.12 (default, Jul 1 2016, 15:12:24)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import json
>>> with open('train_list.js') as fp:
... data = fp.read()
...
>>> js = json.loads(data.decode('utf-8')[16:])
>>> print len(js)
61
>>> print js.keys()
[u'2016-09-25', u'2016-08-30', u'2016-08-31', u'2016-09-13', u'2016-09-12', u'2016-09-11', u'2016-09-10', u'2016-09-17', u'2016-09-16', u'2016-09-15', u'2016-09-14', u'2016-09-30', u'2016-09-19', u'2016-09-18', u'2016-09-20', u'2016-09-21', u'2016-09-27', u'2016-10-19', u'2016-10-18', u'2016-10-15', u'2016-10-14', u'2016-10-17', u'2016-10-16', u'2016-10-11', u'2016-10-10', u'2016-10-13', u'2016-10-12', u'2016-10-08', u'2016-10-09', u'2016-10-06', u'2016-09-28', u'2016-09-29', u'2016-09-08', u'2016-09-09', u'2016-09-23', u'2016-10-07', u'2016-09-04', u'2016-09-05', u'2016-09-06', u'2016-09-07', u'2016-09-26', u'2016-09-01', u'2016-09-02', u'2016-09-03', u'2016-09-22', u'2016-09-24', u'2016-10-20', u'2016-10-21', u'2016-10-22', u'2016-10-23', u'2016-10-24', u'2016-10-25', u'2016-10-26', u'2016-10-27', u'2016-10-28', u'2016-10-29', u'2016-10-04', u'2016-10-05', u'2016-10-02', u'2016-10-03', u'2016-10-01']
>>>

wow, interesting

42

yangyaofei

2016-10-09 19:38:46 +08:00 via Android

@minbaby 表示 android chrome 不卡😂😂😂

43

youxiachai

2016-10-09 19:40:34 +08:00

@jasontse cdn 表示这点带宽小 case ....

44

adv007

2016-10-09 19:42:41 +08:00 via iPhone

这么大的 js 一般是不懂前端的工程师干的，此时先不用扯 CDN,gzip

45

yangyaofei

2016-10-09 19:43:33 +08:00 via Android

感觉挺好……第一次会比较慢，但是后面再请求应该都 200 吧，车票肯定来回刷，加上 cdn ，感觉很好。

46

jasontse

2016-10-09 19:45:17 +08:00 via iPad

@youxiachai 按照 12306 的流量级别，再加上春运时的尖峰流量，这是很大的开销。

47

hellojinjie

2016-10-09 19:57:33 +08:00

我们很多时候一张图片也要好几兆了啊， 4MiB 的文本下载很正常啊。

48

fqzz

2016-10-09 19:58:17 +08:00

react + webpack 打出来的 app ， gzip 后不一定比这小多少。

49

ChaosPark

2016-10-09 20:03:35 +08:00

这样做挺好，不然网络垃圾点的就更抢不到票了。

50

Totato5749

2016-10-09 20:12:11 +08:00

我很好奇的是， 12306 的那些程序猿都神龙见首不见尾，从来没在网上见过说自己是 12306 的， 12306 现在也不算是黑点吧，总比百度强吧

51

rocai185

2016-10-09 20:18:49 +08:00

@reus 兄弟，别代表大多数，大多数你还真不知道是多少 M 的

52

Tink

2016-10-09 20:22:29 +08:00

我惊了

53

Tink

2016-10-09 20:24:31 +08:00

这个东西还有点用啊

54

schezukNewTos

2016-10-09 21:27:05 +08:00

铁总又不需要频繁调图，一个月不带变一次的。
只需要堆 cdn 就能给数据库减负，挺合算的。
何况第二次访问直接返回 304 ， cdn 不耗流量。

如果手机用略吃亏，慢，费流量。

55

billwang

2016-10-09 22:08:38 +08:00

notepad++ 未响应
第一次打开那个网址等了十秒左右，后面打开就快一些，虽然我笔记本有些老了

56

SilentDepth

2016-10-09 22:43:10 +08:00

Chrome on Windows 点开，风扇开始转……囧

57

youxiachai

2016-10-09 22:48:59 +08:00 via iPad

@jasontse 嗯...目测是没怎么接触 cdn 的？ cdn 的前端缓存性能非常厉害........说实在的就算是峰值也就是开多几个地区的 cdn 而已，对于整个系统的开销 cdn 是最方便扩容的....这种只要堆机器的方法最省事了....

58

palytoxin

2016-10-09 22:54:57 +08:00

@qqmishi 大文件还是 vim

59

qqmishi

2016-10-09 22:58:51 +08:00 via Android

@palytoxin 改用 head 命令，然而我没预料到只有一行，，，

60

reus

2016-10-09 23:33:15 +08:00

2

说直接打开或者 notepad++打开慢的，根本就没搞明白吧，作为脚本运行时，它不需要渲染给你看，很快的。直接打开慢， notepad++打开慢，是因为需要渲染所有的文字。实际执行的时候，直接就执行 js 代码了，又不需要渲染，所以说直接打开或者 notepad++打开慢，毫无意义。

61

zhanglintc

2016-10-09 23:37:28 +08:00

@reus 我觉得大家想表达的是, notepad++打开慢说明文件大, 下载会很花时间的...

62

Shura

2016-10-09 23:37:39 +08:00 via Android

这个算是 js 打表吧，我感觉很正常啊，可能这个程序员搞过 acm

63

indooorsman

2016-10-09 23:42:12 +08:00 via Android

同意楼上，请打开页面在 chrome 控制台的网络里查看响应时间，直接打开文本慢并没有意义

64

indooorsman

2016-10-09 23:43:09 +08:00 via Android

楼上指的是 @reus

65

indooorsman

2016-10-09 23:45:03 +08:00 via Android

@zhanglintc 然而并不能说明，下载的时候是 gzip 后的文件，编辑器打开的时候可不是

66

isCyan

2016-10-10 00:36:17 +08:00

@fqzz 赞同， webpack 是恶魔，

67

mytsing520

2016-10-10 01:56:31 +08:00

这个文件，好像是铁路运行图

68

paulagent

2016-10-10 02:17:32 +08:00 via Android

这种垄断企业是不会考虑用户的

69

RqPS6rhmP3Nyn3Tm

2016-10-10 05:02:32 +08:00 via iPhone

用户太多，只能尽量省资源。不过铁总的后端和前端很难想象他们是一个研究所出的

70

500miles

2016-10-10 07:56:51 +08:00

我滴乖乖... 字段名都换成单字母, 就能省下一半体积了 23333333

71

lslqtz

2016-10-10 08:01:20 +08:00

用动态 api 不好吗。。

72

murmur

2016-10-10 08:07:53 +08:00

@lslqtz 然后就被各种抢票刷票查票软件搞死？

73

Wakeupzombie

2016-10-10 08:25:10 +08:00

@youxiachai 兄弟，咱们又不是经常买火车票。这样或许只对票贩子有好处吧

74

popok

2016-10-10 08:27:09 +08:00

@bridge45 我 2G 内存的， 5 年前的破笔记本， XP 系统，都完全不卡，你的配置不错的都卡了？？？

75

linux40

2016-10-10 08:29:52 +08:00 via Android

@reus 同意，多大的文件，只要不是太大 cat 一下马上就完了。。。

76

exch4nge

2016-10-10 08:58:15 +08:00

目测把 json 的 key （ station_train_code ， train_no ）改成缩写，会减下来不少文件大小。。。
或者不用 JSON ，用点别的方式序列化数据，也可以减少不少。。。
再加什么 gzip ，就更棒了。。。

77

bsidb

2016-10-10 09:00:07 +08:00 via Android

@schezukNewTos 手机有 12306 客户端，启动的时候也会自动检测并更新数据库文件

78

ytmsdy

2016-10-10 09:11:07 +08:00

这东西估计相当于数据库吧，反正数据就是要全部都下载下来，痛苦多次还不如一次性痛苦完了算了。分多个文件增加了下载的不确定性，还有么就是后续调用的时候会比较麻烦。

79

wizardoz

2016-10-10 09:22:04 +08:00

主要是这个页面是要在前端查询车次的,数据必须全部都加载到前端才能查,考虑到这个,分不分级其实无所谓了.
我想说的是 12306 这么大一个网站,为啥不买一个证书?

80

annielong

2016-10-10 09:26:12 +08:00

公说公有理婆说婆有理，这个方案虽然有不足，但是卡死一个用户总比卡死服务器强，当然，继续优化优化会更好

81

youxiachai

2016-10-10 09:28:37 +08:00

@Wakeupzombie 这是个对整个大系统优化策略取舍问题而已.....
就算你不是经常买火车票的..其实对流量而言就 4M 数据而已....而且...也就只有第一次加载会慢..以后查询..反而更方便一些...就系统设计本身,简单直接.......

还是 cdn 的问题的...就整个系统而言..cdn 的扩容和优化是最简单的....特别是在高峰期...只要堆机器就好了...不会对系统有多大压力.

而且,数据在本地..查起来,速度杠杠的.....即时是高峰期也是一样....

82

tumbzzc

2016-10-10 09:34:55 +08:00

也是醉了，这不应该放数据库吗

83

Nutlee

2016-10-10 09:39:42 +08:00

是比这蛋疼的多的是 12306 的证书....... 这都多久了 ......

84

66beta

2016-10-10 09:41:14 +08:00

所以现在不流行 redis 什么的了吧？

85

SlipStupig

2016-10-10 09:49:06 +08:00

我们成功的将性能提升了多少少，请领导指示下一步工作!

86

lianxiaoyi

2016-10-10 09:58:55 +08:00 via Android

12306 的 cdn 才是最扯淡的！显示有票，结果提交时就没票了！后面整个请求结果都被缓存

87

hekunhotmail

2016-10-10 10:01:10 +08:00

看你们说的， 12306 就跟只有一个前端似的；
其实有一个很厉害的团队在搞的吧

88

xpol

2016-10-10 10:51:25 +08:00

7z 压缩到 93.4KB 。
gzip 到 3.58M 。

89

bridge45

OP

2016-10-10 11:03:22 +08:00

@500miles 这个主意好像不错

90

bridge45

OP

2016-10-10 11:04:16 +08:00

@popok 清缓存刷新会卡一会

91

setonfocus

2016-10-10 11:04:17 +08:00

把压力丢给前端，不是将来 web 开发的趋势吗

92

bridge45

OP

2016-10-10 11:08:14 +08:00

@setonfocus 量大的情况下,这样的赘余会被放大,细小的优化也会被放大

93

Quaintjade

2016-10-10 11:38:54 +08:00

CDN 很白菜啊，有什么好担心的。
假设一次下载实际消耗 5MB ，每一亿次下载总共消耗 488,281GB ，参考阿里云国内 CDN 价格平均估计 0.3 元 /GB ，那也就是 14.6 万元而已。
考虑到浏览器缓存以及一人为多人买票，我觉得按平均每个月一亿次下载算挺多了。

94

iyaozhen

2016-10-10 11:52:11 +08:00 via Android

@exch4nge 这种相同的 key ， gzip 会压缩掉吧。改短也差不多

12306 这方案简单粗暴。不过用流量的就蛋疼了

95

errorlife

2016-10-10 12:36:13 +08:00

厉害了，我的哥。这个比我的种子多多了。

96

lslqtz

2016-10-10 12:55:25 +08:00 via iPhone

@murmur 防盗链...然后单独独立出来用缓存

97

lslqtz

2016-10-10 12:58:25 +08:00 via iPhone

或者改成查询时分段调用当天的 js

98

g5

2016-10-10 13:37:30 +08:00 via Android

马云恨不得让铁老大把服务器搬他家去，如果支持微信支付，小马也愿意免费放他家

99

tuimaochang

2016-10-10 14:47:41 +08:00

卡住了，拖不动

100

azh7138m

2016-10-10 14:49:25 +08:00

@bridge45 笔记本 3230M ff 与 chrome 都打开了那个文件，也就加载的时候 CPU 50%-60%，不卡啊

1 2

❮

❯