Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -6,10 +6,10 @@
6	6	Remember that ergonomics research states that:
7	7
8	8
9		-- Under 100 millisecond response time. This is the "Sleek" range. The user will perceive a fluid application.
10		-- Under 1 second. This is the "Processing range". The user will perceive a responsive but will notice processing times.
11		-- Over 1 second and under 10 seconds. This is the "Busy range". The user will be annoyed by processing times, its productivity will decrease, but the application is still usable. (sometimes barely)
12		-- Over 10 seconds. The user will start doing something else. Therefore, you will lose him. This is the "unacceptable" range.
	9	+* Under 100 millisecond response time. This is the "Sleek" range. The user will perceive a fluid application.
	10	+* Under 1 second. This is the "Processing range". The user will perceive a responsive but will notice processing times.
	11	+* Over 1 second and under 10 seconds. This is the "Busy range". The user will be annoyed by processing times, its productivity will decrease, but the application is still usable. (sometimes barely)
	12	+* Over 10 seconds. The user will start doing something else. Therefore, you will lose him. This is the "unacceptable" range.
13	13
14	14
15	15
...	...	@@ -23,22 +23,22 @@
23	23
24	24	For information, a non comprehensive list of them:
25	25
26		-- Use of taglibs and JSP. For rendering, the platform uses servlets and JavaServerPages. Those are java compiled objects that are optimized for rendering. In addition, the Java JIT (Just in time compile) does a great job of pre-compiling the java byte code into native processor assembly code for optimum CPU performance.
27		-- A Model / View / Controller for rendering and user actions processing.
28		-- Ajax based interactivity. Where there is a need to interact with the server (like processing of a on change user click), the minimum amount of data is posted to the server and the update is received with AJAX based transaction. This reduces the amount of data on the network and the amount of processing on the server to the bare minimum.
29		-- CSS and JS based design. The HTML is CSS based to separate the look and feel information (CSS, loaded once) with the actual data (HTML, rendered each time). The same approach is used for javascript.
30		-- Client cached of non alterable data. JS, CSS, images, file attachment content cannot change. Therefore, the platform declares those objects as cacheable with an expiration date far in the future. The client browser may use those information for optimum caching.
31		-- Server side caching of user data. Security tokens are cached upon login, as well as user information such as locale.
32		-- Caching of LOV (List of Values). Common list of values are cached in the platform and not retrieved each time the rendering engine would need it.
33		-- Pre-compilation of server based JavaScript code. All javascript is loaded and pre-compiled into java classes. The execution time is therefore on par with pure java code, and JIT optimized as well.
34		-- First level cache of entity objects. A cached is used to avoid loading twice the same object within the same database transaction.
35		-- Optimistic locking of database objects. Even though this does not speed the transactions, it dramatically reduces the contention and makes the job of the database server much easier and much more scalable
36		-- Lazy loading of collections and referenced objects. Collections are not loaded immediately but are loaded on demand (lazy load). This reduces the number of SQL orders sent to the database server.
37		-- Batch loading of collection items. Items in collections are not loaded one by one, but with batch processing (10 at a time, even if we have less).
38		-- Pre-parsing of SQL statements. SQL orders to load, insert data are pre-calculated, and pre-parsed parametrized statements are used. In addition to improve the security by removing the risk of SQL injections attacks, it also helps the database server to optimize execution plans and caching of database data, thus dramatically improving the overall performance.
39		-- Limits load of data. When rendering lists, only the first items are retrieved and a page cache mechanism is used to retrieve the minimum amount of data. The SQL orders includes database specific hints to let the database server that we want just the 10 first. In most of cases, the database server will do a good job at returning those items as fast as possible (avoiding full table scans for example).
40		-- Pre-calculating of images. Pictures and images (platform, and application based) are resized and re-compressed using JPEG compressor prior to rendering to the user. This ensures the right resolution to be sent to the client, and avoid large amount of data to travel on the network
41		-- No use of server-side inefficient architecture. For example, EJB are not used. Even though they are scalable in theory, their fine grain distributed nature makes them inefficient and therefore they are dismissed on the requea platform.
	26	+* Use of taglibs and JSP. For rendering, the platform uses servlets and JavaServerPages. Those are java compiled objects that are optimized for rendering. In addition, the Java JIT (Just in time compile) does a great job of pre-compiling the java byte code into native processor assembly code for optimum CPU performance.
	27	+* A Model / View / Controller for rendering and user actions processing.
	28	+* Ajax based interactivity. Where there is a need to interact with the server (like processing of a on change user click), the minimum amount of data is posted to the server and the update is received with AJAX based transaction. This reduces the amount of data on the network and the amount of processing on the server to the bare minimum.
	29	+* CSS and JS based design. The HTML is CSS based to separate the look and feel information (CSS, loaded once) with the actual data (HTML, rendered each time). The same approach is used for javascript.
	30	+* Client cached of non alterable data. JS, CSS, images, file attachment content cannot change. Therefore, the platform declares those objects as cacheable with an expiration date far in the future. The client browser may use those information for optimum caching.
	31	+* Server side caching of user data. Security tokens are cached upon login, as well as user information such as locale.
	32	+* Caching of LOV (List of Values). Common list of values are cached in the platform and not retrieved each time the rendering engine would need it.
	33	+* Pre-compilation of server based JavaScript code. All javascript is loaded and pre-compiled into java classes. The execution time is therefore on par with pure java code, and JIT optimized as well.
	34	+* First level cache of entity objects. A cached is used to avoid loading twice the same object within the same database transaction.
	35	+* Optimistic locking of database objects. Even though this does not speed the transactions, it dramatically reduces the contention and makes the job of the database server much easier and much more scalable
	36	+* Lazy loading of collections and referenced objects. Collections are not loaded immediately but are loaded on demand (lazy load). This reduces the number of SQL orders sent to the database server.
	37	+* Batch loading of collection items. Items in collections are not loaded one by one, but with batch processing (10 at a time, even if we have less).
	38	+* Pre-parsing of SQL statements. SQL orders to load, insert data are pre-calculated, and pre-parsed parametrized statements are used. In addition to improve the security by removing the risk of SQL injections attacks, it also helps the database server to optimize execution plans and caching of database data, thus dramatically improving the overall performance.
	39	+* Limits load of data. When rendering lists, only the first items are retrieved and a page cache mechanism is used to retrieve the minimum amount of data. The SQL orders includes database specific hints to let the database server that we want just the 10 first. In most of cases, the database server will do a good job at returning those items as fast as possible (avoiding full table scans for example).
	40	+* Pre-calculating of images. Pictures and images (platform, and application based) are resized and re-compressed using JPEG compressor prior to rendering to the user. This ensures the right resolution to be sent to the client, and avoid large amount of data to travel on the network
	41	+* No use of server-side inefficient architecture. For example, EJB are not used. Even though they are scalable in theory, their fine grain distributed nature makes them inefficient and therefore they are dismissed on the requea platform.
42	42
43	43
44	44