Установка и конфигурирование
Во время установки я рекомендую отключить все дополнительные опции и пакеты. Все, что нужно для magento мы поставим позже. Также желательно отключить firewall и selinux, как минимум до завершения установки.

Несколько слов об используемом ПО. nginx – это быстрый и крайне нетребовательный к ресурсам HTTP (и не только) сервер, который используется для раздачи статики (картинки, стили, javascript), а также позволяет работать с динамическим контентом используя FastCGI API. PHP-FPM – это улучшенная реализация интерфейса FastCGI для PHP, распространяемая в виде патча к исходникам PHP. Сервер FastCGI позволяет работать по TCP или используя локальный socket. APC – “оптимизатор” PHP, реализующий опкод кеширование для скриптов и, помимо этого, предоставляющий интерфейс для хранения данных скрипта в shared памяти. Его применение имеет смысл только в FastCGI или Apache SAPI режимах.

Репозиторий centos не содержит php-fpm. Конечно, можно самостоятельно скомпилировать PHP 5.2.11 + php-fpm, но намного более “правильный” с точки зрения удобства обновления и поддержки способ – использование репозитория. Для использования php5.2.x + fpm на наших серверах мы создали репозиторий (rpms.varien.com). В настоящий момент поддерживается CentOS/RHEL 5, архитектуры i386 и x86_64. Также нам потребуется подключить репозиторий EPEL, содержащий многие программы и библиотеки, отсутствующие в системных репозиториях CentOS/RHEL.

Подключение репозиториев:

  # rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
  # wget http://rpms.varien.com/varien-release-1-1.centos.varien.noarch.rpm
  # rpm -Uvh varien-release-1-1.centos.varien.noarch.rpm

Устанавливем нужное нам ПО:

  # yum install nginx
  # yum install php-fpm php-mysql php-gd php-mcrypt php-dom
  # yum install php-pecl-apc
  # yum install mysql-server

Включаем автостарт необходимых сервисов:

  # /sbin/chkconfig nginx on
  # /sbin/chkconfig mysqld on
  # /sbin/chkconfig php-fpm on

Конфигурируем nginx (файл /etc/nginx.conf). В данном примере магазин расположен по пути /magento/ в папке /var/www/html/magento. Поддерживается URL Rewrite (аналог конфигурации для apache mod_rewrite), для php используется PHP-FPM подключенный через unix socket.

user              nginx;
worker_processes  1;
error_log         /var/log/nginx/error.log;
pid               /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] $request '
                      '"$status" $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;
    sendfile        on;
    keepalive_timeout  65;

    # fastcgi nodes
    upstream  backend  {
        server unix:/tmp/fcgi.sock;
    }

    server {
        listen       80;
        server_name  example.local;
        root   /var/www/html;
        autoindex off;

        gzip on; # use gzip compression
        gzip_proxied any; # enable proxy for the fcgi requests
        gzip_types text/plain text/html text/css text/javascript;

        # protection (we have no .htaccess)
        location ~ (^/magento/(app/|includes/|lib/|/pkginfo/|var/|report/config.xml)|/\.svn/|/.hta.+) {
            deny all;
        }

        # handle all .php files, /downloader and /report
        location ~ (\.php|/downloader/?|/report/?)$ {
            if ($request_uri ~ /(downloader|report)$){ # no trailing /, redirecting
                rewrite  ^(.*)$ $1/ permanent;
            }
            fastcgi_index index.php;
            include /etc/nginx/fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            if (-e $request_filename) { # check if requested path exists
                fastcgi_pass backend;
            }

        }

        # handle magento
        location /magento/
        {
            # set expire headers
            if ($request_uri ~* "\.(ico|css|js|gif|jpe?g|png)$") {
                expires max;
            }
            # set fastcgi settings, not allowed in the "if" block
            include /etc/nginx/fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root/magento/index.php;
            fastcgi_param SCRIPT_NAME /magento/index.php;
            # rewrite - if file not found, pass it to the backend
            if (!-f $request_filename) {
                fastcgi_pass backend;
                break;
            }
        }
    }
}

Конфигурация PHP-FPM (файл /etc/php-fpm.conf). Используется локальный socket. Наиболее важный параметр тут – max_children, его значение должно быть подобрано с учетом конфигурации (память, CPU) в процессе тестов нагрузки.

<configuration>
        <section name="global_options">
                <value name="pid_file">/var/run/php-fpm.pid</value>
                <value name="error_log">/var/log/php-fpm.log</value>
                <value name="log_level">notice</value>
                <value name="emergency_restart_threshold">10</value>
                <value name="emergency_restart_interval">1m</value>
                <value name="process_control_timeout">5s</value>
                <value name="daemonize">yes</value>
        </section>
        <workers>
                <section name="pool">
                        <value name="name">default</value>
                        <value name="listen_address">/tmp/fcgi.sock</value>
                        <value name="listen_options">
                                <value name="owner"></value>
                                <value name="group"></value>
                                <value name="mode">0666</value>
                        </value>
                        <value name="php_defines">
                        </value>
                        <value name="user">nginx</value>
                        <value name="group">nginx</value>
                        <value name="pm">
                                <value name="style">static</value>
                                <value name="max_children">10</value>
                                <value name="apache_like">
                                        <value name="StartServers">20</value>
                                        <value name="MinSpareServers">5</value>
                                        <value name="MaxSpareServers">35</value>
                                </value>
                        </value>
                        <value name="request_terminate_timeout">0s</value>
                        <value name="request_slowlog_timeout">0s</value>
                        <value name="slowlog">logs/slow.log</value>
                        <value name="rlimit_files">1024</value>
                        <value name="rlimit_core">0</value>
                        <value name="chroot"></value>
                        <value name="chdir"></value>
                        <value name="catch_workers_output">yes</value>
                        <value name="max_requests">500</value>
                        <value name="allowed_clients">127.0.0.1</value>
                        <value name="environment">
                                <value name="HOSTNAME">$HOSTNAME</value>
                                <value name="PATH">/usr/local/bin:/usr/bin:/bin</value>
                                <value name="TMP">/tmp</value>
                                <value name="TMPDIR">/tmp</value>
                                <value name="TEMP">/tmp</value>
                                <value name="OSTYPE">$OSTYPE</value>
                                <value name="MACHTYPE">$MACHTYPE</value>
                                <value name="MALLOC_CHECK_">2</value>
                        </value>
                </section>
        </workers>
</configuration>

Запускаем nginx и php-fpm:

  # /etc/init.d/php-fpm start
  # /etc/init.d/nginx start

Запускаем mysqld, и назначаем пароль для mysql рута

  # /etc/init.d/mysqld start
  # /usr/bin/mysql_secure_installation

Теперь добавляем пользователя и базу данных magento:

  # mysql --user=root -p
  mysql>  CREATE USER 'magento'@'localhost' IDENTIFIED BY 'my_password';
  mysql>  CREATE DATABASE magento;
  mysql>  GRANT ALL PRIVILEGES ON `magento`.* TO 'magento'@'%' WITH GRANT OPTION;

На этом этапе все готово для установки magento.

Установка magento
Для установки magent в консоли я использовал wiki-статью installing magento via ssh.

1. Скачиваем magento:
   # cd /var/www/html
   # wget http://www.magentocommerce.com/downloads/assets/1.3.2.4/magento-1.3.2.4.tar.gz
   # tar -xvzf magento-1.3.2.4.tar.gz
2. Если нам нужна тестовая база данных (sample db) – скачиваем и распаковываем ее, если нет – пропускаем этот шаг.
   # wget http://www.magentocommerce.com/downloads/assets/1.2.0/magento-sample-data-1.2.0.tar.gz
   # tar -xvzf magento-sample-data-1.2.0.tar.gz
   # mv magento-sample-data-1.2.0/media/* magento/media/
   # mysql --user=root magento -p < magento-sample-data-1.2.0/magento_sample_data_for_1.2.0.sql
3. Назначаем корректного владельца всем файлам:
   # chown -R nginx:nginx magento

Теперь переходим к этапу настройки magento, указав в браузере адрес нашей установки, например http://example.local/magento/. Должен заработать magento installation wizard. В настройках базы данных указываем пользователя magento (и назначенный вами пароль), адрес хоста – localhost. Также следует отметить флаг “Skip Base URL validation before next step”. Дальнейшая конфигурация и использование ничем не отличается от обычных установок magento.

Дополнительная оптимизация
Прежде всего следует перенести magento cache в APC, так как файловое хранилище достаточно неєффективно, особенно при параллельных запросах. Для этого в секцию globals файла magento/app/etc/local.xml добавляем секцию cache:

    <cache>
         <backend>apc</backend>
         <prefix>MY_MAGENTO_</prefix>
    </cache>

Также рекомендуется оптимизация mysql, ip стека linux, подбор параметров APC, конфигурирование firewall, но все это уже выходит за рамки данной заметки.

Для того чтобы наши читатели узнали больше о том, что мы производим – мы решили создать серию видеопрезентаций о нашем продукте.

Сегодня мы представляем вашему вниманию первую из них. Эта презентация (или скринкаст) является вводной и поверхностно рассказывает о том, что «умеет» Magento. В дальнейшем мы планируем рассмотреть интересующую вас функциональность более детально.
Если у вас есть пожелания или замечания – сообщите нам.

PS: Хочу добавить, что несмотря на то, что все представленные в скринкасте страницы Magento содержат текст на английском языке, Magento поддерживает локализацию, и её интерфейс очень просто можно преобразовать с англоязычного в русскоязычный.

Скачать файл презентации в более высоком качестве можно, пройдя по ссылке: Знакомство с Magento.

Параметры видео:
General
Format                           : MPEG-4
File size                        : 9.01 MiB
Duration                         : 7mn 40s

Video
Format/Info                      : Advanced Video Codec
Format profile                   : High@L4.1
Width                            : 1 024 pixels
Height                           : 768 pixels

Audio
Format/Info                      : Advanced Audio Codec
Format profile                   : LC
Format settings, SBR             : Yes
Format settings, PS              : Yes

Magento – это приложение PHP/Zend, интенсивно использующее ресурсы центрального процессора. С момента выхода версии 1.1.6, каждая новая версия включала в себя некоторые механизмы, призванные улучшать производительность платформы. Основной целью является уменьшение потребления ресурсов для данного e-магазина (попросту говоря – меньше процессорного времени), для того чтобы обслуживать большее количество пользователей на том же самом аппаратном обеспечении.

Одним из путей достижения лучшей производительности является оптимизация скорости генерации страниц PHP. На широко распространенных “LAMP” серверах обычно используется Apache с модулем mod_php, или, иногда, с модулем fast_cgi.

Zend (компания, поддерживающая PHP), выпустила специализированный продукт – Zend Server, который включает в себя стэк веб-приложений, и, помимо некоторых других возможностей, увеличивает скорость работы путем кэширования страниц, и реорганизации и ускорения байт-кода.

Apache в связке Zend Server являются альтернативой обычному Apache с mod-php для запуска Magento. Целью этого исследования является исследование и оценка улучшений производительности за счет использования данного ПО.

Большое спасибо Yoav Kutner (CTO компании Varien) за предоставленные заполненные тестовые каталоги для версий Magento 1.2 и 1.3. Также спасибо лаборатории Zend за помощь в конфигурации и тонкой настройке Zend Server, а также за полное объяснение механизма работы данного решения.

Используемые методы и инструменты

Бенчмарки делались с помощью утилиты siege (версия 2.66-2), с различным количеством одновременных потоков (5, 10, 20 and 40). Каждый поток открывал соединение с веб-сервером, запрашивал страницу и начинал все сначала после того, как страница была считана.

Тесты запускались по 5 минут каждый, и расчитывалось среднее количество полученных страниц для этого бенчмарка.

Проводились два типа тестов: первый – простой, мы просто загружали главную страницу в цикле, как можно быстрее.

Второй тест базировался на логах загрузки всех элементов броузером при посещении страницы (включая css, js, картинки). Так как загрузка одной страницы обычно вызывает загрузку нескольких элементов, отображаемое число будет значительно больше, чем количество страниц, реально видимых пользователю. На 18 страниц, просмотренных пользователем, приходится 91 скачанный элемент, среднее соотношение примерно 1 к 5.

Все результаты были получены на одном и том же “железе” и операционной системе, для целей тестирования. Обратное проксирование не использовалось. Во время запуска тестово был активен АРС кеш байт-кода. Это было стандартное окружение по умолчанию, без применения тонких настроек.

Железо:

2 процессора: Quad-Core AMD Opteron™ Processor 2376 (2.3GHz), 8GB RAM

Софт:

ОС: Linux (2.6.27.10-grsec) Debian (Lenny)
Веб-сервер: Apache2 (2.2.9-10+lenny2)
PHP (mod-php): mod-php5 (5.2.6.dfsg.1-1+lenny3) / php-apc (3.0.19-2)
PHP (Zend Server): zend-pe (1.0.0-1+b47) / mod-php5-zend-pe (5.2.9+b75)

Репозитории:

deb http://ftp.fr.debian.org/debian/ lenny main
deb http://security.debian.org/ lenny/updates main
deb http://volatile.debian.org/debian-volatile lenny/volatile main
deb http://repos.zend.com/deb/pe pe non-free

Тестирование разных версий Magento

Эти тесты были выполнены в каталоге с более чем 80 000 (далее – 80k) продуктов.

Графики показывают среднее количество запросов в секунду, успешно обработанных сервером во время пятиминутного теста.

Загрузка главной страницы

Magento 1.3 собирает главную страницу гораздо быстрее, чем версия 1.2. Включенный Flat-каталог не сильно помогает в отображении главной страницы, и даже, похоже, замедляет процесс ее сборки при большой нагрузке. Производительность версии 1.3 в два раза выше чем 1.2 при небольших нагрузках, и на 33% больше при больших нагрузках.

При “стандартной” загрузке мы можем отметить 40%-ный прирост производительности в версии 1.3 по отношению к версии 1.2, по крайней мере для домашней страницы.

Полный цикл посещения

График показывает небольшое увеличение в версии 1.3 по сравнению с 1.2, механизм flat-каталога дает общее улучшение, которое существенно увеличивает производительность.

Резюмируя, можем привести такие значения:

Версия 1.2 -> 1.3 : +66%
Версия 1.3 -> 1.3+FС : +20%

Apache + mod-php по сравнению с Apache + Zend Server

Zend Server (далее ZS) предлагает несколько встроенных технологий для увеличения производительности приложений:

• Zend Optimizer+ выполняет оптимизацию и кэширование байт-кода. Это увеличивает скорость PHP-приложений путем исключения процесса чтения скриптов с диска и их компилирования. Zend Optimizer+ запускается автоматически, и установка вашего приложения поверх Zend Server (ZS) – это всё, что вам нужно сделать чтобы насладиться его преимуществами. Во время тестов с ZS, кэш APC был деактивирован, так как Zend optimizer+ делает ту же работу.
• Zend Page Cache позволяет кэшировать PHP страницы целиком. Кэширование страниц значительно увеличивает производительность веб-приложений, в то же время поддерживая динамические возможности с помощью системы правил кэширования, построенной на параметрах запросов и данных сессий пользователей. Кэширование страниц также имеет преимущество в том, что не требует никаких изменений в коде, и может быть настроено через интерфейс Zend Server. Только “pro”-версия включает в себя эту часть ПО, которая однозначно изменяет производительность к лучшему, в чем мы и убедимся через минуту.
• Zend Data Cache это набор функций API, позволяющих разработчику сохранять и управлять данными (PHP строки, массивы и другие данные) и даже выдавать элементы либо из кэша диска, либо из кэша разделяемой памяти. Zend Data Cache позволяет настроить тонкое кэширование там, где полное кэширование страниц невозможно. Предлагаемый API легок в использовании в существующем коде, и во многих случаях разработчик может пропускать существующие участки кода, просто оборачивая их API кэширования. Эта возможность может быть использован путем незначительной доработки исходного кода ПО Varien.

Примечание: Zend Optimizer+ и Zend Data Cache доступны в бесплатной версии Zend Server, в то время как Zend Page Cache требует покупки лицензии Zend Server (полное сравнение Zend Server и Zend Server Community Edition доступно на http://www.zend.com/en/products/server/editions).

Настройка Zend Server для Magento

В бенчмарке были определены 2 правила кэширования:

Первое правило кэширует файлы JavaScript, которые динамически подключаются к каждому запросу Magento. Это простое правило привело к значительному улучшению времени отклика.

Второе правило кэширует все веб-страницы, посещенные пользователями, у которых нет товаров в корзине и нет истории посещений (когда корзина не пустая, либо сохранена история пользователя – нет смысла в кэшировании страницы). Как вы видите на картинке внизу, это было сделано с помощью проверки переменных $_SESSION и разделению по $_SERVER['REQUEST_URI'] в дополнение к QUERY_STRING.

Наконец, Zend Optimizer+ был включен для оптимизации и кэширования PHP байт-кода.

Как видите, Zend Page Cache оказался очень мощной функцией. Он требует тонкой и тщательной настройки, но взгляните результаты:

Главная страница / каталог из 80 000 продуктов

Загрузка на главной странице не сильно повлияла на результаты, хотя при большой нагрузке на сервер (40 параллельных заросов), Zend Server (с или без page cage) немного лучше чем mod_php, но практически никакого реального влияния на тест. Выигрыш в 5% и даже меньше не является серьезным фактором и лежит в пределах статистической ошибки тестов.

Полное посещение / 80k продуктов

График говорит сам за себя, при любой нагрузке Zend Server с Page Cache и включенным flat каталогом в Magento действительно улучшают производительность.

Сравнивая 1.3 + flat каталог с такой же конфигурацией, но с установленной бесплатной версией ZS вместо APC, наш сервер получил до 15% больше производительности.

Если же использовать полный Zend Server (с лицензией, в который включено кэширование страниц) на версии 1.3 с flat каталогом, сервер получил до 30% прироста производительности!

Mod PHP + APC -> ZS: +15%
Mod PHP + APC -> ZS с лицензией: +30%

Время отклика

Главная страница / 80k продуктов

Этот график показывает время отклика на домашней странице во время загрузки. При значительной нагрузке, ZS дал до 35% сокращения времени отклика во время загрузки.

Полное посещение / 80k продуктов

Кэширование страниц сокращает время отклика во время полного посещения сайта даже под очень тяжелой нагрузкой. Выгоды от использования кэширования страниц в любом случае существенны, даже при стандартной загрузке. Можем засчитать 35%-ный выигрыш при серьезной загрузке в случае использования любой (бесплатной или лицензированной) версии ZS.

При средней и легкой загрузке, кэширование страниц дает гораздо больший эффект чем может дать бесплатная версия ZS. Этот неожиданный результат, вероятно, является следствием того, что механизм кэширования показал себя неэффективным при большой нагрузке, так как система использует свои ресурсы по-другому.
У нас не было времени проверить, что именно является причиной – процессор, Линукс или сам ZS, однако тесты были проделаны несколько раз с одинаковыми результатами.

Таким образом, запомните, что выгоды механизма кэширования страниц в ZS будут становиться все менее эффективными по мере роста загрузки сервера. При обычной нагрузке, алгоритм Page Cache дал уменьшение времени загрузки до примерно 40%.

Дополнительный технические детали тестов

Тестовые данные

Все тесты были проведены с готовыми тестовыми данными (предоставленными компанией Varien)

Описание тестов

Тест главной страницы

Каждый поток загружает главную страницу без сохранения cookies, чтобы сымитировать одновременных пользователей.

Тест полного посещения

У нас есть список запросов, основанный на посещении сайта с помощью реального браузера. Каждый одновременный поток загружает каждый элемент один за другим так быстро как только сможет, и перегружается после удаления его cookies.

Список запрашиваемых страниц для базы данных из 80k продуктов (с информацией POST где возможно) здесь.

Планируемые тесты

Mage компилятор

Во время подготовки этих тестов, вышла версия 1.3.1.1, включающая модуль Mage_Compiler, и сразу за ней готовилась к выпуску версия 1.3.1.2, так что мы просто не успели включить некоторые тесты в этот обзор. Просто предположим, что весь механизм предназначен для уменьшения работы по вводу-выводу, с помощью включения большинства классов в несколько сборных файлов. Если ваши сервера использовали для работы в основном RAM, вы не ощутите значительного прогресса в производительности. Однако, если в серверах мало RAM, либо они в основном используют диски, вы убедитесь в выгодах использования данных возможностей!

Nginx

У нас не было достаточно времени для оценки результатов тестов с Nginx + PHP. Это решение давало результаты, промежуточные между Magento 1.3 + FC и Magento 1.3 + Zend Server (без Page cache). Так что эта комбинация достигала средних значений производительности, в отличие от Magento 1.3 + Zend Server или еще более продвинутых вариантов.

Выводы

Во-первых, позвольте заявить, что никакие электроны не были заряжены и не пострадали во время этих тестов. Возможно один или два СТО были вынуждены пострадать от кофейных вливаний, но чего только не сделаешь ради лучшего будущего E-commerce!

Если хотите более профессионального заключения, то можем сказать, что использование бесплатной версии ZS сказывается только положительно и действительно может заменить APC.

При использовании лицензированной версии ZS, механизм Page Cache очень эффективен, и может сократить используемые ресурсы железа на 25% для поддержания тех же возможностей хостинга. В некоторых случаях это может обернуться прямым сокращением расходов на сервера.

О Zend Server : это ПО имеет множество других полезных функций, но в этом отчете мы коснулись только тех, что так или иначе связаны с производительностью. Обо всем остальном несложно узнать, посетив веб-сайт Zend для гораздо более детального описания возможностей Zend Server.

И последнее – настраивая сервер со всеми оптимизациями и используя приведенные рекомендации, на базе dual AMD 2376 с 8 Gb RAM, использующий ZS и кэширование страниц, вы сможете достичь уровня до 40 000 уникальных посетителей в день, что соответствует 2 500 одновременных сессий Magento при максимальной загрузке (при вынесении базы данных на отдельный сервер, и использовании обратного прокси типа Squid или Varnish перед веб-сервером).

Эта оценка сильно зависит от сложности веб-сайта и типичного поведения ваших пользователей, но для стандартного сайта и обычного использования вы можете ожидать загрузки главной страницы в пределах 2 секунд.

И напоследок примерное суммарное сравнение производительности упомянутых конфигураций:

Эта статья доступна также на английском и французском языке.

Права: Оригинал этой статьи опубликован под лицензией Creative Commons “Attribution-Noncommercial-Share Alike 3.0″ License. Только три компании (NBS System, Zend и Varien) могут использовать её в коммерческих целях.

Данная статья открывает серию, посвященную этой иерархии, пронизывающей все уровни приложения. Сегодня мы рассмотрим лишь базовые уровни структуры магазинов и постараемся определиться с терминологией, используемой в панели управления и коде Magento.

Для начала давайте взглянем на абстрактную диаграмму сайтов, магазинов и групп магазинов:

Как видно на рисунке, структура магазинов имеет 4 уровня иерархии:

• Глобальный (global или default)
• Уровень вебсайтов (website)
• Уровень групп магазинов (store или store group)
• Уровень магазинов (store views)

Глобальный уровень (global, default) представляет собой одну инсталляцию кода и одну базу данных, с которыми работает Magento.

В действительности, Magento поддерживает работу с несколькими базами данных. Например, для улучшения производительности можно использовать несколько серверов БД, построив master-slave репликацию, и сконфигурировать Magento для чтения данных со slave БД, и записи данных в master БД. Также Magento может использоваться в кластере, когда на каждом веб-узле кластера есть собственная копия кода Magento, и веб-узлы работают с одним, с двумя (master-slave), или с несколькими (один master для записи и по одному slave для чтения на каждый веб-узел) серверами БД. Но об этом мы еще расскажем, пока же, для простоты изложения, условимся считать, что одна инсталляция Magento работает с одной базой данных.

Теоретически, с незначительными изменениями кода (добавив, помимо уже существующей поддержки префиксов имён таблиц, также использование этих же префиксов для имён ключей и индексов), можно было бы устанавливать несколько экземпляров Magento в одну базу данных. Но вы сейчас увидите, почему в этом никогда не было необходимости

Уровень вебсайтов (website) позволяет:

• различные базовые валюты для разных вебсайтов
• назначать различные начальные цены для продуктов на разных вебсайтов
• назначить разные статус одного и того же продукта на разных вебсайтах
• разделить клиентские базы

Уровень групп магазинов (store или store group) позволяет:

• сгруппировать магазины для удобства управления
• назначить группам разные корневые категории каталога

Стандартные темы Magento также предоставляют блок для выбора группы сайтов на фронтенде.

Уровень магазинов (store view) позволяет:

• задавать различные значение большинства атрибутов продуктов и категорий каталога
• иметь различную видимость продуктов в разных магазинах

Стандартные темы Magento также предоставляют блок для переключения между магазинами на фронтенде.

Любые уровни иерархии позволяют задавать различные значения для подавляющего большинства конфигурационных параметров Magento, включая доменное имя и ссылки. Это позволяет как собрать воедино, так и разделить видимые клиентам магазины, например, разнеся их по различным доменам.

Всеми магазинами можно управлять из единой панели управления, что позволяет упростить процесс переноса информации между магазинами, или ее консолидации по всем магазинам для построения отчетности с динамически настраиваемыми фильтрами.

Давайте рассмотрим несколько практических примеров много-сайтовых инсталляций Magento.

Пример 1. Продавец поздравительных открыток с надписями на разных языках:

• Единый каталог продукции
• Одна учетная валюта
• Только электронные способы оплаты (напр. Paypal) и всемирная служба доставки (напр. DHL)
• Несколько языковых версий

Пример 2. Мультинациональный бренд ювелирных украшений:

• Единый каталог
• Несколько региональных подразделений
• Клиентская база сегментирована по регионам
• Различные валюты учета в разных странах
• Поддержка национальных платежных систем и служб доставки
• Различные языки в странах присутствия

Пример 3. Интернет-магазин с широким ассортиментов продукции:

• Единая базовая валюта
• Общая клиентская база
• Различные типы продукции (мебель, электроника, одежда)

Демо-инсталляция такого магазина доступна по адресу www.magento-mall.com

Также рекомендую ознакомиться со обзором на английском языке:
Overview: How Multiple Websites & Stores Work