l*****9
发帖数: 9501 | 1 感觉没有用 asynchronous batch processing. 后台批量处理，貌似老土，啥时候都不
过时 |
g*****g
发帖数: 34805 | 2 不需要吧，大部分是读操作。其实就我说的那一招，分批放人，估计就解决了90%的问
题。
【在 l*****9 的大作中提到】
: 感觉没有用 asynchronous batch processing. 后台批量处理，貌似老土，啥时候都不
: 过时
|
l*****9
发帖数: 9501 | 3 You see the result without asynchronous processing
Healthcare.gov is a portal of many websites, ideal for asynchronous
processing
【在 g*****g 的大作中提到】
: 不需要吧，大部分是读操作。其实就我说的那一招，分批放人，估计就解决了90%的问
: 题。
|
c****3
发帖数: 10787 | 4 找加拿大CGI公司，纯粹是送钱的。这种公司都是一堆水平很差的外包老印，就是给政
府做最简单网站，但要高价的。复杂一点，就露馅了，连自己擦屁股都不会。
【在 l*****9 的大作中提到】
: 感觉没有用 asynchronous batch processing. 后台批量处理，貌似老土，啥时候都不
: 过时
|
g*****g
发帖数: 34805 | 5 As I said, it's overkill for this case architecture wise. No two users are
related, it's not like bidding (ebay) or supply is limited (amazon), why do
you need asynchronous processing? A simple RDBMS horizontal partition +
smooth out the peak traffic by letting users signup gradually is more than
enough.
They won't see such high traffic again, it's a waste to invest on too much
hardware. And it's too hard for them to do it in the cloud.
【在 l*****9 的大作中提到】
: You see the result without asynchronous processing
: Healthcare.gov is a portal of many websites, ideal for asynchronous
: processing
|
l*****9
发帖数: 9501 | 6 you have no idea about asynchronous processing: it actually uses less
resource than synchronos counterpart. If a batch process uses more resource
than real-time, who wants to use it?
do
【在 g*****g 的大作中提到】
: As I said, it's overkill for this case architecture wise. No two users are
: related, it's not like bidding (ebay) or supply is limited (amazon), why do
: you need asynchronous processing? A simple RDBMS horizontal partition +
: smooth out the peak traffic by letting users signup gradually is more than
: enough.
: They won't see such high traffic again, it's a waste to invest on too much
: hardware. And it's too hard for them to do it in the cloud.
|
l*****9
发帖数: 9501 | 7 http://www.techinsurance.com/blog/errors-and-omissions/what-dev
Traffic problems. The website’s first and most obvious problem occurred
shortly after launch, when users rushed to sign up, only to find the website
overwhelmed and malfunctioning due to the massive amount of traffic. When
most people think about web traffic problems, they assume they occur because
of a problem with the server, but as tech blogger Paul Adams points out,
the site’s problems were caused by architecture as well. Adams suggests the
developers erred by making the site synchronous – as user accounts and
information were created, they were validated and checked in real time.
Instead, the site could have used an asynchronous system, which would let
users create accounts, browse, and find information on plans, while their
personal information was added to a queue to be checked later during less
busy times (Adams points out that this is how Amazon.com works). In other
words, some of the website’s malfunctions can be attributed to its designed
, which makes its developers responsible. |
g*****g
发帖数: 34805 | 8 I did 10M+ concurrent users asynchronous processing from scratch. I know
what I am talking about. Asynchronous uses less resource but it doesn't
provide a good experience on the UI, nor it's simple on programming. And in
this case, it's overkilling.
resource
【在 l*****9 的大作中提到】
: you have no idea about asynchronous processing: it actually uses less
: resource than synchronos counterpart. If a batch process uses more resource
: than real-time, who wants to use it?
:
: do
|
g*****g
发帖数: 34805 | 9 There are different ways to achieve the same goal. Asynchronous processing
is overkilling in this case. And I don't think Amazon uses asynchronous
processing in its order process. It's not like you submit an order and you
only know if the order is successful at a later time. And retailer's problem
is much harder due to limited supply of goods, not the case with insurance.
A simple RDBMS horizontal partition can be achieved in this case, many DB (
e.g. Oracle) has it built-in, it's much easier to do it that way.
website
because
the
【在 l*****9 的大作中提到】
: http://www.techinsurance.com/blog/errors-and-omissions/what-dev
: Traffic problems. The website’s first and most obvious problem occurred
: shortly after launch, when users rushed to sign up, only to find the website
: overwhelmed and malfunctioning due to the massive amount of traffic. When
: most people think about web traffic problems, they assume they occur because
: of a problem with the server, but as tech blogger Paul Adams points out,
: the site’s problems were caused by architecture as well. Adams suggests the
: developers erred by making the site synchronous – as user accounts and
: information were created, they were validated and checked in real time.
: Instead, the site could have used an asynchronous system, which would let
|
l*****9
发帖数: 9501 | 10 Amazon definitely uses async process: you place an order with wrong credit
card info, you will get order confirmation, then later an email asking you
to fix data.
Async is the architure by choice for large concurrent users, and is LESS
complicated to implement than real-time aproach. Async process is the divide
and conquer approach for complex portal application.
problem
insurance.
【在 g*****g 的大作中提到】
: There are different ways to achieve the same goal. Asynchronous processing
: is overkilling in this case. And I don't think Amazon uses asynchronous
: processing in its order process. It's not like you submit an order and you
: only know if the order is successful at a later time. And retailer's problem
: is much harder due to limited supply of goods, not the case with insurance.
: A simple RDBMS horizontal partition can be achieved in this case, many DB (
: e.g. Oracle) has it built-in, it's much easier to do it that way.
:
: website
: because
|
|
|
l*****9
发帖数: 9501 | 11 Because of volumn of concurrent users, AND validation and data exchange
among many seperate parties, async definitely is the way to go for Obamacare
website.
do
【在 g*****g 的大作中提到】
: As I said, it's overkill for this case architecture wise. No two users are
: related, it's not like bidding (ebay) or supply is limited (amazon), why do
: you need asynchronous processing? A simple RDBMS horizontal partition +
: smooth out the peak traffic by letting users signup gradually is more than
: enough.
: They won't see such high traffic again, it's a waste to invest on too much
: hardware. And it's too hard for them to do it in the cloud.
|
l*****9
发帖数: 9501 | 12 Async architecture is not complicated at all, and actually easier to
implement than real-time aproach. With potentially tens of millions of
concurrent users, you don't want form submission to wait for validation and
possibly bringing data back from seperate parties, you should instead just
save the data and feed data to queued backend batch process.
【在 c****3 的大作中提到】
: 找加拿大CGI公司，纯粹是送钱的。这种公司都是一堆水平很差的外包老印，就是给政
: 府做最简单网站，但要高价的。复杂一点，就露馅了，连自己擦屁股都不会。
|
g*****g
发帖数: 34805 | 13 Even if Amazon is really using async process, your conclusion is still wrong.
Async is not simpler, if async is simpler, the majority of websites would be
using it. Async is typically for achieving better performance by batching
up, or when
complicated locking/ordering is required between requests. In your
description, the workflow is already more complicated than letting you know
if the transaction is successful or not right at the spot.
In this case, there's no such thing as how many items are left. One user
cannot step on another user's foot, unlike Amazon's case. Simple user table
horizontal partition can do perfect full stack isolation, without
application
even knowing. Async is overkilling in this case.
divide
【在 l*****9 的大作中提到】
: Amazon definitely uses async process: you place an order with wrong credit
: card info, you will get order confirmation, then later an email asking you
: to fix data.
: Async is the architure by choice for large concurrent users, and is LESS
: complicated to implement than real-time aproach. Async process is the divide
: and conquer approach for complex portal application.
:
: problem
: insurance.
|
l*****9
发帖数: 9501 | 14 If async is overkill for Obamacare website, the website would have been
fixed long ago.
wrong.
be
know
table
【在 g*****g 的大作中提到】
: Even if Amazon is really using async process, your conclusion is still wrong.
: Async is not simpler, if async is simpler, the majority of websites would be
: using it. Async is typically for achieving better performance by batching
: up, or when
: complicated locking/ordering is required between requests. In your
: description, the workflow is already more complicated than letting you know
: if the transaction is successful or not right at the spot.
: In this case, there's no such thing as how many items are left. One user
: cannot step on another user's foot, unlike Amazon's case. Simple user table
: horizontal partition can do perfect full stack isolation, without
|
g*****g
发帖数: 34805 | 15 async processing is overkill doesn't mean sync processing is simple for them.
Achieving high scalability is never trivial.
【在 l*****9 的大作中提到】
: If async is overkill for Obamacare website, the website would have been
: fixed long ago.
:
: wrong.
: be
: know
: table
|
l*****9
发帖数: 9501 | 16 You are unqualified as an architect
them.
【在 g*****g 的大作中提到】
: async processing is overkill doesn't mean sync processing is simple for them.
: Achieving high scalability is never trivial.
|
b***i
发帖数: 3043 | 17 虽然Async可以解决问题，不等于Sync就没有解决问题的办法。办法之一就是goodbug说
的，这个比Async还简单。但是，CGI连这个简单的办法都不会，更何况Async。
【在 l*****9 的大作中提到】
: You are unqualified as an architect
:
: them.
|
l*****9
发帖数: 9501 | 18 同时几百万(甚至几千万）人用的系统，选择 sync 架构是自杀: 对server and
network capacity要求太高。结果是async 比 sync 有更好的user experience
这个联邦政府网站和IRS,各个州，各个保险公司都有DATA VALIDATION/EXCHANGE
【在 b***i 的大作中提到】
: 虽然Async可以解决问题，不等于Sync就没有解决问题的办法。办法之一就是goodbug说
: 的，这个比Async还简单。但是，CGI连这个简单的办法都不会，更何况Async。
|
g*****g
发帖数: 34805 | 19 Since when what you think matters?
【在 l*****9 的大作中提到】
: You are unqualified as an architect
:
: them.
|
g*****g
发帖数: 34805 | 20 They won't have much traffic after initial phase. How frequent you
do something in your insurance site? 5 read session and 1 write session a
year?
Using an async architecture requires a much more complicated code base, and
I heard they started coding this spring.
As I mentioned, a gradual state by state rollout already solves 90% of their
problem. But they are just not smart enough.
【在 l*****9 的大作中提到】
: 同时几百万(甚至几千万）人用的系统，选择 sync 架构是自杀: 对server and
: network capacity要求太高。结果是async 比 sync 有更好的user experience
: 这个联邦政府网站和IRS,各个州，各个保险公司都有DATA VALIDATION/EXCHANGE
|
|
|
l*****9
发帖数: 9501 | 21 那是因为系统不工作，POTENTIALLY可能有7千万人用，你这种思路设计的系统就不WORK
and
their
【在 g*****g 的大作中提到】
: They won't have much traffic after initial phase. How frequent you
: do something in your insurance site? 5 read session and 1 write session a
: year?
: Using an async architecture requires a much more complicated code base, and
: I heard they started coding this spring.
: As I mentioned, a gradual state by state rollout already solves 90% of their
: problem. But they are just not smart enough.
|
l*****9
发帖数: 9501 | 22 You just showed lack of common sense
【在 g*****g 的大作中提到】
: Since when what you think matters?
|
g*****g
发帖数: 34805 | 23 你才完全没有常识。对于这种高并发的网站，读写分离，读缓存，写分表，就是一个常
识而已。
对于可以完美分表，没有冲突的，scale out根本不是个问题。
批处理从来都不是UI应用建议的做法，一个是用户不能及时得到结果。另一个是一个交
易失败，会导致一堆不相关交易也失败。
7千万人根本不算什么，保险是一家的。7千万人也就是3千万左右用户而已。加上分批
放人，可以很容易的把峰值的日有效写用户压在500万以下。加上完美分表，用上10-20
个数据库服务器就搞定了。
一个合格的架构师，要擅长分析不同数据的特性并使用不同的解决方案。要考虑的不只
是性能，还要考虑成本，time to market。明明有简单的架构，你引入牛刀就会导致开
发维护成本提高，time to market时间变长。只会人云亦云是没用的。
【在 l*****9 的大作中提到】
: You just showed lack of common sense
|
g*****g
发帖数: 34805 | 24 我提出的是一个完全scale out的系统，别说7千万，7亿人也能用。摆脱有点常识。
WORK
【在 l*****9 的大作中提到】
: 那是因为系统不工作，POTENTIALLY可能有7千万人用，你这种思路设计的系统就不WORK
:
: and
: their
|
h*****a
发帖数: 1718 | 25 对，感觉这种系统就是通过shard搞定就行了。
20
【在 g*****g 的大作中提到】
: 你才完全没有常识。对于这种高并发的网站，读写分离，读缓存，写分表，就是一个常
: 识而已。
: 对于可以完美分表，没有冲突的，scale out根本不是个问题。
: 批处理从来都不是UI应用建议的做法，一个是用户不能及时得到结果。另一个是一个交
: 易失败，会导致一堆不相关交易也失败。
: 7千万人根本不算什么，保险是一家的。7千万人也就是3千万左右用户而已。加上分批
: 放人，可以很容易的把峰值的日有效写用户压在500万以下。加上完美分表，用上10-20
: 个数据库服务器就搞定了。
: 一个合格的架构师，要擅长分析不同数据的特性并使用不同的解决方案。要考虑的不只
: 是性能，还要考虑成本，time to market。明明有简单的架构，你引入牛刀就会导致开
|
z****e
发帖数: 54598 | 26 呵呵，如果你知道全球机票30％出自一个系统
还有45％出自另外一个系统
你还不得自杀谢罪
别告诉我说全球圣诞高峰时候人数不足千万
【在 l*****9 的大作中提到】
: 同时几百万(甚至几千万）人用的系统，选择 sync 架构是自杀: 对server and
: network capacity要求太高。结果是async 比 sync 有更好的user experience
: 这个联邦政府网站和IRS,各个州，各个保险公司都有DATA VALIDATION/EXCHANGE
|
g*****g
发帖数: 34805 | 27 你那机票如果不允许超卖，其实难度比这个大多了，这个没有超卖一说，所以用户之间
完全独立。
【在 z****e 的大作中提到】
: 呵呵，如果你知道全球机票30％出自一个系统
: 还有45％出自另外一个系统
: 你还不得自杀谢罪
: 别告诉我说全球圣诞高峰时候人数不足千万
|
l*****9
发帖数: 9501 | 28 不是所有 use case 都 async
最外层的是个静态的纯portal,根据用户的州给出网站链接，不存用户资料，没有数据库
federal exchange 和 各个州exchange一样,是真正的workhorse：
1。公民和绿卡根据收入和人口可以browse available plans, 不存用户资料，不
validate eligibility. 这部分可以是半静态 （静态数据daily refresh if
necessary）
2. 用户想登记，一个大表接受所有（支付手段以外）数据，存下数据，产生用户。后
台批量async validate
3. 用户browse available eligible plans, 选定plan. 存下选择，后台批量async
send data to insurance providers. 以后就是保险公司和用户之间的事了
4。用户修改信息或选择，async validate or send data if necessary
5.用户完成购买，后台批量async accept insurance providers' feedback. user
data locked until next plan update event, such as renewal or addition/
reduction of family members
这个流程和架构绝对是obamacare website的最佳设计，没有任何overkill
shard 和这个架构不矛盾
20
【在 g*****g 的大作中提到】
: 你才完全没有常识。对于这种高并发的网站，读写分离，读缓存，写分表，就是一个常
: 识而已。
: 对于可以完美分表，没有冲突的，scale out根本不是个问题。
: 批处理从来都不是UI应用建议的做法，一个是用户不能及时得到结果。另一个是一个交
: 易失败，会导致一堆不相关交易也失败。
: 7千万人根本不算什么，保险是一家的。7千万人也就是3千万左右用户而已。加上分批
: 放人，可以很容易的把峰值的日有效写用户压在500万以下。加上完美分表，用上10-20
: 个数据库服务器就搞定了。
: 一个合格的架构师，要擅长分析不同数据的特性并使用不同的解决方案。要考虑的不只
: 是性能，还要考虑成本，time to market。明明有简单的架构，你引入牛刀就会导致开
|
g*****g
发帖数: 34805 | 29 据报道说用户卡在用户注册上了，如果需要validate, validate跟产生用户本来就是分
开的，可以先
validate后建立用户。连UI都可以分两步。总之常识是UI应用不是真不得已不用后台批
处理，要提高性能分表是优先考虑的。而不是你这样上来就不分青红皂白来个async就
能解决，连Amazon跟obamacare数据特性的区别都没考虑。
据库
【在 l*****9 的大作中提到】
: 不是所有 use case 都 async
: 最外层的是个静态的纯portal,根据用户的州给出网站链接，不存用户资料，没有数据库
: federal exchange 和 各个州exchange一样,是真正的workhorse：
: 1。公民和绿卡根据收入和人口可以browse available plans, 不存用户资料，不
: validate eligibility. 这部分可以是半静态 （静态数据daily refresh if
: necessary）
: 2. 用户想登记，一个大表接受所有（支付手段以外）数据，存下数据，产生用户。后
: 台批量async validate
: 3. 用户browse available eligible plans, 选定plan. 存下选择，后台批量async
: send data to insurance providers. 以后就是保险公司和用户之间的事了
|
l*****9
发帖数: 9501 | 30 人就是要坚持错误啊，你就是最好的例子
登记hold up,因为要和不同系统validate data, such as SSN, income, immigration
status, veteran status, to determine eligibility,这是现有系统最大的bug. 所以
我建议用一个大表接受用户输入，后台批处理validation. 这是我的架构比现有架构最
大的高明之处。
另外，现有系统不登记就不能browse available policies,所以系统基本啥也干不了，
一个月只登记了27000人。我的设计允许browse available policies without
registration,是重大user friendliness.
Now you agrees Amazon use async process?
【在 g*****g 的大作中提到】
: 据报道说用户卡在用户注册上了，如果需要validate, validate跟产生用户本来就是分
: 开的，可以先
: validate后建立用户。连UI都可以分两步。总之常识是UI应用不是真不得已不用后台批
: 处理，要提高性能分表是优先考虑的。而不是你这样上来就不分青红皂白来个async就
: 能解决，连Amazon跟obamacare数据特性的区别都没考虑。
:
: 据库
|
|
|
g*****g
发帖数: 34805 | 31 你完全不知道自己在说啥呀，所有的validation，都不需要参与transaction。一个个
外部validation跑过去，过了发个token，让用户点击确认，连这个token一起提交才产
生用户，这之前完全没有本地数据库参与，没什么瓶颈。而产生用户这一步用我说的
sharding
可以很轻松的解决。如果某个外部validation API不能处理这个并发量，那是外部服务
scalability的问题，不需要在这个网站里解决，也没法在这个网站里解决。
如果transaction参与validation是没法注册用户的原因，那是设计的错误，但不等于
必须用async解决，transaction本来就是越小越好。你让用户提交大量invaliid的数据
到数据库里本身就不是什么好的设计。我再说一遍，amazon至少在UI上来说，是个sync
process，提交订单就立刻跟我说成不成功，订单立刻就产生一个transaction提交到
数据库。如果有异步的process来
另外验证这个订单，那也是另一回事。
我说这么多帖子，提出来的解决办法的核心就是用户直接完全没有关系，可以完美划分。
极端的话想象一下根据IP地址，DNS把流量分配到1万套完全独立的系统上，1个系统无
非处理3000人。这些系统自然不会有本地的瓶颈。你上来就async万能，不就是舍本求
末。
immigration
【在 l*****9 的大作中提到】
: 人就是要坚持错误啊，你就是最好的例子
: 登记hold up,因为要和不同系统validate data, such as SSN, income, immigration
: status, veteran status, to determine eligibility,这是现有系统最大的bug. 所以
: 我建议用一个大表接受用户输入，后台批处理validation. 这是我的架构比现有架构最
: 大的高明之处。
: 另外，现有系统不登记就不能browse available policies,所以系统基本啥也干不了，
: 一个月只登记了27000人。我的设计允许browse available policies without
: registration,是重大user friendliness.
: Now you agrees Amazon use async process?
|
g*********9
发帖数: 1285 | 32 Why do you think async doe not provide good UI experience? Can you give an
example?
in
【在 g*****g 的大作中提到】
: I did 10M+ concurrent users asynchronous processing from scratch. I know
: what I am talking about. Asynchronous uses less resource but it doesn't
: provide a good experience on the UI, nor it's simple on programming. And in
: this case, it's overkilling.
:
: resource
|
g*****g
发帖数: 34805 | 33 you want to minimize wait time for ui application, asyn doesn't do that.
【在 g*********9 的大作中提到】
: Why do you think async doe not provide good UI experience? Can you give an
: example?
:
: in
|
l*****9
发帖数: 9501 | 34 You take in as much user data as possible, and don't let validation get in
the way of data entry. And wait time is surely much less than piecemeal data
and validation then another piece of data and validation. If you cannot
understand this, there is really not much to discuss.
【在 g*****g 的大作中提到】
: you want to minimize wait time for ui application, asyn doesn't do that.
|
g*****g
发帖数: 34805 | 35 That's a funny design. You take in as much data as possible, save them to DB
regardless and validate asynchronously. So a user registers, select a
policy only to receive a notification 15 min later his name doesn't match
SSN on record, he realizes it's a typo on SSN, correct it, and 15 minutes
later he got a notification he's not eligible for the policy. I am sure that
's a very intuitive and effective design. LOL.
Scale-out is all about split data and put them in smallest transactions, if
transaction is needed at all. You are just doing the opposite.
data
【在 l*****9 的大作中提到】
: You take in as much user data as possible, and don't let validation get in
: the way of data entry. And wait time is surely much less than piecemeal data
: and validation then another piece of data and validation. If you cannot
: understand this, there is really not much to discuss.
|
l*****9
发帖数: 9501 | 36 Where did I say a new user can select a policy? Don't put your words into
other's mouth.
Now I see why CGI chose its current design, there are seasoned IT
professionals who just don't have any common sense.
4 columns or 100 columns of data are no big difference, 4 transactions and 1
transaction have huge difference.
DB
that
if
【在 g*****g 的大作中提到】
: That's a funny design. You take in as much data as possible, save them to DB
: regardless and validate asynchronously. So a user registers, select a
: policy only to receive a notification 15 min later his name doesn't match
: SSN on record, he realizes it's a typo on SSN, correct it, and 15 minutes
: later he got a notification he's not eligible for the policy. I am sure that
: 's a very intuitive and effective design. LOL.
: Scale-out is all about split data and put them in smallest transactions, if
: transaction is needed at all. You are just doing the opposite.
:
: data
|
g*****g
发帖数: 34805 | 37 Your word literally. Policy or not, I doubt asynchronous validation is a
good design. Users don't typically wait for emails to correct input errors,
now that's some common sense.
"You take in as much user data as possible, and don't let validation get in
the way of data entry."
BTW, 4 transactions or 1 transaction won't matter in a scale-out design,
each DB only deal with a subset of users.
1
【在 l*****9 的大作中提到】
: Where did I say a new user can select a policy? Don't put your words into
: other's mouth.
: Now I see why CGI chose its current design, there are seasoned IT
: professionals who just don't have any common sense.
: 4 columns or 100 columns of data are no big difference, 4 transactions and 1
: transaction have huge difference.
:
: DB
: that
: if
|
l*****9
发帖数: 9501 | 38 I already layed out process flow in detail
http://www.mitbbs.com/article/Programming/31279109_0.html
,
in
【在 g*****g 的大作中提到】
: Your word literally. Policy or not, I doubt asynchronous validation is a
: good design. Users don't typically wait for emails to correct input errors,
: now that's some common sense.
: "You take in as much user data as possible, and don't let validation get in
: the way of data entry."
: BTW, 4 transactions or 1 transaction won't matter in a scale-out design,
: each DB only deal with a subset of users.
:
: 1
|
g*****g
发帖数: 34805 | 39 我老说半天，这UI不能async validate，注册一个typo等15分钟发个邮件跟你说输入错
了，体验极差，几乎没有网站是这么做的。
你要错误的道路走到底是你的事情，不要跟我再提常识。
【在 l*****9 的大作中提到】
: I already layed out process flow in detail
: http://www.mitbbs.com/article/Programming/31279109_0.html
:
: ,
: in
|
l*****9
发帖数: 9501 | 40 Go talk to some real users of healthcare.gov, you will see whose design the
end users prefer: live validation is the current design, and is the reason
why the website doesn't work.
【在 g*****g 的大作中提到】
: 我老说半天，这UI不能async validate，注册一个typo等15分钟发个邮件跟你说输入错
: 了，体验极差，几乎没有网站是这么做的。
: 你要错误的道路走到底是你的事情，不要跟我再提常识。
|
|
|
g*****g
发帖数: 34805 | 41 I've mentioned how a live validation can work with a fully scale-out design.
I don't get why your poor design is the only way out.
There are so many websites with this scale or more, and tell me which ones
had to turn to asynchronous validation for user registration? Get some
common sense.
the
【在 l*****9 的大作中提到】
: Go talk to some real users of healthcare.gov, you will see whose design the
: end users prefer: live validation is the current design, and is the reason
: why the website doesn't work.
|
l*****9
发帖数: 9501 | 42 Give me one example of similar scale where live validation with IRS,
homeland security, vetaran affiars, are part of registration process
design.
【在 g*****g 的大作中提到】
: I've mentioned how a live validation can work with a fully scale-out design.
: I don't get why your poor design is the only way out.
: There are so many websites with this scale or more, and tell me which ones
: had to turn to asynchronous validation for user registration? Get some
: common sense.
:
: the
|
g*****g
发帖数: 34805 | 43 And why is that a problem? If those external services cannot handle requests
at this scale, those external services should be fixed in the first place.
If those services do, there are nothing shared between the users, there's no
locking, no shared resource, I don't see how it cannot be handled.
You are simply trying to fix in the wrong place.
【在 l*****9 的大作中提到】
: Give me one example of similar scale where live validation with IRS,
: homeland security, vetaran affiars, are part of registration process
:
: design.
|
l*****9
发帖数: 9501 | 44 Show me your success example. I gave you the failure example of your
excellent design: healthcare.gov
requests
.
no
【在 g*****g 的大作中提到】
: And why is that a problem? If those external services cannot handle requests
: at this scale, those external services should be fixed in the first place.
: If those services do, there are nothing shared between the users, there's no
: locking, no shared resource, I don't see how it cannot be handled.
: You are simply trying to fix in the wrong place.
|
g*****g
发帖数: 34805 | 45 I don't know why you are so insistent on a bad design. I've proposed a
better architecture, synchronized validation and fully scale-out solution.
Isn't that enough? It wasn't like you've found a flaw in my proposal.
Go to any insurance website or SSN website, and check if they are using
async validation. Do they count as success examples? Your common sense is so
lacking it's not even funny.
【在 l*****9 的大作中提到】
: Show me your success example. I gave you the failure example of your
: excellent design: healthcare.gov
:
: requests
: .
: no
|
P********l
发帖数: 452 | 46 好像和async/sync无关．那帮家伙都到最后了要干什么都没弄明白．
另外下面的slide提到了goodbug说的gradual launch.
http://apps.npr.org/documents/document.html?id=836380-mckinsey-
【在 l*****9 的大作中提到】
: 感觉没有用 asynchronous batch processing. 后台批量处理，貌似老土，啥时候都不
: 过时
|
g*****g
发帖数: 34805 | 47 These are just common senses, you see I mention testing efforts and gradual
rollout as key points without even looking at specs. Experience counts.
The key findings in the presentation (below) come on Page 5. Even though it
was written in March, the slide sums up most of the key problems we
eventually saw with the rollout of HealthCare.gov last month: limited
testing time, evolving requirements, over-reliance on contractors and "
stacking" of all the phases of development. The really damaging decision,
according to the consultants: launching "at scale." The exchanges for all 50
states opened on the same day, instead of a few states at a time, gradually
opening the marketplaces in phases.
【在 P********l 的大作中提到】
: 好像和async/sync无关．那帮家伙都到最后了要干什么都没弄明白．
: 另外下面的slide提到了goodbug说的gradual launch.
: http://apps.npr.org/documents/document.html?id=836380-mckinsey-
|
l*****9
发帖数: 9501 | 48 No insurance website has scale even close to obamacare website. Live
validation as one step of multiple registration steps is the reason why the
website is not working.
so
【在 g*****g 的大作中提到】
: I don't know why you are so insistent on a bad design. I've proposed a
: better architecture, synchronized validation and fully scale-out solution.
: Isn't that enough? It wasn't like you've found a flaw in my proposal.
: Go to any insurance website or SSN website, and check if they are using
: async validation. Do they count as success examples? Your common sense is so
: lacking it's not even funny.
|
l*****9
发帖数: 9501 | 49 Gradual launch won't help because too many people will wait till last week
【在 P********l 的大作中提到】
: 好像和async/sync无关．那帮家伙都到最后了要干什么都没弄明白．
: 另外下面的slide提到了goodbug说的gradual launch.
: http://apps.npr.org/documents/document.html?id=836380-mckinsey-
|
g*****g
发帖数: 34805 | 50 ironically 30 m visitors in the first day. they aint that patient, are they
? don't fool yourself just because yoy don't want to admit inexperience.
【在 l*****9 的大作中提到】
: Gradual launch won't help because too many people will wait till last week
|
|
|
l*****9
发帖数: 9501 | 51 Just show an example. I already present the example of your desfunctional
design: the Obamacare website
they
【在 g*****g 的大作中提到】
: ironically 30 m visitors in the first day. they aint that patient, are they
: ? don't fool yourself just because yoy don't want to admit inexperience.
|
g*****g
发帖数: 34805 | 52 All insurances websites are examples. They don't use async validation,
period.
And Obamacare is not my dysfunctional design. I have designed a few systems
with more daily active users without performance issue.
Functions come first and foremost. A good architect finds a way to scale out
the system with give functional requirements. Not bending functions
backward to meet performance insufficiency. The Obamacare may be a bad
implementation, but your design is a no starter, you would't even get the
contract if you were the architect.
【在 l*****9 的大作中提到】
: Just show an example. I already present the example of your desfunctional
: design: the Obamacare website
:
: they
|
l*****9
发帖数: 9501 | 53 None insurance company's website has a scale even close to 1% of what
Obamocare website is. You designed a few systems with more daily active
users than Obamacare website need handle? Let's see it.
systems
out
【在 g*****g 的大作中提到】
: All insurances websites are examples. They don't use async validation,
: period.
: And Obamacare is not my dysfunctional design. I have designed a few systems
: with more daily active users without performance issue.
: Functions come first and foremost. A good architect finds a way to scale out
: the system with give functional requirements. Not bending functions
: backward to meet performance insufficiency. The Obamacare may be a bad
: implementation, but your design is a no starter, you would't even get the
: contract if you were the architect.
|
g*****g
发帖数: 34805 | 54 Well, when I refer to merchants like Amazon, eBay, you said they don't do
SSN validation. You always have excuses, don't you.
And I do have designed a few systems having higher daily active users,
Obamacare system wouldn't have more than 5M daily active after initial phase
。Hardly a big number to beat. You don't have to believe me and I don't care.
【在 l*****9 的大作中提到】
: None insurance company's website has a scale even close to 1% of what
: Obamocare website is. You designed a few systems with more daily active
: users than Obamacare website need handle? Let's see it.
:
: systems
: out
|
l*****9
发帖数: 9501 | 55 I didn't brag like you. I know braggers like you don't care, me don't care
what you think neither
phase
care.
【在 g*****g 的大作中提到】
: Well, when I refer to merchants like Amazon, eBay, you said they don't do
: SSN validation. You always have excuses, don't you.
: And I do have designed a few systems having higher daily active users,
: Obamacare system wouldn't have more than 5M daily active after initial phase
: 。Hardly a big number to beat. You don't have to believe me and I don't care.
|
g*****g
发帖数: 34805 | 56 On the contrary, I didn't brag, just state the truth. And I don't talk
things I don't know. The architecture proposal speaks for itself. If you can
't find a flaw from my design, just shut the fuck up.
【在 l*****9 的大作中提到】
: I didn't brag like you. I know braggers like you don't care, me don't care
: what you think neither
:
: phase
: care.
|
l*****9
发帖数: 9501 | 57 You said you designed website handling bigger daily traffic than Obamacare
website need to handle, that's a big claim without proof, and it is called
bragging
can
【在 g*****g 的大作中提到】
: On the contrary, I didn't brag, just state the truth. And I don't talk
: things I don't know. The architecture proposal speaks for itself. If you can
: 't find a flaw from my design, just shut the fuck up.
|
g*****g
发帖数: 34805 | 58 Not websites, mobile app backend. I don't want to name them because I don't
want to be renrou. It's a discussion of technology, not personal background.
I've been around long enough to earn my credit here, unlike you.
【在 l*****9 的大作中提到】
: You said you designed website handling bigger daily traffic than Obamacare
: website need to handle, that's a big claim without proof, and it is called
: bragging
:
: can
|
l*****9
发帖数: 9501 | 59 mobile app backend is totally different from Obamacare website. you keep
changing your story, and only yourself claim credit.
t
background.
【在 g*****g 的大作中提到】
: Not websites, mobile app backend. I don't want to name them because I don't
: want to be renrou. It's a discussion of technology, not personal background.
: I've been around long enough to earn my credit here, unlike you.
|
P********l
发帖数: 452 | 60 why desktop app & Mobile app are "totally" different?
【在 l*****9 的大作中提到】
: mobile app backend is totally different from Obamacare website. you keep
: changing your story, and only yourself claim credit.
:
: t
: background.
|
|
|
g*****g
发帖数: 34805 | 61 You lack the basic knowledge of scalability. There's no difference beyond
front end between web app and mobile app. And high volume system's
bottleneck always happen on DB, front end doesn't really matter.
【在 l*****9 的大作中提到】
: mobile app backend is totally different from Obamacare website. you keep
: changing your story, and only yourself claim credit.
:
: t
: background.
|
l*****9
发帖数: 9501 | 62 You have no idea about UI and web server.
【在 g*****g 的大作中提到】
: You lack the basic knowledge of scalability. There's no difference beyond
: front end between web app and mobile app. And high volume system's
: bottleneck always happen on DB, front end doesn't really matter.
|
g*****g
发帖数: 34805 | 63 lol, scalability is never an issue on front tier.
【在 l*****9 的大作中提到】
: You have no idea about UI and web server.
|
l*****9
发帖数: 9501 | 64 无知是福
【在 g*****g 的大作中提到】
: lol, scalability is never an issue on front tier.
|
g*****g
发帖数: 34805 | 65 Talk to me when you have architect in your job title. I don't know
why you are trying to hold on when I've showed you a superior system.
【在 l*****9 的大作中提到】
: 无知是福
|
f******h
发帖数: 9 | 66 各位轻松一下，来点light reading, 看看“专家”们怎样讲......
http://www.reuters.com/article/2013/10/05/us-usa-healthcare-tec
很好奇这一段：怎样才能制造出这个错误呢？
Many users experienced problems involving security questions they had to
answer in order to create an account on HealthCare.gov. No questions
appeared in the boxes, or an error message said they were using the same
answers for different questions when they were not.
No questions appeared: 可能是DB connection问题，没有记录返回；
they were using the same answers for different questions when they were not
：好奇中。 |
P********l
发帖数: 452 | 67 这有啥好奇的? 不就是一个bug吗?
not
【在 f******h 的大作中提到】
: 各位轻松一下，来点light reading, 看看“专家”们怎样讲......
: http://www.reuters.com/article/2013/10/05/us-usa-healthcare-tec
: 很好奇这一段：怎样才能制造出这个错误呢？
: Many users experienced problems involving security questions they had to
: answer in order to create an account on HealthCare.gov. No questions
: appeared in the boxes, or an error message said they were using the same
: answers for different questions when they were not.
: No questions appeared: 可能是DB connection问题，没有记录返回；
: they were using the same answers for different questions when they were not
: ：好奇中。
|
f******h
发帖数: 9 | 68 在想这个bug的“机制”是什么。得怎么胡搞才能让它有时候work，有时候不work. |
l*****9
发帖数: 9501 | 69 吹牛历来是你的利器。换个马甲再来吹
【在 g*****g 的大作中提到】
: Talk to me when you have architect in your job title. I don't know
: why you are trying to hold on when I've showed you a superior system.
|
