13:00:46 #startmeeting monasca 13:00:47 Meeting started Tue Feb 11 13:00:46 2020 UTC and is due to finish in 60 minutes. The chair is witek. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:50 The meeting name has been set to 'monasca' 13:00:56 hello everyone 13:01:02 Hi 13:01:05 Hello 13:01:08 hi 13:01:45 the agenda seems to be light 13:01:49 https://etherpad.openstack.org/p/monasca-team-meeting-agenda 13:01:55 let's start 13:02:04 #topic ujson replacement 13:02:47 I've sent a question to requirements team at openstack-discuss 13:02:56 http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012376.html 13:03:59 orjson seems not to be the good option for including into global requirements 13:04:10 because of complicated build process 13:04:52 do we have any performance evaluation results already? 13:05:24 I compared ujson, json and simplejson in devstack 13:05:48 all these are available in devstack already 13:06:21 This is the way I did the checks: 13:06:37 1. After stacking devstack, I stopped the log-agent, metric-agent and the persister. 13:06:50 2. I modified the scale_perf/agent_simulator.py from Monasca-perf in order to work with devstack. 13:07:06 3. I sent 690 calls with 1000 points each one using 4 Python Processes. Every point had this form: 13:07:18 {'dimensions': {'cloud_name': 'monasca', 13:07:18 'cluster': 'compute', 13:07:18 'component': 'vm', 13:07:18 'container': 'container_0', 13:07:18 'control_plane': 'ccp', 13:07:19 'hostname': 'agent_0', 13:07:20 'resource_id': '34c0ce14-9ce4-4d3d-84a4-172e1ddb26c4', 13:07:22 'service': 'service_0', 13:07:24 'tenant_id': '71fea2331bae4d98bb08df071169806d', 13:07:28 'zone': 'nova'}, 13:07:30 'name': 'aaa.perf_428', 13:07:32 'timestamp': 1581424933000, 13:07:34 'value': 781} 13:07:40 where: 'name' can be [aaa.perf_000 to aaa.perf_999] 13:07:54 'value' a randon [000 to 999] 13:08:03 and 'hostname': ['agent_0' to 'agent_3'] 13:08:20 This point is quite similar to those we have in production. 13:08:37 Cardinality: 1000 metrics X 4 agents X 1 containers X 1 services = 4000 13:08:50 4. Changed from 30 to 1000 the batch_size of the metrics in the persister 13:09:07 5. Set a log.warn in the json.loads https://github.com/openstack/monasca-persister/blob/master/monasca_persister/repositories/utils.py#L21 13:09:57 6. Started the persister manually redirecting the output to a file waiting to consume all the 690000 points waiting in kafka. 13:10:26 7. Checked the time difference in the log from the first deserialization (log.warn) to the last. 13:11:21 I repeated the process for simplejson and json, by changing the import at 13:11:27 https://github.com/openstack/monasca-persister/blob/master/monasca_persister/repositories/utils.py#L16 13:12:21 The results: json took 2 min 20 sec in the first test and 2 min 22 sec in the second test. 13:13:02 ujson took 1 min 53 sec in the first test and 1 min 51 in the second 13:13:23 simplejson took 1 min 59 in both tries. 13:14:52 from this test simplejson seems to be a good compromise 13:15:15 and at least in devstack is already available without any change 13:16:09 we could test rapidjson as well, but I don't expect it to be much faster the ujson 13:16:32 Yes, I have all the mini-infrastructure to test it 13:17:22 *Note that I only tested the deserialization (json.loads), I left the serialization (json.dumps) using ujson. 13:17:36 https://github.com/openstack/monasca-persister/blob/a4addd0f5e8c60f631a77fd280f2810b8f222203/monasca_persister/repositories/influxdb/metrics_repository.py#L48 13:18:47 that's fine, we were interested in deserialization because of persister beeing the bottleneck 13:18:55 cool 13:20:26 any other comments on that? 13:21:01 well, it's good if there is no need to add it to global requirements and is fast enough 13:21:49 agree 13:22:15 Probably the profiling test in the internet show differences because of the size of the string to be deserializated. 13:22:27 *tests 13:22:48 sure, it depends strongly on the structure of the object 13:23:38 yes like the nesting level of the object 13:24:10 Besides of the dimensions: we use a 'flat' object 13:25:23 so do we agree on using simplejson, or do you still want to test rapidjson as well? 13:26:10 can rapidjson be installed easy-way with pip? 13:26:19 I think simplejson should be good enough 13:26:21 I can do the check just after the meeting 13:29:10 I'm fine with simplejson as well, we can still change it in future if proves to cause any problems 13:29:44 #topic aob 13:29:58 do we have any other topics for today? 13:30:38 no from my part 13:31:42 OK, let's wrap it up then 13:31:52 thanks for joining 13:31:57 and for the tests 13:32:04 thanks 13:32:10 see you next time 13:32:10 thank you 13:32:11 Thanks, bye everybody 13:32:19 #endmeeting