maruku 怎样，你的网站在哪里？

尝试用 Javascript Parser，在前端渲染。服务器只保存 markdown 格式，如何？

用片段缓存，不要写到数据库

#1 楼 @chenge admin 后台还没做好，不过功能也不多，大概过阵子才能上线，vps 也没准备好额.. 有图有 JB：

#2 楼 @zhangyuan 前端用了 Angularjs，火狐已经表示略吃力了。之前有用过 showdown，不过 xss 问题搞头晕就转向后端处理了。前端的编辑器用的 epiceditor 换下 showdown，后端采用 redcarpet 转换

专门建一个 content_html 字段，每次保存的时候把 markdown 处理过的内容保存到这个字段，显示的时候就取读这个字段，编辑的时候取读没渲染国的 content 字段。用空间换时间

#3 楼 @Rei 这个可以考虑。不过现在怕的是转换，一个人要 2s 的话，再多一点就不敢想象了。个人想把保存之后，把相应的 id 压到队列延迟转换，不知道可否？

保存到数据库的时候存原文的 markdown 格式原文，显示内容的时候通过 RDiscount 来进行解析，页面用 raw 表示

#6 楼 @gaicitadie 现在也是这么做，不过因为要保证实时性，每次提交都要转换一次。

感觉 markdown 转换比较耗时间 有生成 cloudfoundry 文档的经历，markdown 写的，几十个页面，生成都要十几分钟

#8 楼 @ywjno 显示的时候再转换？这样死得更惨...get 次数一般要比 post 多的。RDiscount maruku redcarpet 好像都是 C 扩展，效能应该不会相差太多，只能从别的地方入手。

#7 楼 @saiga 不清楚你的应用场景，我的意思是在页面渲染的时候加缓存。

<% cache @post do %>
  <%= format_body @post.body %>
<% end %>

库里只存原数据就行了。

#12 楼 @Rei 没描述清楚我的错.....现在的问题是：原数据频繁改动（编辑的时候每隔一段时间自动提交一次），转换次数多而且时间长。

markdown 好用吗？

#13 楼 @saiga 所以读时渲染不就更适合了？写时不会产生渲染耗时。

#15 楼 @Rei 大量私密文档好像不太好这样做缓存，给数据库加一个 sybmol，在读的时候 symbol 为 false 的时候表示还没转换，这时候再做转换？不过这样好像违背了 RESTful 了...

#16 楼 @saiga 文档的私密性跟片段缓存有啥关系啊。

<% if can_read? %>
  <% cache @post do %>
    <%= format_body @post.body %>
  <% end %>
<% end %>

#17 楼 @Rei 没事，我脑子抽了..我去试试...非常感谢～～