现在不依赖像 memcached 这样的缓存系统（对于动态站点）是不是很疯狂？
我刚刚审查了我的客户的一个应用程序，该应用程序使用一些旧的过时的 php 框架，该框架根本不依赖缓存，并且几乎完全依赖于数据库。
我想我会从头开始重写它，因为它确实已经过时了，并且在这次重写中我想实现一个缓存系统。如果有人之前做过这件事，如果我能得到一些指示，那就太好了。
- 重写将在 PHP 或 Python 中完成，
- 如果我可以在此实现之前和之后进行分析，那就太好了
- 我有自己的服务器，所以我不受共享托管的限制
I was just reviewing one of my client's applications which uses some old outdated php framework that doesn't rely on caching at all and is pretty much completely database dependent.
I figure I'll just rewrite it from scratch because it's really outdated and in this rewrite I want to implement a caching system. It'd be nice if I could get a few pointers if anyone has done this prior.
- Rewrite will be done in either PHP or Python
- Would be nice if I could profile before and after this implementation
- I have my own server so I'm not restricted by shared hosting
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果缓存工作正常（==高命中率），它是为数不多的能够真正帮助解决延迟问题的通用技术之一——问题中较困难的部分通常被描述为“性能”。您只需通过投入更多硬件来解决问题即可增强 QPS（每秒查询数）性能衡量标准，但延迟却并非如此（即，不需要一个月的时间就能解决问题）如果你让九位母亲参与其中，就会生出一个婴儿；-)。
然而，缓存使用的主要资源通常是内存（RAM 或磁盘）。正如您在评论中提到的，您观察到的唯一性能问题是内存使用，缓存不会有帮助：它只会指定一部分内存用于缓存目的，而作为“普通基金”的可用内存则更少。作为加利福尼亚州的居民，我亲眼目睹了当指定太多资源时会发生什么，我不能问心无愧地推荐这样的行动方案！-）
Caching, when it works right (==high hit rate), is one of the few general-purpose techniques that can really help with latency -- the harder part of problems generically describes as "performance". You can enhance QPS (queries per second) measures of performance just by throwing more hardware at the problem -- but latency doesn't work that way (i.e., it doesn't take just one month to make a babies if you set nine mothers to work on it;-).
However, the main resource used by caching is typically memory (RAM or disk as it may be). As you mention in a comment that the only performance problem you observe is memory usage, caching wouldn't help: it would just earmark some portion of memory to use for caching purposes, leaving even less available as a "general fund". As a resident of California I'm witnessing first-hand what happens when too many resources are earmarked, and I couldn't recommend such a course of action with a clear conscience!-)
如果您的网站性能良好，则没有理由添加缓存。许多站点可以在没有任何缓存的情况下运行，或者通过迁移到基于文件系统的缓存来运行。只有超高流量的网站才需要memcached。
“疯狂”的是代码架构（或缺乏架构），这使得在后者中添加缓存变得困难。
If your site performance is fine then there's no reason to add caching. Lots of sites can get by without any cache at all, or by moving to a file-system based cache. It's only the super high traffic sites that need memcached.
What's "crazy" is code architecture (or a lack of architecture) that makes adding caching in latter difficult.
既然 Python 是你的选择之一，我会选择 Django。内置缓存机制，我一直在使用 这个 debug_toolbar在开发/分析时帮助我。
顺便说一句，memcached 不按照您所描述的方式工作。它将唯一键映射到内存中的值，与 .csh 文件或数据库查询无关。您存储在值中的内容将被缓存。
哦，只有当存在（或将会出现）性能问题时，缓存才有价值。如果不需要的话，“不依赖”缓存并没有什么问题。过早的优化是99%的罪恶！
Since Python is one of your choices, I would go with Django. Built-in caching mechanism, and I've been using this debug_toolbar to help me while developing/profiling.
By the way, memcached does not work the way you've described. It maps unique keys to values in memory, it has nothing to do with .csh files or database queries. What you store in a value is what's going to be cached.
Oh, and caching is only worth if there are (or will be) performance problems. There's nothing wrong with "not relying" with caches if you don't need it. Premature optimization is 99% evil!
根据代码库和流量模式的具体性质，您甚至可能不需要重写整个站点。如果 99.9% 的页面请求可以通过缓存绕过，那么效率极低的代码并不是什么大问题。
选择 PHP 或 Python 时，请确保您弄清楚将在哪里托管该网站（或者您是否可以进行该调用）。我的许多客户已经在网络服务器上设置了，而 Python 不是一个选择。您还应该确保您想要连接的任何数据库/外部程序在 PHP 或 Python 中得到良好的支持。
Depending on the specific nature of the codebase and traffic patterns, you might not even need to re-write the whole site. Horribly inefficient code is not such a big deal if it can be bypassed via cache for 99.9% of page requests.
When choosing PHP or Python, make sure you figure out where you're going to host the site (or if you even get to make that call). Many of my clients are already set up on a webserver and Python is not an option. You should also make sure any databases/external programs you want to interface with are well-supported in PHP or Python.