带你读《云原生机密计算最佳实践白皮书》——Apache_Teaclave_ Java_TEE_SDK 最佳实践(4)

简介: 带你读《云原生机密计算最佳实践白皮书》——Apache_Teaclave_ Java_TEE_SDK 最佳实践(4)

《云原生机密计算最佳实践白皮书》——05编程框架——Apache Teaclave Java TEE SDK: 面向Java生态的机密计算编程框架——Apache_Teaclave_ Java_TEE_SDK 最佳实践(3) https://developer.aliyun.com/article/1231434?groupCode=aliyun_linux




3.3 运行tests

cd /opt/javaenclave/test && ./run.sh
...........
.enter test case: org.apache.teaclave.javasdk.test.host.TestSMEnclave
exit test case: org.apache.teaclave.javasdk.test.host.TestSMEnclave
.enter test case: org.apache.teaclave.javasdk.test.host.TestSMEnclave
exit test case: org.apache.teaclave.javasdk.test.host.TestSMEnclave
.enter test case: org.apache.teaclave.javasdk.test.host.TestSMEnclave
exit test case: org.apache.teaclave.javasdk.test.host.TestSMEnclave
Time: 109.616
OK (16 tests)
Teaclave java sdk ut result: true

3.4 运行benchmark

cd /opt/javaenclave/benchmark

运行 Guomi Benchmark:

cd guomi && ./run.sh
REMEMBER: The numbers below are just data. To gain reusable insights, you need to follow up on
why the numbers are the way they are. Use profifilers (see -prof, -lprof), design factorial
experiments, perform baseline and negative tests that provide experimental control, make sure
the benchmarking environment is safe on JVM/OS/HW level, ask for reviews from the domain experts.
Do not assume the numbers tell you what you want them to tell.
Benchmark (enclaveServiceInstance) (smAlgo) Mode Cnt Score Error Units
GuoMiBenchMark.smBenchMark MOCK_IN_JVM SM2 avgt 4 39.032 ? 39.471 ms/op
GuoMiBenchMark.smBenchMark MOCK_IN_JVM SM3 avgt 4 8.656 ? 0.302 ms/op
GuoMiBenchMark.smBenchMark MOCK_IN_JVM SM4 avgt 4 3.410 ? 0.153 ms/op
GuoMiBenchMark.smBenchMark MOCK_IN_SVM SM2 avgt 4 31.899 ? 1.003 ms/op
GuoMiBenchMark.smBenchMark MOCK_IN_SVM SM3 avgt 4 10.755 ? 2.616 ms/op
GuoMiBenchMark.smBenchMark MOCK_IN_SVM SM4 avgt 4 4.515 ? 0.303 ms/op
GuoMiBenchMark.smBenchMark TEE_SDK SM2 avgt 4 36.113 ? 2.337 ms/op
GuoMiBenchMark.smBenchMark TEE_SDK SM3 avgt 4 11.331 ? 1.379 ms/op
GuoMiBenchMark.smBenchMark TEE_SDK SM4 avgt 4 10.292 ? 0.896 ms/op
GuoMiBenchMark.smBenchMark EMBEDDED_LIB_OS SM2 avgt 4 32.058 ? 14.033 ms/op
GuoMiBenchMark.smBenchMark EMBEDDED_LIB_OS SM3 avgt 4 10.380 ? 0.741 ms/op
GuoMiBenchMark.smBenchMark EMBEDDED_LIB_OS SM4 avgt 4 9.190 ? 0.488 ms/op
Benchmark result is saved to guomi_benchmark.json

运行 String Benchmark:

cd string && ./run.sh
REMEMBER: The numbers below are just data. To gain reusable insights, you need to follow up on
why the numbers are the way they are. Use profifilers (see -prof, -lprof), design factorial
experiments, perform baseline and negative tests that provide experimental control, make sure
the benchmarking environment is safe on JVM/OS/HW level, ask for reviews from the domain experts.
Do not assume the numbers tell you what you want them to tell.
Benchmark (enclaveServiceInstance) (stringOpt) Mode Cnt Score Error Units
StringBenchMark.stringBenchMark MOCK_IN_JVM regex avgt 4 2.788 ? 0.090 ms/op
StringBenchMark.stringBenchMark MOCK_IN_JVM concat avgt 4 2.692 ? 0.139 ms/op
StringBenchMark.stringBenchMark MOCK_IN_JVM split avgt 4 2.698 ? 0.129 ms/op
StringBenchMark.stringBenchMark MOCK_IN_SVM regex avgt 4 4.558 ? 0.084 ms/op
StringBenchMark.stringBenchMark MOCK_IN_SVM concat avgt 4 4.879 ? 0.200 ms/op
StringBenchMark.stringBenchMark MOCK_IN_SVM split avgt 4 5.595 ? 0.186 ms/op
StringBenchMark.stringBenchMark TEE_SDK regex avgt 4 5.377 ? 0.176 ms/op
StringBenchMark.stringBenchMark TEE_SDK concat avgt 4 5.269 ? 0.119 ms/op
StringBenchMark.stringBenchMark TEE_SDK split avgt 4 6.171 ? 0.403 ms/op
StringBenchMark.stringBenchMark EMBEDDED_LIB_OS regex avgt 4 4.104 ? 0.992 ms/op
StringBenchMark.stringBenchMark EMBEDDED_LIB_OS concat avgt 4 6.140 ? 0.278 ms/op
StringBenchMark.stringBenchMark EMBEDDED_LIB_OS split avgt 4 4.305 ? 0.585 ms/op
Benchmark result is saved to string_benchmark.json




《云原生机密计算最佳实践白皮书》——05编程框架——Apache Teaclave Java TEE SDK: 面向Java生态的机密计算编程框架——Apache_Teaclave_ Java_TEE_SDK 最佳实践(5) https://developer.aliyun.com/article/1231430?groupCode=aliyun_linux


相关实践学习
CentOS 7迁移Anolis OS 7
龙蜥操作系统Anolis OS的体验。Anolis OS 7生态上和依赖管理上保持跟CentOS 7.x兼容,一键式迁移脚本centos2anolis.py。本文为您介绍如何通过AOMS迁移工具实现CentOS 7.x到Anolis OS 7的迁移。
相关文章
|
1月前
|
运维 Cloud Native 云计算
云原生技术:探索未来计算的无限可能
【10月更文挑战第8天】 云原生技术,作为云计算领域的一次革新性突破,正引领着企业数字化转型的新浪潮。它不仅重塑了应用的构建、部署和运行方式,还通过极致的弹性、敏捷性和可扩展性,解锁了未来计算的无限潜力。本文将深入浅出地解析云原生技术的核心理念、关键技术组件及其在不同行业中的实际应用案例,展现其如何赋能业务创新,加速企业的云化之旅。
55 7
|
11天前
|
存储 分布式计算 Java
存算分离与计算向数据移动:深度解析与Java实现
【11月更文挑战第10天】随着大数据时代的到来,数据量的激增给传统的数据处理架构带来了巨大的挑战。传统的“存算一体”架构,即计算资源与存储资源紧密耦合,在处理海量数据时逐渐显露出其局限性。为了应对这些挑战,存算分离(Disaggregated Storage and Compute Architecture)和计算向数据移动(Compute Moves to Data)两种架构应运而生,成为大数据处理领域的热门技术。
32 2
|
15天前
|
分布式计算 Java MaxCompute
ODPS MR节点跑graph连通分量计算代码报错java heap space如何解决
任务启动命令:jar -resources odps-graph-connect-family-2.0-SNAPSHOT.jar -classpath ./odps-graph-connect-family-2.0-SNAPSHOT.jar ConnectFamily 若是设置参数该如何设置
|
26天前
|
Kubernetes Cloud Native 开发者
探秘云原生计算:Kubernetes与Docker的协同进化
在这个快节奏的数字时代,云原生技术以其灵活性和可扩展性成为了开发者们的新宠。本文将带你深入了解Kubernetes和Docker如何共同塑造现代云计算的架构,以及它们如何帮助企业构建更加敏捷和高效的IT基础设施。
|
1月前
|
机器学习/深度学习 算法 搜索推荐
让星星⭐月亮告诉你,Java冒泡排序及其时间复杂度计算
冒泡排序是一种简单的排序算法,通过多次遍历数组,每次比较相邻元素并交换位置,将较小的元素逐步移至数组前端。第一轮结束后,最小值会位于首位;第二轮则将次小值置于第二位,依此类推。经过 (n-1) 轮遍历后,数组完成排序。冒泡排序的时间复杂度为 O(n²),在最优情况下(已排序数组)时间复杂度为 O(n)。示例代码展示了如何实现冒泡排序。
49 1
|
15天前
|
Java API Apache
java集合的组内平均值怎么计算
通过本文的介绍,我们了解了在Java中计算集合的组内平均值的几种方法。每种方法都有其优缺点,具体选择哪种方法应根据实际需求和场景决定。无论是使用传统的循环方法,还是利用Java 8的Stream API,亦或是使用第三方库(如Apache Commons Collections和Guava),都可以有效地计算集合的组内平均值。希望本文对您理解和实现Java中的集合平均值计算有所帮助。
23 0
|
1月前
|
分布式计算 资源调度 Hadoop
Hadoop-10-HDFS集群 Java实现MapReduce WordCount计算 Hadoop序列化 编写Mapper和Reducer和Driver 附带POM 详细代码 图文等内容
Hadoop-10-HDFS集群 Java实现MapReduce WordCount计算 Hadoop序列化 编写Mapper和Reducer和Driver 附带POM 详细代码 图文等内容
88 3
|
1月前
|
消息中间件 Java Kafka
Flink-04 Flink Java 3分钟上手 FlinkKafkaConsumer消费Kafka数据 进行计算SingleOutputStreamOperatorDataStreamSource
Flink-04 Flink Java 3分钟上手 FlinkKafkaConsumer消费Kafka数据 进行计算SingleOutputStreamOperatorDataStreamSource
46 1
|
3月前
|
运维 Cloud Native 云计算
云原生架构的演进:从微服务到无服务器计算
在数字化转型的浪潮中,云原生技术以其灵活性、可扩展性和成本效益性,成为推动现代软件开发和运维的关键力量。本文将探讨云原生概念的演变,特别是从微服务架构到无服务器计算的转变,揭示这一进化如何影响应用程序的开发、部署和管理。通过分析实际案例,我们旨在提供对云原生技术未来趋势的洞察,同时指出企业在这一转变过程中可能面临的挑战和机遇。
48 2
|
4月前
|
运维 Cloud Native 持续交付
云原生架构的演进:从微服务到无服务器计算
【7月更文挑战第28天】在数字化浪潮的推动下,云原生技术不断演进,引领着软件开发和运维模式的革新。本文将深入探讨云原生架构的发展历程,着重分析微服务架构与无服务器计算模型如何相互补充,共同推动现代应用的开发与部署。我们将从微服务的基本原则出发,探索其如何赋能团队快速迭代和扩展应用,进而阐述无服务器计算如何简化资源管理,降低运营成本。通过对比分析,揭示两者结合的优势,为读者提供构建未来云原生应用的洞见。

推荐镜像

更多