-Asset publishing is managed by the System.Web.UI.TAssetManager module. By default, all published asset files are stored under the [AppEntryPath]/assets directory, where AppEntryPath refers to the directory containing the application entry script. Make sure the assets directory is writable by the Web server process. You may change this directory to another by setting the BasePath and BaseUrl properties of the System.Web.UI.TAssetManager module. -
-PRADO provides several methods for publishing assets or directories containing assets:
+Asset publishing is managed by the System.Web.UI.TAssetManager module. By default, all published asset files are stored under the [AppEntryPath]/assets directory, where AppEntryPath refers to the directory containing the application entry script. Make sure the assets directory is writable by the Web server process. You may change this directory to another by configuring the BasePath and BaseUrl properties of the System.Web.UI.TAssetManager module in application configuration, +
+
PRADO uses caching techniques to ensure the efficiency of asset publishing. Publishing an asset essentially requires file copy operation, which is expensive. To save unnecessary file copy operations, System.Web.UI.TAssetManager only publishes an asset when it has a newer file modification time than the published file. When an application runs under the Performance mode, such timestamp checkings are also omitted.
diff --git a/demos/quickstart/protected/pages/Advanced/Performance.page b/demos/quickstart/protected/pages/Advanced/Performance.page
index d1c5a49c..5aee4a9b 100644
--- a/demos/quickstart/protected/pages/Advanced/Performance.page
+++ b/demos/quickstart/protected/pages/Advanced/Performance.page
@@ -1,5 +1,82 @@
+Performance of Web applications is affected by many factors. Database access, file system operations, network bandwidth are all potential affecting factors. PRADO tries in every effort to reduce the performance impact caused by the framework.
+
+PRADO provides a generic caching technique used by in several core parts of the framework. For example, when caching is enabled, TTemplateManager will save parsed templates in cache and reuse them in the following requests, which saves time for parsing templates. The TThemeManager adopts the similar strategy to deal with theme parsing.
+
+Enabling caching is very easy. Simply add the cache module in the application configuration, and PRADO takes care of the rest.
+
+Developers can also take advantage of the caching technique in their applications. The Cache property of TApplication returns the plugged-in cache module when it is available. To save and retrieve a data item in cache, use the following commands,
+
+where $keyName should be a string that uniquely identifies the data item stored in cache.
+
+Including many PHP script files may impact application performance significantly. PRADO classes are stored in different files and when processing a page request, it may require including tens of class files.To alleviate this problem, in each PRADO release, a file named pradolite.php is also included. The file is a merge of all core PRADO class files whose comments are also stripped off.
+
+To use pradolite.php, in your application entry script, replace the inclusion of prado.php with pradolite.php.
+
+Application mode also affects application performance. A PRADO application can be in one of the following modes: Off, Debug, Normal and Performance. The Debug mode should mainly be used during application development, while Normal mode is usually used in early stage after an application is deployed to ensure everything works correctly. After the application is proved to work stably for some period, the mode can be switched to Performance to further improve the performance.
+
+The difference between Debug, Normal and Performance modes is that under Debug mode, application logs will contain debug information, and under Performance mode, timestamp checking is not performed for cached templates and published assets. Therefore, under Performance mode, application may not run properly if templates or assets are modified. Since Performance mode is mainly used when an application is stable, change of templates or assets are not likely.
+
+To switch application mode, configure it in application configuration:
+
+By default, PRADO stores page state in hidden fields of the HTML output. The page state could be very large in size if complex controls, such as TDataGrid, is used. To reduce the size of the network transmitted page size, two strategies can be used.
+
+First, you may disable viewstate by setting EnableViewState to false for the page or some controls on the page if they do not need user interactions. Viewstate is mainly used to keep track of page state when a user interacts with that page.
+
+Second, you may use a different page state storage. For example, page state may be stored in session, which essentially stores page state on the server side and thus saves the network transmission time. The module responsible for page state storage is System.Web.UI.TPageStatePersister, which uses hidden fields as persistent storage. To use your own storage, configure the module in application configuration as follows,
+
+Server caching techniques are proven to be very effective in improving the performance of PRADO applications. For example, we have observed that by using Zend Optimizer, the RPS (request per second) of a PRADO application can be increased by more than ten times. Of course, this is at the cost of stale output, while PRADO's caching techniques always ensure the correctness of the output.
+Performance Tuning
+Caching
+Using pradolite.php
+Changing Application Mode
+Reduce Page Size
+Other Techniques
+
+All themes by default must be placed under the [AppEntryPath]/themes directory, where AppEntryPath refers to the directory containing the application entry script. If you want to use a different directory, configure the BasePath and BaseUrl properties of the System.Web.UI.TThemeManager module in application configuration, +
+-Creating a theme involves creating the theme directory and writing skin files (and possibly javascript and CSS files). All themes by default must be placed under the [WebAppEntryPath]/themes directory, where WebAppEntryPath refers to the directory containing the application entry script. If you want to use a different directory, configure the BasePath and BaseUrl properties of the System.Web.UI.TThemeManager module. -
--The format of skin files are the same as that of control template files. Since skin files do not define parent-child presentational relationship among controls, you cannot place a component tag within another. And any static texts between component tags are discarded. To define the aforementioned 'Blue' skin for TButton, write the following in a skin file, +Creating a theme involves creating the theme directory and writing skin files (and possibly javascript and CSS files). The name of skin files must be terminated with .skin. The format of skin files are the same as that of control template files. Since skin files do not define parent-child presentational relationship among controls, you cannot place a component tag within another. And any static texts between component tags are discarded. To define the aforementioned 'Blue' skin for TButton, write the following in a skin file,
+As aforementioned, you can put several skins within a single skin file, or split them into several files. A commonly used strategy is that each skin file only contains skins for one type of controls. For example, Button.skin would contain skins only for the TButton control type. +
\ No newline at end of file -- cgit v1.2.3