>在表示层(希望不是)?
>在业务逻辑层?
>在数据层?
我将使用像memcached或MS Velocity这样的东西.
我只是发现自己编写了如此多的代码来更新业务逻辑层中的缓存,那么在数据库服务器的数据访问层之间创建一个结构来缓存数据会更好吗?
解决方法
当第一步实现时,您可以开始分析应用程序,列出似乎使用大量资源的功能(可能是cpu,内存,I / O,数据库访问)或花费大量时间来完成(通常是因为相同的症状).
一旦你有一个你认为可以用缓存系统优化的功能列表,你需要问自己两个问题:
>“我如何同时改进所有这些功能”(宏观焦点):这个问题的一个明显答案通常是数据访问缓存.如果您获得的数据始终相同,您通常不希望一遍又一遍地向数据库服务器发送相同的查询.因此,将这种类型的数据存储在缓存中,具有巧妙的使用寿命,总是一个好主意.
>“我如何改进每个功能”(微焦点):这很棘手,你需要很好地理解你的应用程序来解决这个问题.有些数据可以缓存,有些则不应该,有些则不能.调试器和分析器通常是此步骤的绝佳工具,因为它们可帮助您确定功能缓慢的原因,并为您提供有关如何优化功能的提示.
您要弄清楚的优化可能与您的应用程序的任何层(表示,业务逻辑,数据)有关,但这并不意味着您应该全部实现它们.您应该考虑以下几个重要事项:
>这个功能真的需要优化吗? (这对客户来说是一个显着的收益吗?对于硬件?对于整个应用程序?对于其他应用程序?)
>我可以获得什么样的性能提升? (1%,200%,……)
>我需要多长时间来优化它? (1小时,12天,…)
>优化它有多大风险? (它可能会破坏应用程序的内容吗?对于客户?)
一旦您获得了这些问题的答案,就可以与您的项目经理,您的同事,甚至那些不与您一起处理该应用程序的人员讨论这个问题.持中立意见是好的,并且有非技术性(或技术性较差)的意见.与这些人交谈应该可以帮助你弄清楚应该做什么和不应该做什么.
此时,您应该有一个非常清楚的优化列表,您已经多次考虑过,并且编码和测试它们应该没有问题.