Site Maintenance

 Site Maintenance

Site & Page Caching

Page download time is a critical factor in keeping visitors in your storefront. The longer it takes to download a page, the higher your risk of losing a sale. Therefore, it is best to cache your pages as much as possible to minimize page download times.

 

Furthermore, rendering pages containing many business objects or complex calculations such as category and search result pages or product detail pages can consume a lot of resources. Since this information generally does not change from one user to another, not caching these pages can excessively waste processing resources which will slow down the entire site for all users (including job processing) and not just for the requested pages.

 

In Demandware, caching is controlled on a per page basis, via the ISML template for the page. Caching is set on a page using the <iscache> tag:

<iscache type="relative" hour="24">

 

These are the rules when using the tag:

• If <iscache> tag occurs multiple times in a template or its locally included templates, the shortest duration is used

• Caching from a local include affects the including template

• If there is no <iscache> defined, the template is not cached

Caching Parameters

The following parameters can be set with the <iscache> tag:

• status = "off|on"

  • off disables page caching

  • on enables page caching (the default)

    This setting allows for caching to be turned on and off programmatically. status="off" is considered the shortest duration, so be careful when using it on an included template (see rules above).

• type = "relative | daily"

  • Relative allows you to specify a certain period of time（一段时间）, in minutes and hours, after which the page will be deleted from the cache. Daily allows you to specify a specific time when the page will be deleted from the cache.

• hour = integer

  • Indicates either the caching duration or the time of day. If the type attribute is set to daily, the hour value must be an integer ranging from 0 to 23. If type is set to relative, all integer values greater than 0 are valid (the default value is 0, meaning either the page is never cleared from the cache or only the minute attribute is relevant).

• minute = integer

  • Indicates either the caching duration or the time of day. If the type attribute isset to daily, the minute value must be an integer ranging from 0 to 59. If type is set to relative, all integer values greater than 0 are valid (the default value is 0, meaning either the page is never cleared from the cache or only the hour attribute is relevant).

• varyby="price_promotion"

  • Lets you mark a page as personalized（标记个性化页面）: this does not mean that the page is unique for a person but rather that different versions of the same page showing different prices, promotions, sorting rules or AB test segments will be cached by the Demandware platform. For example, this parameter is necessary for product pages since a customer belonging to a customer group might get special promotions that other customer groups don’t get. While the ISML template is the same, the generated pages vary, and therefore caching every version of the page benefits performance. For performance reasons, a page should only be marked with the varyby property if the page is really personalized; otherwise, the performance canunnecessarily degrade.

Frequently changing pages benefit 有利于 from a shorter caching period. Stored pages are only invalidated and a new one pulled from the Application Server if:

频繁更改页面从减少cache周期做起，存储页面被废除。一个新的从app server中调出。

• The defined caching time is exceeded, or

  定义cache时间为溢出的

• A replication has been performed (with the exception of coupons and geolocation data), or

  一个复制已经被执行（除了coupons 和地理信息）

• An explicit page cache invalidation is triggered by a merchant in BM

  明确的页面缓存删除被商家从后台触发

As a best practice, disable page caching on sandboxes, development and staging environments in order to see changes immediately. In Production caching is always on by default.

 

部分页面缓存

Portions of pages(部分页面) can be cached separately（分开）. You can assemble a page from snippets（片段） with different caching attributes using remote includes. Each part:

• Has to be a result of a pipeline request to the application server

• Is included using the syntax:

  <isinclude url=""> or the <iscomponent pipeline=….>

• Can have different cache times or no caching at all

In general, do not cache pages that show buyer or session information.

Studying Page Analytics to Determine Caching Problems

Demandware provides caching metrics under the Site  ⇒ Analytics  ⇒ Technical Reports menu. The Pipeline Performance report will capture information.

These types of analytics are not collected on sandboxes, only on Production instances. While this chart is hard to read, it reveals that the Home-Show pipeline (which generates the homepage) is not cached: the Caching column shows red for all hits. If you see this trend in your analytic data, you may decide to alter the caching settings or the caching interval.

 

Across Demandware customers the two critical metrics we look at from a pipeline performance perspective are the average response times of Search-Show and Product-Show pipelines.

 

For Search-Show the average response is 400ms. Customers should be <= to this value to be in a good performance range.

 

For Product-Show the average response is 320ms-400ms. Customers should be <=to this value to be in a good performance range.

 

Demandware strongly recommends that you check analytics reports each week and after you make code changes to track these metrics.

 

Page Level Caching

 

Once the <iscache> tag is added to an ISML template, the entire ISML page will be cached for the time specified in the tag.

 

For example, the page below will be cached for 1 hour and 30 minutes:

<iscache type=”relative” hour=”1” minute=”30” >

 

Partial Page Caching

Most of the time, a single page should not be cached completely. Some parts of the page should be cached, while not others. In this case you need to use remote includes for every part that has unique caching characteristics. Every remote include calls a different pipeline which generates an ISML template, each template having (possibly) different page caching.

 

The syntax for a remote includes uses the URLUtils class to call a remote pipeline with optional parameters appended:

<isinclude  url="${URLUtils.url('Page-Include', 'cid', 'COOKIE_TEST')}">

 

You can also use the newer <iscomponent> tag to implement a remote include.

<iscomponent pipeline="Product-IncludeLastVisited" />

 

Using the Storefront Toolkit to Determine Cache Settings

You can enable the Cache Information tool in the Storefront Toolkit to see how partial page caching is implemented for a page:

 

The page will now show special icons that you can click to reveal how the whole page and its remote includes are cached.

 

Site Performance 网站性能

The Pipeline Profiler （Pipeline分析器） is a tool in BM that gives you insight into pipeline and script performance.

 

It is located in Administration > Operations > Pipeline Profiler.

 

Code Replication 代码复制

Code replication is set and managed in BM. Once you have uploaded a new code version to the P.I.G. staging instance, you can set code replication to occur between staging and development or staging and production.

 

Code Replication Overview

In a typical development environment, a source management system is used for code version control. Each developer uses their own sandbox for development, while checking in their code to a source management system. 在典型的开发环境，一个资源管理系统用于版本控制。每一个开发人员使用自己的sandbox来开发，在资源管理系统检查他们的代码

 

UX Studio integrates with SVN for source management.

可以使用UX Studio 集成到SVN 资源。

 

When a developer has tagged a new code version and is ready to upload the new code to staging, he/she creates a new code version on STAGING in BM ：

Administration > Site Development > Code Deployment

当一个开发人员标记了一个新的代码版本，准备上传代码到staging,他创建一个新的版本在STAGING上：

Administration > Site Development > Code Deployment

 

Next, the developer uploads custom cartridges with Studio or WebDAV client using 2-factor authentication and tests the storefront in STAGING. A rollback to a previous version is available.

然后，开发人员上传自定义cartridge，使用studio或者WebDAV 客户端 ,

通过两个因素的验证，测试staging上的前台页面，可以允许回滚到上一个版本。

 

For major code changes, it is recommended to use a sandbox for testing

对于主要代码的调整，推荐使用sandbox来做测试。

 

For testing in a sandbox, you will need to export site data to the global directory from staging and import it into your sandbox using the Site Import/Export module in Business Manager.

在sandbox做测试，你需要从staging导出site数据到全局目录, 然后导入它到你的sandbox. 使用BM的Import/Export 模块。

 

When code meta data (site preferences, new attributes, etc.) needs to be tested, a replication from STAGING to DEVELOPMENT should be performed by a build engineer:

当代码的meta-data需要被测试（站点参数，新属性）需要被测试。一个从staging到development的复制需要被执行。

 

This is also good practice for testing processes without impacting the production storefront (i.e. Product import feed).

这也对测试过程，不影响生产环境有好处。

 

The last step in code replication is moving code from STAGING to PRODUCTION.

最后一步在复制代码过程中是移动代码从staging到生成环境

 

This process is also performed in Business Manager.

这个步骤也在BM中执行。

 

Data Replication 数据复制

Data replication is a process to promote merchant edits, product and system objects from Staging to Production (or Development). The best practice is to replicate to development first, verify that data and storefront work and then replicate from staging to production.

 

Data can be replicated granularly: 数据可以被选择性复制

• Organization objects

• Per Site objects

   

A Data Replication process consists of two phases:

Transfer – long running processes where data is copied from STAGING into“shadow” tables and folders on PRODUCTION. No changes are shown in storefront.

Publishing – Very fast process. Changes in “shadow” tables and folders become active, page cache is cleaned, and the new version is shown in storefront.

 

After data has been replicated, a one-time rollback (undo) is possible. This reverses the data to the state of the last successful replication.

 

You can view the progress of a replication by monitoring the staging logs on the staging and production instance.

 

Just as code replication is set up in Business Manager, so is data replication. The process is almost identical with the exception of being able to select which data you want to replicate.

与代码导入不同的是可以选择性复制

 

Just as code replication can only occur between STAGING and DEVELOPMENT or STAGING and PRODUCTION, so too is the data replication process only allowed one-way from STAGING to the other primary instances.