Magento有一个回退机制,通过一组定义的路径检查预期文件的存在,有助于防止错误和主题问题。 It's implemented like this:
/**
* Check for files existence by specified scheme
*
* If fallback enabled, the first found file will be returned. Otherwise the base package / default theme file,
* regardless of found or not.
* If disabled, the lookup won't be performed to spare filesystem calls.
*
* @param string $file
* @param array &$params
* @param array $fallbackScheme
* @return string
*/
protected function _fallback($file, array &$params, array $fallbackScheme = array(array()))
{
if ($this->_shouldFallback) {
foreach ($fallbackScheme as $try) {
$params = array_merge($params, $try);
$filename = $this->validateFile($file, $params);
if ($filename) {
return $filename;
}
}
$params['_package'] = self::BASE_PACKAGE;
$params['_theme'] = self::DEFAULT_THEME;
}
return $this->_renderFilename($file, $params);
}
作为Magento主题开发人员,您有两种选择:您可以尽可能少地添加新主题并依赖回退,或者您可以将后备主题中的所有内容复制到新主题中并进行修改(在这种情况下)在找到目标之前,后备必须迭代更少的文件。建议采用前一种方法。后者不是。
复制这些文件肯定是混乱的,但另一方面,似乎后备应该相当昂贵,特别是如果(作为一个好的,精悍的编码器)你确保尽可能多的文件回退。因此,如果我采取措施尽量减少发生的后备量,我发现自己想知道Magento网站是否会表现更好。
我在网上搜索过,但没有找到关于这个问题的任何信息,而且我还不熟悉Magento自己描述后备的情况。是否有关于此回退机制的实际性能成本的信息?
答案 0 :(得分:4)
性能成本为37。
不那么狡猾:不幸的是,你的问题无法回答。虽然(显然)说明这些文件和目录的性能成本,但由于其他因素,Magento(和任何LAMP应用程序)将因SQL开销和CPU更快地遇到性能瓶颈。现代Web应用程序的性能调优往往不会在应用程序级别上发生,而是将应用程序视为不可更改的blob并购买/配置最佳的硬件设置。
如果有人对Magento进行了基准测试,那么他们就没有公开分享这些信息。
答案 1 :(得分:0)
性能成本,但像Alan说的那样,它将取决于您的服务器架构而不是应用程序。
值得注意的是,Magento也有代码文件的回退机制,这也可能花费你宝贵的毫秒数。与主题后备不同,有一个解决方法。 Magento将其称为"编译器"。
通常,在请求加载类时,Autoloader会查看四个 查找相应PHP文件的位置: app / code / local , app / code / community , app / code / core ,最后是 lib 。如果你想用你自己的版本重载某些核心代码,这很有用,但是 由于散落在周围的大量课程,因此速度很慢 文件系统。
因此Magento编译器确保Autoloader只需要查看 includes / src 并打开更少的文件。
理论上,这应该没什么区别,因为你的服务器应该缓存这些文件,但是你必须阅读完整的文章才能理解为什么它不是&#39切割干燥。
http://www.byte.nl/blog/should-i-use-the-magento-compiler
轶事证据:在拥有大量第三方模块的商店中,只需启用编译,我们就可以看到从~2秒到第1.6秒的时间到第一字节的下降
警告字:某些第三方模块未正确构建,并且在启用编译时会导致整个存储中断。通常这是因为他们尝试使用相对路径include_once
或require_once
某个文件,并且它不起作用,因为在启用编译时文件位于不同的目录中。