Redian新闻
>
A programming interview question
avatar
A programming interview question# Programming - 葵花宝典
n*8
1
【 以下文字转载自 Immigration 讨论区 】
发信人: n158 (土人), 信区: Immigration
标 题: 求教 关于485申请的G1145
发信站: BBS 未名空间站 (Sun Feb 22 14:38:26 2015, 美东)
请问大侠,
G1145 form 是不是不适用于 寄到dallas的uscis center的485申请?
非常感谢!
avatar
J*i
2
avatar
c*y
3
跟“金婚”一样, 张国立和宋丹丹演军婚两口子。
avatar
l*b
4
Hi, friends,
Provided:
1. A server to handle requests by attaching them with keys
2. Incoming request speed is 40 - 80 requests/per second
3. Server pre generate 5000 keys in startup
4. Server attach one key for each request
5. each key will be deleted once it is used
6. Server will re-generate the new keys periodically
Questions
1. What data sturcture to store the keys in server
2. What criteria (when, how) to regenerate the new keys
my conservative idea at that time:
1. maintain a queue struct
avatar
f*u
5
为啥这么说?寄到哪里都不一定有用的。
avatar
c*y
6
怎么没人看啊? 喜欢看金婚的人呢, 一定会喜欢的!
avatar
X*r
7
Your answer could work, however, you probably want
to probe the interviewer (as you would try to discover
in a real project) for what is the real technical difficulty
in the requirement. It is not obvious from your description.
Is that generating keys is expensive/difficult, or there is a
limit on how many of them can be generated in a given
time so keys must be conserved? Alternatively, is that we
want to minimize response latency that as little time spent
on handling keys while processing requ

【在 l*****b 的大作中提到】
: Hi, friends,
: Provided:
: 1. A server to handle requests by attaching them with keys
: 2. Incoming request speed is 40 - 80 requests/per second
: 3. Server pre generate 5000 keys in startup
: 4. Server attach one key for each request
: 5. each key will be deleted once it is used
: 6. Server will re-generate the new keys periodically
: Questions
: 1. What data sturcture to store the keys in server

avatar
g*e
8
I would also suggest use load factor instead of generate keys after certain
seconds.

【在 X****r 的大作中提到】
: Your answer could work, however, you probably want
: to probe the interviewer (as you would try to discover
: in a real project) for what is the real technical difficulty
: in the requirement. It is not obvious from your description.
: Is that generating keys is expensive/difficult, or there is a
: limit on how many of them can be generated in a given
: time so keys must be conserved? Alternatively, is that we
: want to minimize response latency that as little time spent
: on handling keys while processing requ

avatar
l*b
9
Thanks for reply, Xentar.
Right, I just put some briefing of the description. It has condition that
the key gen has expensive consuming, e.g. 1.5 seconds exclusive to generate
one key (single thread mode). that is why to pre gen certain amount keys
initially. I was thinking to have the key regen and request handling in
separated two threads to improve the response. Any comments? Thanks.

【在 X****r 的大作中提到】
: Your answer could work, however, you probably want
: to probe the interviewer (as you would try to discover
: in a real project) for what is the real technical difficulty
: in the requirement. It is not obvious from your description.
: Is that generating keys is expensive/difficult, or there is a
: limit on how many of them can be generated in a given
: time so keys must be conserved? Alternatively, is that we
: want to minimize response latency that as little time spent
: on handling keys while processing requ

avatar
l*b
10
Hi, gate, may i have more details of load factor approach? Thank you.

certain

【在 g**e 的大作中提到】
: I would also suggest use load factor instead of generate keys after certain
: seconds.

avatar
X*r
11
Of course, key generation and request handling would be in different
threads if the former is expensive. But it is still unclear what kind
of price we're paying for key generation. For example, if it is
CPU-bounded then 1.5s per key would not meet 40-80 qps, even if you
consider multi-core. If this is the case we'll have to let some other
dedicated computing cluster to generate the key. On the other hand,
if 1.5s is simply wait for something else to happend (e.g. some
physical device) and each t

【在 l*****b 的大作中提到】
: Thanks for reply, Xentar.
: Right, I just put some briefing of the description. It has condition that
: the key gen has expensive consuming, e.g. 1.5 seconds exclusive to generate
: one key (single thread mode). that is why to pre gen certain amount keys
: initially. I was thinking to have the key regen and request handling in
: separated two threads to improve the response. Any comments? Thanks.

avatar
g*e
12
you can take a look at HashMap.java to get an idea about load factor.
basically you can use it as threshold which triggers key generation.

【在 l*****b 的大作中提到】
: Hi, gate, may i have more details of load factor approach? Thank you.
:
: certain

avatar
l*b
13
Thanks for your idea, Xentar. I was just thinking this is a interested topic
and we could have some brainstorm on those provided precondition. Thanks
again.

【在 X****r 的大作中提到】
: Of course, key generation and request handling would be in different
: threads if the former is expensive. But it is still unclear what kind
: of price we're paying for key generation. For example, if it is
: CPU-bounded then 1.5s per key would not meet 40-80 qps, even if you
: consider multi-core. If this is the case we'll have to let some other
: dedicated computing cluster to generate the key. On the other hand,
: if 1.5s is simply wait for something else to happend (e.g. some
: physical device) and each t

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。