我正在使用APC(3.1.9)和Zend Framework,但是,只有一堆文件被缓存(类似于10/400).
你有什么想法?我在debian安装上使用工厂选项.
编辑:看起来唯一的opcached文件是我手动调用的文件,require '';但是我的自动加载器加载的文件不是.有任何想法吗?
运行时设置
apc.cache_by_default 1
apc.canonicalize 1
apc.coredump_unmap 0
apc.enable_cli 0
apc.enabled 1
apc.file_md5 0
apc.file_update_protection 2
apc.filters
apc.gc_ttl 3600
apc.include_once_override 0
apc.lazy_classes 0
apc.lazy_functions 0
apc.max_file_size 1M
apc.mmap_file_mask
apc.num_files_hint 1000
apc.preload_path
apc.report_autofilter 1
apc.rfc1867 0
apc.rfc1867_freq 0
apc.rfc1867_name APC_UPLOAD_PROGRESS
apc.rfc1867_prefix upload_
apc.rfc1867_ttl 3600
apc.serializer default
apc.shm_segments 1
apc.shm_size 32M
apc.slam_defense 1
apc.stat 1
apc.stat_ctime 0
apc.ttl 0
apc.use_request_time 1
apc.user_entries_hint 4096
apc.user_ttl 0
apc.write_lock 1
Run Code Online (Sandbox Code Playgroud)
这是apc.php的截图

获得opcached的文件

和index.php(ZF)我需要文件并在Zend_Loader_Autoloader中注册自动加载器.

我正在使用Zend Framework 1.11,Doctrine 2,一些Symfony 2组件以及其他工具和库来开展项目.
我正在尝试使用Xdebug和Webgrind来优化性能.
我已经发现了一些瓶颈,比如解析Ini配置等等.并缓存了它.
现在,我只是意识到自动加载是我的应用程序中成本最高的部分:
Opl\Autoloader\ApcLoader->loadClass 274 31.36 43.86
Zend_Loader_PluginLoader->load 150 4.80 12.29
Zend_Loader_Autoloader->getClassAutoloaders 278 1.42 1.91
Zend_Controller_Router_Route_Regex->_getMappedValues 291 1.29 1.35
Doctrine\ORM\UnitOfWork->createEntity 85 1.24 3.18
Run Code Online (Sandbox Code Playgroud)
正如你我不使用默认的看到Zend_Loader_Autoloader,我使用的Opl是,据我所知,比它更快,我使用的是classMapLoader与APC缓存,但它仍然是一个有点减慢相比,应用程序的其余部分.
我怎么能优化它?
我已经加载了大约250个类,看起来只有~40个很慢,其他人显示0,00为"总呼叫成本",但其他人在要求呼叫时从0,08增加到0,57.
顺便说一句,由于使用Opl自动加载器,它看起来在我的生产环境APC上只有操作码缓存"手动需要"的文件,而不是自动加载器调用的文件.
我使用PHP5.3,Apache的2.2和Zend框架1.11,当我做卷曲的请求,我有两个型动物的会话ID两个Set-Cookie头.
有任何想法吗?
> POST /api/register HTTP/1.1
> Authorization: Basic Ymd1ZXJ0eQ==
> Host: api.domain.tld
> Accept: */*
> Content-Length: 66
> Content-Type: application/x-www-form-urlencoded
>
< HTTP/1.1 200 OK
< Date: Wed, 07 Dec 2011 13:27:07 GMT
< Server: Apache
< X-Powered-By: PHP/5.3.8
< Set-Cookie: SESSID=vtvackh55bj1up3ouoq4bhk545; expires=Thu, 06-Dec-2012 19:15:53 GMT; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
< Set-Cookie: SESSID=79a1g98e0pkqlq8fo7elpe9492; expires=Thu, 06-Dec-2012 19:15:53 GMT; path=/
< Vary: Accept-Encoding,User-Agent
< Content-Length: …Run Code Online (Sandbox Code Playgroud) 所以我目前正在研究 CQRS 架构和 EventStore“模式”。
它将应用程序打开到可扩展性和灵活性以及测试的新维度。
但是我仍然坚持如何正确处理数据迁移。
这是一个具体的用例:
假设我想管理一个包含文章和评论的博客。
在写入端,我使用 MySQL,在读取端 ElasticSearch,现在每次处理命令时,我都会在写入端持久化数据,在读取端调度一个事件来持久化数据。
现在让我们说我有某种 ViewModel 被调用ArticleSummary,它包含一个 id 和一个标题。
我有一个新的功能请求,要将文章标签包含到我的 中ArticleSummary,我会向模型添加一些字典以包含标签。
鉴于我的写入层中已经存在标签,我需要更新或使用新的“表”来正确使用新包含的数据。
我知道 EventLog Replay 策略包括重放所有事件以“更新”所有 ViewModel,但是,严肃地说,当我们有十亿行时它是否可行?
有没有经过验证的策略?任何反馈?
好吧,我正在尝试将自己介绍给DDD,我对它很新,一些概念仍然不清楚.
这是我到目前为止所理解的:
使用Doctrine2时,我们使用EntityRepository或CustomEntityRepository实现.
在DDD中,Repository模式看起来有点不同,我查看了.NET和Java示例以及来自DDD邮件列表的消息,人们倾向于认为存储库应该返回QueryObject,在Doctrine2中,我项目返回我的存储库中的QueryBuilder实例.
因此,为了隐藏使用QueryBuilder的复杂性,然后查询一个Hydrated结果集,我实现了另一个我叫做Manager的服务层.
以下是我的域名的样子:
src/Domain/
??? Entity
? ??? AbstractComment.php
? ??? Comment.php
??? Manager
? ??? CommentManager.php
??? Repository
??? CommentRepository.php
Run Code Online (Sandbox Code Playgroud)
Entity文件夹只是纯POPO.
该CommentRepository如下所示:
<?php
namespace Acme\Domain\Repository;
use Doctrine\Common\Collections\Criteria;
class CommentRepository
{
private $em;
public function __construct(EntityManager $em)
{
$this->em = $em;
}
/**
* @param $id
*
* @return \Doctrine\ORM\QueryBuilder
*/
public function findOneById($id)
{
$qb = $this->getEntityManager()
->getRepository('Acme:Domain\Entity\Comment')
->createQueryBuilder('c');
$criteria = new Criteria();
$criteria->andWhere(
$criteria->expr()->eq('c.id', ':id')
);
$qb->addCriteria($criteria);
$qb->setParameter('id', $id);
return $qb; …Run Code Online (Sandbox Code Playgroud) php domain-driven-design ddd-repositories symfony doctrine-orm
php ×4
apc ×1
autoloader ×1
caching ×1
cqrs ×1
doctrine-orm ×1
events ×1
optimization ×1
performance ×1
session ×1
symfony ×1