Closed HigashikataZhangsuke closed 3 months ago
Plan:
- Shift code for all functions -> 20min 1.5 Prepare all environments for every function -> ~30min
- Share part code + deal with profiling data-> 2h
- Ex Part code -> 3h
- Test for Ex+Sh+multiple function -> 2h
Additional notes: Note that when testing, broker,trigger need to change to the aligned version. Yesterday when I did the test the broker-trigger still used alu function's, but for final test we should not use this, remember you get throughput drop if you use one line to route all traffic.(Actually maybe only the high rate trace will suffer).
We may need a new node for running codes. The disk pressure is a little bit big.
1 finished.
Plan:
- Shift code for all functions -> 20min 1.5 Prepare all environments for every function -> ~30min
- Share part code + deal with profiling data-> 2h
- Ex Part code -> 3h
- Test for Ex+Sh+multiple function -> 2h
Additional notes: Note that when testing, broker,trigger need to change to the aligned version. Yesterday when I did the test the broker-trigger still used alu function's, but for final test we should not use this, remember you get throughput drop if you use one line to route all traffic.(Actually maybe only the high rate trace will suffer).
We may need a new node for running codes. The disk pressure is a little bit big.
1.5 finished
Plan:
- Shift code for all functions -> 20min 1.5 Prepare all environments for every function -> ~30min
- Share part code + deal with profiling data-> 2h
- Ex Part code -> 3h
- Test for Ex+Sh+multiple function -> 2h
Additional notes: Note that when testing, broker,trigger need to change to the aligned version. Yesterday when I did the test the broker-trigger still used alu function's, but for final test we should not use this, remember you get throughput drop if you use one line to route all traffic.(Actually maybe only the high rate trace will suffer).
We may need a new node for running codes. The disk pressure is a little bit big.
One step forget: should let all codes can record the resource amount you used Also add to flask and all other code: log the time the req is sent into the system
For 2, we need to provide the execution latency. If we find out that Due to a high rate, we have to use all resources on this node and Sh's execution latency + queueing is too long, then it is time for scaling up. So just need to record the most recent E-E latency here. 2Finished
Plan:
Additional notes: Note that when testing, broker,trigger need to change to the aligned version. Yesterday when I did the test the broker-trigger still used alu function's, but for final test we should not use this, remember you get throughput drop if you use one line to route all traffic.(Actually maybe only the high rate trace will suffer).
We may need a new node for running codes. The disk pressure is a little bit big.
One step forget: should let all codes can record the resource amount you used -> should use invoker to record this. It has the mask information. Also add to flask and all other code: log the time the req is sent into the system Should only modify curl. not flask UUIDs for Sh. And Sh/IsoInvoker/VM is one one mapping so this is also the unique ID. -> This is Done. Now turn back to modity the flask and Ex codes.
Fixed the three additional problems.