<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无码专区亚洲国产精品| 免费爱爱的视频太爽了| 亚洲中文字幕无码不卡电影| 黄色网址免费在线| 亚洲第一区精品观看| 免费VA在线观看无码| 亚洲人成网站18禁止一区| 九九九精品视频免费| 亚洲欧洲精品成人久久奇米网 | 免费三级毛片电影片| 亚洲午夜精品在线| 成人免费午间影院在线观看| 亚洲欧美日韩国产成人| 国产中文字幕免费| 国产久爱免费精品视频| 亚洲精品免费观看| 毛片免费观看视频| 暖暖免费中文在线日本| 亚洲日本乱码在线观看| 一级毛片在线免费观看| 亚洲天堂2017无码中文| 国产成人无码区免费A∨视频网站| 免费一级全黄少妇性色生活片 | 黄网址在线永久免费观看 | 国产在线观看免费观看不卡| 亚洲日本VA中文字幕久久道具| 又粗又黄又猛又爽大片免费 | 国内自产少妇自拍区免费| 免费国产va视频永久在线观看| 国产偷国产偷亚洲清高动态图| 热re99久久6国产精品免费| 亚洲综合无码无在线观看| 亚洲AV网站在线观看| 免费h视频在线观看| 亚洲综合欧美色五月俺也去| 亚洲精品国产va在线观看蜜芽| 91精品国产免费久久国语蜜臀| 亚洲av永久中文无码精品综合| 亚洲精品二区国产综合野狼| 亚洲国产精品免费观看| www在线观看播放免费视频日本|