直接贴地址: https://kyfw.12306.cn/otn/resources/js/query/train_list.js 下载下来文本 35M,网页流量查看显示 4M...如何的慢,想想就知道了
推荐关注
› Meteor
› JSLint - a JavaScript code quality tool
› jsFiddle
› D3.js
› WebStorm
推荐书目
› JavaScript 权威指南第 5 版
› Closure: The Definitive Guide
› Closure: The Definitive Guide
This topic created in 3681 days ago, the information mentioned may be changed or developed.
 |
yuankuiOct 9, 2016
1
不错啊，这个数据~
|
 |
2
train_list ，是车次信息吧？可以减轻服务器压力，其实算正路做法。
那些页游、 flash 之类的资源，比这大的也不少见，没啥的。 |
1 |
minbabyOct 9, 2016
3
好奇心害死猫。（ chrome 卡死了）
|
 |
wolfanOct 9, 2016
6
LZ 小心铁总今年不卖回家的车票你哟~
|
|
14
@bridge45 从你的回复可以看出你并不是很懂技术，我想这种显而易见的事情，没什么值得讨论的。一个 gzip 后 4M 的资源，怎么就对不起电脑对不起带宽了呢？动态查询难道就不占带宽？动态查询还耗服务器资源。
|
 |
15
@reus 简单个分法:分为 D,T,K,G 四种文件,用户输入第一个字母去加载对应 js 文件,当然还有其他分法...,就可以大为减少一些带宽和内存.我配置不错的台式机 chrome 卡爆了...
|
 |
learnshareOct 9, 2016
16
查看文件详情，标签卡死了
|
 |
tscatOct 9, 2016 via iPhone
17
4m 的文件根本不占带宽吧和图片之类的比起来
|
 |
qqmishiOct 9, 2016 via Android
19
下载下来把我的 gedit 卡死了，，，
|
 |
SasasuOct 9, 2016 via Android
21
c++程序里经常有几十兆的表打在内存里， js 里打表怎么了嘛，况且还只能打表的东西。
电脑比你想象的更适合处理这种任务，你觉得卡是渲染的问题，我的手机只会尝试渲染前几百行，剩下的不管。秒开不卡 |
|
reusOct 9, 2016
22
@bridge45 我用 chrome 打开 https://kyfw.12306.cn/otn/queryTrainInfo/init ，占 500 几 M 内存，多是多一些，但也在可以接受的范围内。你可以换其他内核的浏览器试试， chrome 在某些平台某些版本内存泄漏挺严重的。
|
 |
jhaohaiOct 9, 2016 via iPhone
23
简单粗暴有效
|
 |
youxiachaiOct 9, 2016
29
简单除暴省事....12306 为了省服务器资源..也是拼了...
简单来说.你电脑差,网络差,买毛线车票..... 好像确实这样..黄牛都是顶配电脑+网络... |
 |
xfspaceOct 9, 2016 via Android
30
12306 的特殊性...没什么好说的。
外人评价怎么怎么垃圾，要这样写要这样拆，没考虑到其他因素。 |
|
youxiachaiOct 9, 2016
31
@bridge45 其实,例如我可以忍受第一次慢点...而且..以后访问有缓存...也不会慢..
你的方案看上去很好..但是不符合人性..,在等我查的时候,才去下载.在这个过程中..就有了时间的消耗..而现在这个只是第一次加载慢点,以后查就很快了.... 还是个人性的问题... |
 |
iTakeoOct 9, 2016 via iPhone
32
为什么我的手机秒开，一点不带卡的？
|
 |
williamxOct 9, 2016
33
这种明显是要分级的。太懒了
|
 |
34
国家应该再开个卖火车票的类似 12306 的 没有竞争 永远没有提升！价格始终不降
|
 |
zhihaofansOct 9, 2016
35
NOTEPAD++卡住了。。。
|
 |
ChiangDiOct 9, 2016 via Android
36
我手机 chrome 也秒开
|
 |
scnaceOct 9, 2016 via Android
37
和之前那个 SQL 的帖子有异工同曲之妙～
|
|
38
@youxiachai 哈哈 服了
|
 |
jasontseOct 9, 2016 via iPad
39
这一点都不节省资源好吧，简直是浪费带宽，有用没用的一起加载。
|
 |
jeremaihlooOct 9, 2016 via Android
40
讲道理，我们都是秒开，其实文件和我们平时手机浏览一个网页的图片相比并不大，而且，你说你下载这东西时间长，我只能说你用的网络太垃圾，而且不能代表其他人网络和你一样差，我老家农村 4m 小水管都没问题，你现在用的网络该换换了（手动滑稽并爱抚一下题主）
|
 |
mdzzOct 9, 2016
41
$ 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 |
 |
yangyaofeiOct 9, 2016 via Android
42
@minbaby 表示 android chrome 不卡😂😂😂
|
|
youxiachaiOct 9, 2016
43
@jasontse cdn 表示这点带宽小 case ....
|
 |
adv007Oct 9, 2016 via iPhone
44
这么大的 js 一般是不懂前端的工程师干的，此时先不用扯 CDN,gzip
|
|
yangyaofeiOct 9, 2016 via Android
45
感觉挺好……第一次会比较慢，但是后面再请求应该都 200 吧，车票肯定来回刷，加上 cdn ，感觉很好。
|
|
jasontseOct 9, 2016 via iPad
46
@youxiachai 按照 12306 的流量级别，再加上春运时的尖峰流量，这是很大的开销。
|
 |
hellojinjieOct 9, 2016
47
我们很多时候一张图片也要好几兆了啊， 4MiB 的文本下载很正常啊。
|
 |
fqzzOct 9, 2016
48
react + webpack 打出来的 app ， gzip 后不一定比这小多少。
|
 |
ChaosParkOct 9, 2016
49
这样做挺好，不然网络垃圾点的就更抢不到票了。
|
 |
Totato5749Oct 9, 2016
50
我很好奇的是， 12306 的那些程序猿都神龙见首不见尾，从来没在网上见过说自己是 12306 的， 12306 现在也不算是黑点吧，总比百度强吧
|
 |
TinkOct 9, 2016
52
我惊了
|
|
TinkOct 9, 2016
53
这个东西还有点用啊
|
 |
schezukNewTosOct 9, 2016
54
铁总又不需要频繁调图，一个月不带变一次的。
只需要堆 cdn 就能给数据库减负，挺合算的。 何况第二次访问直接返回 304 ， cdn 不耗流量。 如果手机用略吃亏，慢，费流量。 |
 |
billwangOct 9, 2016
55
notepad++ 未响应
第一次打开那个网址等了十秒左右，后面打开就快一些，虽然我笔记本有些老了 |
 |
SilentDepthOct 9, 2016
56
Chrome on Windows 点开，风扇开始转……囧
|
|
youxiachaiOct 9, 2016 via iPad
57
@jasontse 嗯...目测是没怎么接触 cdn 的？ cdn 的前端缓存性能非常厉害........说实在的就算是峰值也就是开多几个地区的 cdn 而已，对于整个系统的开销 cdn 是最方便扩容的....这种只要堆机器的方法最省事了....
|
|
60
说直接打开或者 notepad++打开慢的，根本就没搞明白吧，作为脚本运行时，它不需要渲染给你看，很快的。直接打开慢， notepad++打开慢，是因为需要渲染所有的文字。实际执行的时候，直接就执行 js 代码了，又不需要渲染，所以说直接打开或者 notepad++打开慢，毫无意义。
|
 |
zhanglintcOct 9, 2016
61
@reus 我觉得大家想表达的是, notepad++打开慢说明文件大, 下载会很花时间的...
|
 |
ShuraOct 9, 2016 via Android
62
这个算是 js 打表吧，我感觉很正常啊，可能这个程序员搞过 acm
|
 |
indooorsmanOct 9, 2016 via Android
63
同意楼上，请打开页面在 chrome 控制台的网络里查看响应时间，直接打开文本慢并没有意义
|
|
indooorsmanOct 9, 2016 via Android
64
楼上指的是 @reus
|
|
indooorsmanOct 9, 2016 via Android
65
@zhanglintc 然而并不能说明，下载的时候是 gzip 后的文件，编辑器打开的时候可不是
|
 |
67
这个文件，好像是铁路运行图
|
 |
paulagentOct 10, 2016 via Android
68
这种垄断企业是不会考虑用户的
|
 |
RqPS6rhmP3Nyn3TmOct 10, 2016 via iPhone
69
用户太多，只能尽量省资源。不过铁总的后端和前端很难想象他们是一个研究所出的
|
 |
500milesOct 10, 2016
70
我滴乖乖... 字段名都换成单字母, 就能省下一半体积了 23333333
|
 |
lslqtzOct 10, 2016
71
用动态 api 不好吗。。
|
 |
WakeupzombieOct 10, 2016
73
@youxiachai 兄弟，咱们又不是经常买火车票。这样或许只对票贩子有好处吧
|
 |
exch4ngeOct 10, 2016
76
目测把 json 的 key （ station_train_code ， train_no ）改成缩写，会减下来不少文件大小。。。
或者不用 JSON ，用点别的方式序列化数据，也可以减少不少。。。 再加什么 gzip ，就更棒了。。。 |
 |
bsidbOct 10, 2016 via Android
77
@schezukNewTos 手机有 12306 客户端，启动的时候也会自动检测并更新数据库文件
|
 |
ytmsdyOct 10, 2016
78
这东西估计相当于数据库吧，反正数据就是要全部都下载下来，痛苦多次还不如一次性痛苦完了算了。分多个文件增加了下载的不确定性，还有么就是后续调用的时候会比较麻烦。
|
 |
wizardozOct 10, 2016
79
主要是这个页面是要在前端查询车次的,数据必须全部都加载到前端才能查,考虑到这个,分不分级其实无所谓了.
我想说的是 12306 这么大一个网站,为啥不买一个证书? |
 |
annielongOct 10, 2016
80
公说公有理婆说婆有理，这个方案虽然有不足，但是卡死一个用户总比卡死服务器强，当然，继续优化优化会更好
|
|
youxiachaiOct 10, 2016
81
@Wakeupzombie 这是个对整个大系统优化策略取舍问题而已.....
就算你不是经常买火车票的..其实对流量而言就 4M 数据而已....而且...也就只有第一次加载会慢..以后查询..反而更方便一些...就系统设计本身,简单直接....... 还是 cdn 的问题的...就整个系统而言..cdn 的扩容和优化是最简单的....特别是在高峰期...只要堆机器就好了...不会对系统有多大压力. 而且,数据在本地..查起来,速度杠杠的.....即时是高峰期也是一样.... |
 |
82
也是醉了，这不应该放数据库吗
|
 |
NutleeOct 10, 2016
83
是 比这蛋疼的多的是 12306 的证书....... 这都多久了 ......
|
 |
66betaOct 10, 2016
84
所以现在不流行 redis 什么的了吧？
|
 |
SlipStupigOct 10, 2016
85
我们成功的将性能提升了多少少，请领导指示下一步工作!
|
 |
lianxiaoyiOct 10, 2016 via Android
86
12306 的 cdn 才是最扯淡的！显示有票，结果提交时就没票了！后面整个请求结果都被缓存
|
 |
hekunhotmailOct 10, 2016
87
看你们说的， 12306 就跟只有一个前端似的；
其实有一个很厉害的团队在搞的吧 |
 |
xpolOct 10, 2016
88
7z 压缩到 93.4KB 。
gzip 到 3.58M 。 |
 |
setonfocusOct 10, 2016
91
把压力丢给前端，不是将来 web 开发的趋势吗
|
|
92
@setonfocus 量大的情况下,这样的赘余会被放大,细小的优化也会被放大
|
 |
QuaintjadeOct 10, 2016
93
CDN 很白菜啊，有什么好担心的。
假设一次下载实际消耗 5MB ，每一亿次下载总共消耗 488,281GB ，参考阿里云国内 CDN 价格平均估计 0.3 元 /GB ，那也就是 14.6 万元而已。 考虑到浏览器缓存以及一人为多人买票，我觉得按平均每个月一亿次下载算挺多了。 |
 |
errorlifeOct 10, 2016
95
厉害了，我的哥。这个比我的种子多多了。
|
|
lslqtzOct 10, 2016 via iPhone
97
或者改成查询时分段调用当天的 js
|
 |
g5Oct 10, 2016 via Android
98
马云恨不得让铁老大把服务器搬他家去，如果支持微信支付，小马也愿意免费放他家
|
 |
suntoryliquOct 10, 2016
99
卡住了，拖不动
|
Select Language