<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. 閱讀(191) 評(píng)論(0)  編輯  收藏

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


    網(wǎng)站導(dǎo)航:
     
    主站蜘蛛池模板: 免费国产黄网站在线看| 亚洲综合在线另类色区奇米| 亚洲美女视频网站| 成av免费大片黄在线观看| 亚洲XX00视频| 午夜不卡AV免费| 自拍偷自拍亚洲精品第1页| 三级毛片在线免费观看| 亚洲成A∨人片在线观看不卡| 日韩精品免费在线视频| 久久亚洲美女精品国产精品| 亚欧日韩毛片在线看免费网站| 亚洲狠狠综合久久| 最近中文字幕无免费| 亚洲另类春色校园小说| 国产精品免费观看久久| 亚洲aⅴ无码专区在线观看| 亚洲精品亚洲人成在线观看下载| 一级做a爰片久久毛片免费陪 | 国产黄片不卡免费| 亚洲女同成av人片在线观看| 日韩插啊免费视频在线观看| 亚洲avav天堂av在线网爱情| 国产大片免费观看中文字幕| 一本大道一卡二大卡三卡免费 | 久久亚洲AV永久无码精品| 曰批全过程免费视频在线观看无码 | 久久99国产亚洲精品观看| 一级毛片**不卡免费播| 国产成人精品日本亚洲专| 国产免费观看视频| 免费一区二区无码东京热| 91午夜精品亚洲一区二区三区| 青草草在线视频永久免费| 99精品视频在线观看免费| 精品亚洲成在人线AV无码| 精品国产亚洲男女在线线电影| 99在线视频免费| 男人扒开添女人下部免费视频| 亚洲一卡2卡三卡4卡有限公司| 暖暖免费高清日本中文|