SKY(364110847) 16:42:47
大家讨论下开发机爆慢的处理思路啊？
SKY(364110847) 16:43:25
我现在也遇到开发机暴慢的问题 很纠结
v_学者(185563766) 16:43:44
你内存多大？
我D系统只有可怜的16G
s
原创
2013-03-20 17:26:17
715阅读
SAP MM 进销存报表优化小记 笔者刚刚加入SY项目，就接到了SY集团上海总部SAP运维部门负责人的工作分配，说是有一只进销存报表，需要做一个优化，可能是需要重新设计重新开发。 笔者研究了
原创
2018-07-21 08:37:42
1243阅读
实际项目实施过程中，我们会遇到程序性能优化的问题，这里介绍一种方法：通过RFC接口进行远程函数的异步调用实现程序的并行处理。 同步/异步调用函数语法同步调用：CALL FUNCTION同步调用的实质：程序进行单线程执行。异步调用：CALL FUNCTION 'AAA' STARTING NEWTASK <taskname> "任务名称DE
转载
2023-09-18 12:03:35
1504阅读
Please note that concurrency: 50 (in SsrOptimizationOptions) means that OptimizedSsrEngine will perform at most 50 p
原创
2022-03-16 10:26:05
26阅读
Thursday, February 18, 2016 8:31 PM
优化完之后，系统AFF我的user，取356个Opportunity的documentItems，从以前的44秒缩短到3.8秒。
优化之后的docItem主方法就两行代码，
性能提高了10倍的原因是因为我没有再使用one order的API去取每个field，而是用OPEN SQL直接取表。
测试的时候发现一个bug，CU
原创
2021-07-13 11:38:37
28阅读
，这意味着Retrieve的输入参数不同，后台编译生成的ABAP方法也不同。如何优化：还是一样的思路：在line 29声明一个行类型为ID的容器...
原创
2021-07-14 15:51:23
89阅读
Pricing currency的bug今天也fix了，356个Opportunity取document Items需要2.8~3秒。Pricing table和one order table的关联关系和其他字段稍有不同，中间通过CRMD_LINK的guid_set进行连接，因此不方便写到一个SQL里，所有我最后的solution 通过两个独立的SQL来实现。单元测试里COMPARE_PR...
原创
2021-07-15 13:34:21
47阅读
在GM6没有设延时的前提下，性能大概提高了100毫秒。（我在GM6的launchpad里一共测试了10次，分别记录下两个service的消耗时间，两个service取的task个数都为11个。X 轴代表第N次测试）。原始数据如下：要获取更多Jerry的原创文章，请关注公众号"汪子熙":...
原创
2021-07-13 11:43:57
52阅读
Please note that concurrency: 50 (in SsrOptimizationOptions) means that OptimizedSsrEngine will perform at most 50 parallel rendering tasks.With the
原创
2021-10-08 15:27:38
48阅读
Thursday, February 18, 2016 8:31 PM优化完之后，系统AFF我的user，取356个Opportunity的documentItems，从以前的44秒缩短到3.8秒。优化之后的docItem主方法就两行代码，性能提高了10倍的原因是因为我没有再使用one order的API去取每个field，而是用OPEN SQL直接取表。测试的时候发现一个bug，CURRENCY
原创
2022-04-08 11:27:37
177阅读
此文系笔者原创，首发于AZSAP第一课堂 https://mp.weixin.qq.com/s/9yuDJohp1iNRR-hHTyT9WQ 上半年，笔者刚刚加入某运维项目，就接到了该项目客户中国总部SAP运维部门负责人的工作分配，说是让我帮忙优化一只进销存报表，很可能是需要重新设计重新开发。
原创
2018-07-30 08:09:00
321阅读
1.使用正确的表。SAP有标准的索引表或者VIEW。参见sap notes 185530/191492/18
转载
2022-07-27 23:00:08
288阅读
在GM6没有设延时的前提下，性能大概提高了100毫秒。（我在GM6的launchpad里一共测试了10次，分别记录下两个service的消耗时间，两个service取的task个数都为11个。X 轴代表第N次测试）。原始数据如下：要获取更多Jerry的原创文章，请关注公众号"汪子熙":
原创
2022-04-08 11:39:02
120阅读
这是优化前的代码，可以看到ServiceRequest.Retrieve在foreach循环里被调用 。 如何优化： 其实在PDI里有提示。在ServiceRequest后面敲个“。”，触发代码自动完成功能，可以看到Retrieve方法有三个重载，这意味着Retrieve的输入参数不同，后台编译生成
原创
2021-10-22 14:14:55
30阅读
这是优化前的代码，可以看到ServiceRequest.R
原创
2022-04-14 16:53:50
50阅读
Pricing currency的bug今天也fix了，356个Opportunity取document Items需要2.8~3秒。Pricing table和one order table的关联关系和其他字段稍有不同，中间通过CRMD_LINK的guid_set进行连接，因此不方便写到一个SQL里，所有我最后的solution 通过两个独立的SQL来实现。单元测试里COMPARE_PR...
原创
2022-04-15 11:35:51
121阅读
https://github.com/SAP/spartacus/issues/3649SAP Commerce Cloud CMS 页面加载的一些优化点
原创
2021-07-12 14:07:10
89阅读
Recently I am responsible for the performance optimization of one API which retrieves application logs of the given one order documents. API Requireme
原创
2021-10-22 11:27:51
76阅读
guids, and output are all the application logs belon
原创
2021-07-14 10:44:27
129阅读
问题和观察关于由Spartacus驱动的页面或组件请求的一个疑问。请求负载中的componentIds是由CmsService.getComponentData调用定义的，堆叠起来，然后通过一些优化立即发送到后端。如果二次开发人员连续多次调用CmsService.getComponentData（在同一个JS宏任务中），那么Spartacus会将这些调用分组，并且仅向OCC发出一个带有所有组件ID
原创
2022-06-13 10:53:01
439阅读
