做系統訊息功能時，聯絡人列表這一塊開始是後台查詢資料庫的方法來繫結treeview頁面控制項。外觀設計是區劃下有部門，部門下面才是聯絡人的**節點。由於區劃、部門、人員各有一張表，所以在繫結treeview時，首先查詢這三張表，然後根據使用者的區劃和部門來確定使用者的位置，用了三個迴圈，還有判斷語句，在使用者量還比較小的時候效率上還可以，但當使用者量增加時，效率就有點慢，而且訊息功能用的比較頻繁，連續的訪問資料庫，加重了資料庫伺服器的負擔。當系統穩定以後，使用者數量也基本確定，就想用其它的方式來優化一下，xml能否解決這個問題？
先確定xml文件的格式，既然利用生成的xml來繫結treeview控制項，生成的文件最好能不經過邏輯判斷來進行繫結treeview控制項。專案實施後，由於使用者更新已經比較小，所以就想到在專案應用啟動和使用者資料更新時，來重新生成使用者的xml資料。
設計treeview的**節點：區劃
部門 聯絡人姓名+區劃
xml生成的文件格式：
<?xml version="1.0" encoding="utf-8"?>
........
.........
.........
完成後沒有用測試工具測試，頁面反應是快了許多。但是如果使用者資料很大，比如超過一萬或更多時，這種簡單的xml文件生成方式可能就會降低，xmlreader 可以提高讀取速度。
下面是根據是實現需求的**：
１ 生成xml文件的**
dataset areads = dbaccess.query(common.getconnstring, areaselectsql);//區劃
dataset departds = dbaccess.query(common.getconnstring, departselectsql);//部門
dataset userds = dbaccess.query(common.getconnstring, selectusersql);//使用者
for (int i_ta = 0; i_ta < areads.tables[0].rows.count; i_ta++)}}
微型專案實踐（1） 用XML描述實體
系統設計的第一步當然是分析需求，目前能夠想到的就是對日誌的管理，恩 再加上乙個分類好了，大體就是這樣子 我們使用乙個xml來描述這兩個實體 1 xmlversion 1.0 encoding utf 8 2 entities xmlns 3 entity title 日誌 name blog mod...
前端優化實踐
問題0 通過配置nginx日誌和tomcat訪問日誌，進行分析檢視處理速度，發現伺服器處理速度很快，不是伺服器端邏輯處理的問題。那麼就是網路環境或者頁面解析的問題 最終發現以下問題 問題1 頁面跳轉過多，對於g網路發起連線慢的環境會對速度體驗造成巨大的問題 處理辦法 1，去掉 專案中不必要的跳轉 問...
效能優化實踐
由於系統表資料量達到百萬級別，所有就遇到了效能優化問題。總結解決問題思路如下 1 從使用者角度來說，介面的資料載入緩慢，超過5秒就是存在效能問題了。解決問題思路，首先，先確定瓶頸點在 確定是 的問題還是sql的問題，可以通過debug除錯或者日誌或者擷取堆疊資訊檢視耗時來確定。2 如果是 層面的問題...