Прямолинейная прокрутка занимает много времени с большими наборами данных

Question

Привет У меня есть шрифт, содержащий около 52000 записей. Поскольку это большой набор данных, я попытался использовать функцию прокрутки в реальном времени с помощью строк прокрутки, равных 20. Это число столбцов - 53. В таблице также есть функция фильтрации и сортировки на каждом столбце. До сих пор я не удовлетворен работой таблицы. Для загрузки страницы занимает около 15 секунд, хуже всего то, что она занимает около 65 секунд для следующего набора из 20 записей, которые будут загружены при достижении конца прокрутки.

Только для тестирования я уменьшил общее количество записей до 25000, а преформация улучшилась со временем прокрутки 29 секунд. Я действительно не могу понять, почему это занимает много времени, когда я показываю только 20 записей за раз. Общее количество записей не должно влиять на производительность.

Может кто-то пожалуйста, предложить, как улучшить performance.I не может реализовать разбиение на страницы для этого, так как мой клиент не хочет it.Thanks заранее

Мой JSF фрагмент кода

<p:dataTable id="arcRecList" var="data" 
      value="#{archivedRecordBean.archiveItems}" 
      tableStyle="table-layout:auto; width:80%;" styleClass="datatable" 
      scrollable="true" scrollWidth="84%" scrollHeight="69%" 
      columnClasses="columnwidth" liveScroll="true" scrollRows="20" 
      filteredValue="#{archivedRecordBean.filteredArchiveItems}"> 


      <p:column style="width:250px" headerText="Insured" 
       filterBy="#{data.insuredName}" sortBy="#{data.insuredName}"> 
       <h:outputText value="#{data.insuredName}" /> 
      </p:column> 

      <p:column style="width:250px" headerText="City" 
       filterBy="#{data.custAddress_City}" 
       sortBy="#{data.custAddress_City}"> 
       <h:outputText value="#{data.custAddress_City}" /> 
      </p:column> 
       . 
       . 
       .53 columns 
       . 
     </p:dataTable> 

управляемому боб

@ManagedBean

@RequestScoped

класс ArchivedRecordBean общественность реализует Serializable {

private List<WorkSpaceItem> archiveItems=null; 
private List<WorkSpaceItem>filteredArchiveItems; 
private WorkSpaceItem objWorkSpaceItem=null; 
JdbcConnection jdbcConnection=null; 
Connection connection=null; 
Statement selectStmt=null; 
ResultSet rs=null; 
public ArchivedRecordBean() 

{ 
    getArchiveFields(); 

} 
public List<WorkSpaceItem> getArchiveItems() { 
    return archiveItems; 
} 
public void setArchiveItems(List<WorkSpaceItem> archiveItems) { 
    this.archiveItems = archiveItems; 
} 
public WorkSpaceItem getObjWorkSpaceItem() { 
    return objWorkSpaceItem; 
} 
public void setObjWorkSpaceItem(WorkSpaceItem objWorkSpaceItem) { 
    this.objWorkSpaceItem = objWorkSpaceItem; 
} 

public List<WorkSpaceItem> getFilteredArchiveItems() { 
    return filteredArchiveItems; 
} 
public void setFilteredArchiveItems(List<WorkSpaceItem> filteredArchiveItems) { 
    this.filteredArchiveItems = filteredArchiveItems; 
} 
public void getArchiveFields() 
{ 
    try 
    { 
     jdbcConnection=new JdbcConnection(); 
     connection=jdbcConnection.getJdbcConnection(); 
     selectStmt=connection.createStatement(); 
     String query="select * from LPINFO where LPINFO.ClearDate < (select TOP 1 Tbl_CurrentYear.CurrentYear from dbo.Tbl_CurrentYear)" 
       +"AND (LPINFO.ClearDate is not null)"; 
     rs=selectStmt.executeQuery(query); 
     archiveItems=new ArrayList<WorkSpaceItem>(); 
     while(rs.next()) 
     { 

      objWorkSpaceItem=new WorkSpaceItem(); 
      objWorkSpaceItem.setInsuredName(rs.getString("InsuredName")); 
      objWorkSpaceItem.setCustAddress_City(rs.getString("CustAddress_City")); 
      objWorkSpaceItem.setCustAddress_State(rs.getString("CustAddress_State")); 
      . 
      . 
      .//Setting the values for remaining columns 
      . 
      . 
      archiveItems.add(objWorkSpaceItem); 

     } 

    } 
    catch(Exception e) 
    { 
     e.printStackTrace(); 
    } 
    finally 
    { 
     try { 

      connection.close(); 
     } catch (SQLException e) { 

      e.printStackTrace(); 
     } 

    } 

} 

}

Answer 1

Попробуйте изменить управляемый компонент для @ViewScoped. Я не могу сделать тест прямо сейчас, но насколько я знаю, для каждого HTTP-запроса создается обработчик requestScoped, поэтому я думаю, что проблема может заключаться в том, что вы запрашиваете базу данных для каждого прокрутки. Это объясняет, почему время загрузки уменьшается с меньшим количеством записей в таблице.

Answer 2

Я так долго занимаюсь, потому что вы загружаете все товары из базы данных, по каждому запросу (бонус @RequestScope воссоздается по каждому запросу).

Если вы перейдете на @ViewScope, вы будете загружать данные только один раз, но все они будут сохранены в сеансе, замедляя работу сервера. Если вы сохраняете состояние на клиенте, это будет иметь гигантское влияние на использование сети и очень большое использование ЦП из-за сериализации/десериализации. Не очень хорошая идея.

Вы должны как минимум реализовать LazyDataModel и всегда ограничивать объем данных, которые считываются из базы данных (предоставление 1000 страниц для конечного пользователя не имеет смысла в представлении UX).