PHP - APC 缓存 - 用户特定数据与所有用户均可访问的数据
我已经阅读了几个网站上的一些教程以及 StackOverFlow 上有关该主题的一些问题,但我仍然找不到我的问题的明确答案。
我想知道APC Cache如何管理/保存用户特定的数据(将在php代码中使用的变量,是用户特定的。换句话说,其他用户不应该看到的数据。)以及它是如何做到的保存所有用户都可以看到的公开数据?
我只是想了解它是如何工作的。我知道 APC“保存”或保留在内存中所需的文件和包含的文件...但是如果这些包含的文件在代码中具有用户特定的变量怎么办?如果在 /account/user_profile.php 中我使用了几个变量,例如 $firstname $lastname $address 等,这些变量是否会保留在内存中?例如,如果 John X 在更新或保存缓存时登录,那么 APC 将始终将 John 记住为 $firstname,将 X 记住为 $lastname?如果另一个用户访问同一页面,我希望他看到其用户个人资料详细信息,而不是约翰的。
我知道这可能已经讨论过了,但我需要一个明确的答案。
谢谢你!
I have read a couple of tutorials on several web sites as well as a few questions here on StackOverFlow about the subject and I still couldn't find a clear answer to my question.
I am wondering how APC Cache manages/saves the user-specific data (variables that will be used in the php code, that are user-specific. In other words, data that should not be seen by other users.) and how does it save the publicly available data that all users can see?
I am just trying to understand how it works. I know that APC "saves" or keeps in memory required and included files... but what if those included files have user-specific variables in the code? If let's say in /account/user_profile.php I use several variables like $firstname $lastname $address, etc. will those variables be kept in memory? If, for example, John X is logged in at the time the cache is being updated or saved, then APC will always remember John as $firstname and X as $lastname? If another user goes to the same page, I want him to see its user profile details, not John's.
I know this might have been discussed already, but I need a clear answer, please.
Thank you!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我也有同样的问题。但关键是这个。 APC 并不将用户视为最终用户(即 John Smith),而是将其视为应用程序本身。因此,当 APC 表示用户特定数据时,您可以存储“用户特定数据”,即 APC 中有关该特定应用程序的 mywebsite.com 信息。它不是为人们设计的。它的目的是让一个程序基本上将可变信息发送到另一个程序。
I had the same question. But the key is this. APC sees the user not as the end user, i.e. John Smith, but as the application itself. So when APC says user specific data you can store "user specific data", i.e. information about mywebsite.com in APC about that specific application. It's not meant for people. It's meant for one program basically sending variable information to another.
PS:我从来没有使用过APC(之前切换到不同的语言我才真正理解APC的重要性),但我想我理解这个概念。如果我在某处撒谎,请纠正我。
你可以使用 apc_store 将数据存储在内存中,可以使用 apc-fetch。它不会将所有变量存储在程序中。
参数
键
通过阅读文档,我认为您必须提供唯一的键,就像在 memcached/redis 中一样。要将数据存储为私有,您只需获取 session_id(唯一每个会话)并将其用作前缀。您使用
密钥
来存储您的数据。 Simon Willison 的这个 Redis 教程 还有一个部分描述了如何使用密钥,我下面将引用:P.S: I have never used APC(switched to different language before that I really understand the importance of APC), but I think I understand the concept. Please correct me if I am telling a lie somewhere.
You can use apc_store to store data inside memory, which can be retrieved using apc-fetch. It does not store all your variables inside your program.
Parameters
key
From reading the docs I assume that you have to provide unique keys just like you would in memcached/redis. To store data private you would just get the session_id(unique per session) and use that as your prefix. You use the
key
to store your data. This Redis tutorial from Simon Willison also has a section describing how to use keys which I will quote below:你对APC缓存有错误的理解。它是一个字节码缓存,这意味着它将存储 PHP 脚本的字节码。这将在下次从脚本中再次创建字节码时保存 PHP 解释器,因为它已经存在了。
在正常的 PHP 执行中,您的脚本代码将被获取并编译为字节码。然后该字节码将由 php 处理器执行。这是 JIT 编译器的常见模式。
因此,如果没有字节码缓存,则需要在每个请求上编译字节码。使用字节码缓存,此步骤只需在所有请求中执行一次。下次字节码已经在缓存中并且可以直接执行。
这与变量内容完全无关,仅用于代码。
You have the false understanding of the APC cache. It's a bytecode-cache, which means it will store the bytecode of a PHP script. This will save the PHP-interpreter the next time to create the bytecode again from the script because it's already there.
In normal PHP execution your scripts code will be taken and compiled into byte-code. This byte-code will then be executed by the php processor. It's a common pattern for JIT compilers.
So w/o a bytecode-cache, the bytecode needs to be compiled on each request. With a bytecode-cache, this step needs to be done only once across all requests. Next time the bytecode is already in the cache and can be executed straight-forward.
This is totally unrelated to variable contents, it's just for the code.