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

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

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

    Bryan

      BlogJava :: 首頁 :: 聯系 :: 聚合  :: 管理
      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. 閱讀(182) 評論(0)  編輯  收藏

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


    網站導航:
     
    主站蜘蛛池模板: 久久夜色精品国产亚洲AV动态图| 日韩高清在线高清免费| 亚洲精品国产高清嫩草影院| 亚洲无人区码一二三码区别图片| 999国内精品永久免费视频| 亚洲视频国产视频| 免费A级毛片无码A∨免费| 亚洲成a人片在线观| 91精品成人免费国产片| 亚洲国产视频网站| 毛片在线看免费版| 精品在线视频免费| 久久伊人亚洲AV无码网站| 免费无码av片在线观看| 久久精品亚洲一区二区三区浴池| 亚洲美女免费视频| 亚洲AV无码之国产精品| 亚洲国产av无码精品| 国产午夜无码精品免费看 | 免费福利在线播放| 亚洲人成网站999久久久综合| 日本不卡高清中文字幕免费| 午夜不卡AV免费| 亚洲AV无码久久精品成人| 九九精品免费视频| 野花视频在线官网免费1| 亚洲精品亚洲人成人网| 啦啦啦完整版免费视频在线观看| 亚洲av最新在线观看网址| 亚洲精品视频在线看| 99热在线观看免费| 亚洲va中文字幕| 亚洲AV永久无码精品水牛影视| 亚洲免费观看网站| xxxx日本在线播放免费不卡| 亚洲综合激情另类小说区| 四虎在线播放免费永久视频| 男女作爱在线播放免费网站| 亚洲综合色婷婷在线观看| 亚洲欧洲日产国码无码久久99| 免费观看AV片在线播放|