<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)航:
     
    主站蜘蛛池模板: 日本一道在线日本一道高清不卡免费| 免费看一区二区三区四区| 永久免费AV无码国产网站| 亚洲一区二区在线免费观看| 免费一区二区无码东京热| 亚洲欧洲日产国码av系列天堂 | 亚洲色精品三区二区一区| 日韩免费一区二区三区在线 | 国产亚洲真人做受在线观看| 国产成人免费ā片在线观看| 亚洲人成网站在线在线观看| 四虎www免费人成| 国产午夜亚洲精品不卡| 久久亚洲精品无码观看不卡| 国产V片在线播放免费无码| 国产亚洲精品美女久久久| 午夜无码A级毛片免费视频| 亚洲日韩中文字幕| 毛片免费在线观看网址| 春暖花开亚洲性无区一区二区| 国产成人免费片在线视频观看| 一区二区三区在线免费 | 精品无码专区亚洲| 成人男女网18免费视频| 亚洲综合无码无在线观看| 日本高清免费aaaaa大片视频| 色婷婷精品免费视频| 亚洲深深色噜噜狠狠爱网站| 久久99国产乱子伦精品免费| 亚洲永久网址在线观看| 亚洲精品成人区在线观看| 午夜老司机永久免费看片| 亚洲啪AV永久无码精品放毛片| 国产成人精品亚洲精品| 永久免费视频网站在线观看| 亚洲av色香蕉一区二区三区| 日日噜噜噜噜夜夜爽亚洲精品 | 亚洲人成毛片线播放| 免费一级e一片在线播放| 久久久久久国产精品免费免费男同 | 中文字幕在线免费|