<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    Bryan

      BlogJava :: 首頁 :: 聯(lián)系 :: 聚合  :: 管理
      37 Posts :: 3 Stories :: 24 Comments :: 0 Trackbacks
    I have encountered sereval performance issues during my projects in the past several years and now I try to list them so that I will not forget them or sometimes I can pick it up for a reference.

    1. During the idol/CFS/lua development, once, a client asked me why there are some documents which they changed is lost in idol database, and we try to troubleshoot it and found the processing time for some lua script are taking days, so we try to optimize the lua query by adding fields to matchindex which is sent to idol to reduce response time.

    2. There is a program which needs to sync all the data from one idol database to another idol database, and the developers trying to add thousands of xml documents to the ResultList and we found the speed is becoming slow and slow and with more time, we found the equal/hashcode affecting the performance a lot and finally, we try to remove the function and found they are working well(temp solution).

    public class ResultListCustom extends ResultList {

        
    private ArrayList _alDocuments = new ArrayList();

        
    /**
         * remove the duplicates condition
         
    */
        @Override
        
    public void addDocument(ResultDocument document) {
            
    if (document != null) {
                _alDocuments.add(document);
            }
        }

        @Override
        
    public void removeDocument(
                com.autonomy.aci.businessobjects.Document document) {
            
    if (document != null) {
                
    int nDocIdx = this._alDocuments.indexOf(document);
                
    if (nDocIdx != -1) {
                    
    this._alDocuments.remove(nDocIdx);
                }
            }
        }

        @Override
        
    public void clearDocuments() {
            
    this._alDocuments.clear();
        }

        @Override
        
    public ArrayList getDocuments() {
            
    return (ArrayList) this._alDocuments.clone();
        }

        @Override
        
    public Iterator iterator() {
            
    return this._alDocuments.iterator();
        }

        @Override
        
    public int getDocumentCount() {
            
    return this._alDocuments.size();
        }
    }


    3. Once for our enovia system, a client try to search for data with description * in search field and then we found the java process memory increased all the time and finally the application crashed. and we have analyzed this problem, but could not resolve it and finally, this problem is resolved by ds (a company) by adding index to the field description.

    4.For all the fields which we need to query with match in idol, we need to add this field to match index, and for all the parametric fields for refinement, we need to add to the parametric index and this way will optimize all the queries and ensure the less response time. also when you idol database deletes document too often, you need to do compact operations to optimize the idol database performance also.

    5. We have some lua scripts which read a excel file and build a record for each of line and then send to idol, this works well in our old cfs version, but when we upgraded to 11.0 version, we found the CFS queue is becoming slow and slow and the lua script will also take days to finish. and we raised this problem to idol team and finally they said we have to send the documents with lua to idol in batches. and we did that and performances changed a lot. but they still could not answer why sometimes the performance is slow when we send document one by one to cfs.

    6. Usually, connectors crawls data from different repository and then ingest the messages into CFS in batches and this improved performance , during our java developement we should also use this strategy, sending documents to idol in batches, including dreadd, drereplace, and dredelete operations.

    For example, the format below to support batches of idx files for drereplace
    #DREDOCREF 30036.20391.35739.7275
    #DREFIELDNAME SEARCH-RESULTS/DOCUMENT/CSI_RATING_FORECAST
    #DREFIELDVALUE ANVGRP:1,WRLS:1
    #DREFIELDNAME SEARCH-RESULTS/DOCUMENT/COMCODEID
    #DREFIELDVALUE SRDE10:3596831,ANVGRP:3596831
    #DREDOCREF 30036.20391.35739.7274
    #DREFIELDNAME SEARCH-RESULTS/DOCUMENT/CSI_RATING_FORECAST
    #DREFIELDVALUE ANVGRP:1,WRLS:1
    #DREFIELDNAME SEARCH-RESULTS/DOCUMENT/COMCODEID
    #DREFIELDVALUE SRDE10:3596831,ANVGRP:3596831
    #DREENDDATA

    7. when we upgraded enovia connector to version v11.2.0.1279850 and for one of our enovia connector the memory is alway increasing with the time passing, we also raised this problem to idol team and also install valgrind tool to help analyze the memroy problem and then send the logs to idol team, but still they could not ensure whether they can solve the problem or not as this is not reproduced in their application.
    posted on 2017-08-16 09:08 Life is no respector of any genius. 閱讀(183) 評論(0)  編輯  收藏

    只有注冊用戶登錄后才能發(fā)表評論。


    網(wǎng)站導(dǎo)航:
     
    主站蜘蛛池模板: 亚洲精品在线免费看| 亚洲2022国产成人精品无码区| 99免费观看视频| 一级做a爰黑人又硬又粗免费看51社区国产精品视 | 亚洲美女视频一区| 亚洲性日韩精品国产一区二区| 一二三四在线观看免费高清中文在线观看 | 91在线亚洲精品专区| 亚洲综合色婷婷七月丁香| 真实乱视频国产免费观看| 永久在线免费观看| 久久国产乱子精品免费女| 九九久久精品国产免费看小说| 亚洲一区二区三区国产精华液| 久久亚洲精品人成综合网| 亚洲精品无码久久久久| 亚洲AV无码乱码精品国产| 四虎成人精品一区二区免费网站| 最近中文字幕完整版免费高清| 中文字幕无码毛片免费看| 特级毛片A级毛片100免费播放| 亚洲一区二区无码偷拍| 亚洲一区二区三区无码国产| 777亚洲精品乱码久久久久久| 亚洲精品无码不卡在线播HE| 中文字幕不卡亚洲| 久久精品亚洲乱码伦伦中文| 伊人久久亚洲综合影院| 日本免费人成黄页在线观看视频| 性盈盈影院免费视频观看在线一区| 2021久久精品免费观看| 无人在线观看完整免费版视频| 99久久免费国产香蕉麻豆| 日本黄网站动漫视频免费| 2020因为爱你带字幕免费观看全集| 免费无码成人AV在线播放不卡| 无码av免费一区二区三区试看| 无码专区AAAAAA免费视频| 亚洲一区二区在线免费观看| 91麻豆国产免费观看| 亚洲精品免费网站|