l*****b
发帖数: 82 | 1 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 | X****r
发帖数: 3557 | 2 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
| g**e
发帖数: 6127 | 3 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
| l*****b
发帖数: 82 | 4 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
| l*****b
发帖数: 82 | 5 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.
| X****r
发帖数: 3557 | 6 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.
| g**e
发帖数: 6127 | 7 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
| l*****b
发帖数: 82 | 8 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
|
|
