Оптимальный сервер (инт-магазин, почтовый сервер, итп)?

Question

[V A]

Всем Привет!
Возможно вопрос мой покажется нетривиальным, и у каждого на счет выбора серверных решений, свой "вкус", но все же.

Есть существующий выделенный сервер с 2-мя сайтами интернет-магазинами (Nginx+Php-fpm+Apache1+CMS-Битрикс). с почтой 150 юзеров (Postfix+Dovecot-IMAP+Postgrey), ну и панель управления ISPmanager 4.

Задача: Перейти на новый сервер, с более мощным железом. Как сделать чтобы не покупать домен (он уже есть на действующем сервере, хотелось бы отладить новый сайт для начала и только после всех проверок резолвить), настроить почтовый сервак (перенос 50 гб писем), web-сервер итп.

Как лучше организовать сервер (какие программы задействовать? сам думаю сделать Front-end=Nginx, back-End=Apache), на котором будут 2 интернет-магазина (с нагрузкой 10-15 тыс посещений), почтовый сервер, панель пока WebMin, но думаю купить ISPmanager 5. (или Vestacp)

Вот конфиг нового сервера

System hostname	Debian-84-jessie-64-LAMP 
Operating system	Debian Linux 8
Webmin version	1.791
Time on system	Fri May 13 15:48:44 2016
Kernel and CPU	Linux 3.16.0-4-amd64 on x86_64
Processor information	Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz, 12 cores
System uptime	3 hours, 33 minutes
Running processes	187
CPU load averages	1.02 (1 min) 1.06 (5 mins) 1.05 (15 mins)
CPU usage	0% user, 0% kernel, 0% IO, 100% idle
Real memory	610.95 MB used, 252.32 GB total
Virtual memory	0 bytes used, 4 GB total
Local disk space	187.49 GB used, 3.58 TB total

Answer 1

[spotifi]

В чем проблема изменить записи в домене после того как новый сервер будет настроен. Для этого DNS и существует - чтобы имя не было привязано к конкретному серверу.

Для тестирования можешь сделать домен третьего уровня на своем же.

У тебя большие проблемы с ПО если тебе нужен этот сервер.
Интернет-магазин с нагрузкой 30 000 посетителей в день прекрасно живет на оборудовании раза в 3 более слабом.

Comments

[V A]

Вот параметры нынешнего сервера:
Процессор
Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz 800.000 Mhz X 8
Оперативная память
32737720 kB
Файл подкачки (swap)
16777084 kB
Размер дискового пространства
1861526 Mb
Средняя загрузка
1.22
1.26
1.26
Продолжительность работы
146 days 5 hours 53 minutes
Количество процессов
695

[АртемЪ]

Интернет-магазин с нагрузкой 30 000 посетителей

Вы считаете, что нагрузка на интернет магазин зависит только от количества посетителей?
Сравните два магазина - у одного 5 товаров и тысяча посетителей, у другого 80тысяч товаров, и та же тысяча посетителей. Думаете нагрузка на сервер будет одинаковая?
Движок магазина может позволять производить сравнение характеристик товара - это нагрузка на сервер.
Нет такой фишки, и нагрузка в разы меньше.
Поэтому требуемая производительность сервера под интернет магазин может отличаться в сотни раз, при одинаковом количестве пользователей.

[spotifi]

АртемЪ:
Для справки: сайт о котором я говорю имеет порядка 15 000 товаров.

От количества товаров в БД нагрузка НЕ ЗАВИСИТ почти никак. При поиске товаров - это не проблема - современные БД прекрасно справляются и с МИЛЛИОНАМИ записей.

Разумеется там где нужно применяется специализированная БД для полнотекстового поиска. Или как минимум, специализированный функционал вашего любимого SQL-сервера.

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

Что меняется: нагрузка при большом количестве товаров - только при обновлении БД. Раз в сутки. Решается правильными (удобными и быстрыми) способами импорта.

С картинками тоже проблем нет. Они живут на отдельно сервере, в отдельном датацентре на cloud storage hosting. За картинки плачу порядка 1000 рублей в год. Да, не ослышались.

Сравнение по характеристикам? Ну откройте же наконец для себя векторные индексы. Тогда сервер может сравнивать за секунды сотни товаров - но процессор даже не вспотеет.

[spotifi]

Vgzrs 77424: Что то у вас не так. Этого должно хватать.

[АртемЪ]

spotifi: От количества товаров в БД нагрузка в основном и зависит.
Сравните - магазин торгующий сотовыми - 300товаров в базе данных, база данных весит 5мегабайт.
и магазин торгующий автозапчастями - несколько миллионов автозапчастей в базе, база данных занимает примерно 2террабайта.

Для первого магазина памяти 1Гб будет с большим запасом, и база будет размещаться полностью в памяти.
Для второго магазина все хуже - два террабайта БД не запихаешь в 1гб памяти, и в 32Гб тоже.

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

Как вам помогут векторные индексы, если у вас памяти мало, а база данных огромная?

[spotifi]

АртемЪ:
> Для первого магазина памяти 1Гб будет с большим запасом, и база будет размещаться полностью в памяти.

Специально изучал этот вопрос несколько раз.
Не все так просто, как вы думаете. Не так просто разместить всю БД в оперативной памяти, даже если памяти хватает.

Если не хочется оптимизировать ПО под это дело (переход на Tarantool, например, который прекрасно держит всю БД в оперативной памяти), то с помощью обычных SQL-серверов Вы этого не добьетесь никогда.

https://habrahabr.ru/company/mailru/blog/273695/

[spotifi]

АртемЪ:

> Для первого магазина памяти 1Гб будет с большим запасом, и база будет размещаться полностью в памяти.
> Для второго магазина все хуже - два террабайта БД не запихаешь в 1гб памяти, и в 32Гб тоже.

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

Ключевой момент, который вы упускаете - одномоментно никому не нужны все товары.

[АртемЪ]

spotifi: Я в курсе.
Просто согласитесь что для одинаково эффективной работы множества пользователей с БД в 2мегабайта и для работы с БД в 2террабайта железо нужно немного разное, при одинаковой эффективности ПО.

[neol]

Vgzrs 77424:
Покажите пожалуйста содержимое /etc/default/cpufrequtils на текущем сервере.

[spotifi]

АртемЪ:
> Для первого магазина не нужен никакой поиск - пользователь зашел, полистал странички и оформил заказ.
> Для второго магазина пользователь сначала ищет в базе каталожный номер запчасти, потом смотрит список запчастей с этим номером, и цены на них, сравнивает и только тогда покупает.

Бы говорим о вполне конкретной ситуации.
У меня 30 000 посетителей.
15 000 товаров.

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

Поэтому я и утверждаю, что у товарища проблемы с ПО. Не нужно типичным интернет-магазинам такого железа. Если конечно у них софт корректно работает.

[spotifi]

АртемЪ:
> Как вам помогут векторные индексы, если у вас памяти мало, а база данных огромная?

Не скажу. Сами подумайте. Вы же программист.
Даю подсказку - эту проблему даже не я сам решал. Воспользовался готовым ПО.

Еще одна подсказка - значительная часть товара почти что никому кроме поисковиков не нужна. Живые люди не ищут весь товар, не говоря уже о том, чтобы его просматривать.

[spotifi]

АртемЪ:
> Я в курсе.
> Просто согласитесь что для одинаково эффективной работы множества пользователей с БД в 2мегабайта и для работы с БД в 2террабайта железо нужно немного разное, при одинаковой эффективности ПО.

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

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

Если мы говорим о нормально написанном и настроенном ПО.
Вы, верно, избалованы мощностью современного железа.

Не так давно серьезные вещи делались относительно шустро на компьютерах, которые слабее нынешних смартфонов.

У оптимизации очень много возможностей.
Очень.

[spotifi]

АртемЪ:
> Для первого магазина памяти 1Гб будет с большим запасом, и база будет размещаться полностью в памяти.
> Для второго магазина все хуже - два террабайта БД не запихаешь в 1гб памяти, и в 32Гб тоже.

Многие современные сервера БД возникли еще в те времена, когда 256 М на хостинге было очень много и дорого. И они неплохо оптимизированы для работы в стестенных на ресурсы условиях.

[V A]

neol: cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to [e-mail], please.
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0 1 2 3 4 5 6 7
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 10.0 us.
hardware limits: 800 MHz - 3.40 GHz
available frequency steps: 3.40 GHz, 3.40 GHz, 3.20 GHz, 3.00 GHz, 2.80 GHz, 2.70 GHz, 2.50 GHz, 2.30 GHz, 2.10 GHz, 1.90 GHz, 1.70 GHz, 1.50 GHz, 1.40 GHz, 1.20 GHz, 1000 MHz, 800 MHz
available cpufreq governors: ondemand, userspace, performance
current policy: frequency should be within 800 MHz and 3.40 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 800 MHz (asserted by call to hardware).
analyzing CPU 1:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0 1 2 3 4 5 6 7
CPUs which need to have their frequency coordinated by software: 1
maximum transition latency: 10.0 us.
hardware limits: 800 MHz - 3.40 GHz
available frequency steps: 3.40 GHz, 3.40 GHz, 3.20 GHz, 3.00 GHz, 2.80 GHz, 2.70 GHz, 2.50 GHz, 2.30 GHz, 2.10 GHz, 1.90 GHz, 1.70 GHz, 1.50 GHz, 1.40 GHz, 1.20 GHz, 1000 MHz, 800 MHz
available cpufreq governors: ondemand, userspace, performance
current policy: frequency should be within 800 MHz and 3.40 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 800 MHz (asserted by call to hardware).
analyzing CPU 2:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0 1 2 3 4 5 6 7
CPUs which need to have their frequency coordinated by software: 2
maximum transition latency: 10.0 us.
hardware limits: 800 MHz - 3.40 GHz
available frequency steps: 3.40 GHz, 3.40 GHz, 3.20 GHz, 3.00 GHz, 2.80 GHz, 2.70 GHz, 2.50 GHz, 2.30 GHz, 2.10 GHz, 1.90 GHz, 1.70 GHz, 1.50 GHz, 1.40 GHz, 1.20 GHz, 1000 MHz, 800 MHz
available cpufreq governors: ondemand, userspace, performance
current policy: frequency should be within 800 MHz and 3.40 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 800 MHz (asserted by call to hardware).
analyzing CPU 3:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0 1 2 3 4 5 6 7
CPUs which need to have their frequency coordinated by software: 3
maximum transition latency: 10.0 us.
hardware limits: 800 MHz - 3.40 GHz
available frequency steps: 3.40 GHz, 3.40 GHz, 3.20 GHz, 3.00 GHz, 2.80 GHz, 2.70 GHz, 2.50 GHz, 2.30 GHz, 2.10 GHz, 1.90 GHz, 1.70 GHz, 1.50 GHz, 1.40 GHz, 1.20 GHz, 1000 MHz, 800 MHz
available cpufreq governors: ondemand, userspace, performance
current policy: frequency should be within 800 MHz and 3.40 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 800 MHz (asserted by call to hardware).
analyzing CPU 4:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0 1 2 3 4 5 6 7
CPUs which need to have their frequency coordinated by software: 4
maximum transition latency: 10.0 us.
hardware limits: 800 MHz - 3.40 GHz
available frequency steps: 3.40 GHz, 3.40 GHz, 3.20 GHz, 3.00 GHz, 2.80 GHz, 2.70 GHz, 2.50 GHz, 2.30 GHz, 2.10 GHz, 1.90 GHz, 1.70 GHz, 1.50 GHz, 1.40 GHz, 1.20 GHz, 1000 MHz, 800 MHz
available cpufreq governors: ondemand, userspace, performance
current policy: frequency should be within 800 MHz and 3.40 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 800 MHz (asserted by call to hardware).
analyzing CPU 5:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0 1 2 3 4 5 6 7
CPUs which need to have their frequency coordinated by software: 5
maximum transition latency: 10.0 us.
hardware limits: 800 MHz - 3.40 GHz
available frequency steps: 3.40 GHz, 3.40 GHz, 3.20 GHz, 3.00 GHz, 2.80 GHz, 2.70 GHz, 2.50 GHz, 2.30 GHz, 2.10 GHz, 1.90 GHz, 1.70 GHz, 1.50 GHz, 1.40 GHz, 1.20 GHz, 1000 MHz, 800 MHz
available cpufreq governors: ondemand, userspace, performance
current policy: frequency should be within 800 MHz and 3.40 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 800 MHz (asserted by call to hardware).
analyzing CPU 6:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0 1 2 3 4 5 6 7
CPUs which need to have their frequency coordinated by software: 6
maximum transition latency: 10.0 us.
hardware limits: 800 MHz - 3.40 GHz
available frequency steps: 3.40 GHz, 3.40 GHz, 3.20 GHz, 3.00 GHz, 2.80 GHz, 2.70 GHz, 2.50 GHz, 2.30 GHz, 2.10 GHz, 1.90 GHz, 1.70 GHz, 1.50 GHz, 1.40 GHz, 1.20 GHz, 1000 MHz, 800 MHz
available cpufreq governors: ondemand, userspace, performance
current policy: frequency should be within 800 MHz and 3.40 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 800 MHz (asserted by call to hardware).
analyzing CPU 7:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0 1 2 3 4 5 6 7
CPUs which need to have their frequency coordinated by software: 7
maximum transition latency: 10.0 us.
hardware limits: 800 MHz - 3.40 GHz
available frequency steps: 3.40 GHz, 3.40 GHz, 3.20 GHz, 3.00 GHz, 2.80 GHz, 2.70 GHz, 2.50 GHz, 2.30 GHz, 2.10 GHz, 1.90 GHz, 1.70 GHz, 1.50 GHz, 1.40 GHz, 1.20 GHz, 1000 MHz, 800 MHz
available cpufreq governors: ondemand, userspace, performance
current policy: frequency should be within 800 MHz and 3.40 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 800 MHz (asserted by call to hardware).

[АртемЪ]

spotifi: Еще раз - вы серьезно считаете что работа с БД размером 2Мб и 2Тб это одинаковая нагрузка?
И время потраченное на один запрос будет одинаковым при прочих равных?

[spotifi]

АртемЪ:
ага. у меня есть в обслуживании БД с парой миллиардов записей.
я знаю.

[spotifi]

АртемЪ:
все 2 терабайта даже за пару лет могут не понадобится ни для одного посетителя сайта ни разу.

[АртемЪ]

spotifi: Разумеется. Но в кэш их не положишь.
Поэтому каждый посетитель будет создавать тяжелые запросы к диску.
А товара мало - все будет в кэше, и к диску запросов минимум.
В итоге на одного пользователя требуется гораздо меньше процессорного времени, я уж не говорю про объем памяти и нагрузке на диск.

[V A]

spotifi: В какую сторону копать, если все-таки проблемы с ПО ?й

[V A]

Например у меня Apache не задействован, я так понял (до меня сайт делали)

[АртемЪ]

spotifi: И с этой вашей БД с парой миллиардов записей 30тыс пользователей будут работать так же быстро как и с БД у которой 500записей? На одном и том же железе?

[spotifi]

АртемЪ:
> Но в кэш их не положишь.
> Поэтому каждый посетитель будет создавать тяжелые запросы к диску.
> А товара мало - все будет в кэше, и к диску запросов минимум.

Откройте для себя уже индексы.

[spotifi]

Vgzrs 77424:
мерять где затыки - диски, процессор, память.
какой именно процесс.

[spotifi]

Vgzrs 77424:
Апач не всегда плохо.

[spotifi]

АртемЪ:
> И с этой вашей БД с парой миллиардов записей 30тыс пользователей будут работать так же быстро как и с БД у которой 500записей? На одном и том же железе?

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

))))

[spotifi]

Vgzrs 77424: Или, хороший вариант, временно перенести на другой сервер один из сайтов. И посмотреть а как ему там живется и не стало ли лучше на старом сервере. Повторить для всех трех остальных компонентов. Выявить - кто именно доставляет проблемы.

[spotifi]

Vgzrs 77424: Чаще всего это БД.
Но для БД есть инструменты профилирования. Можно посмотреть даже что именно за запросы больше всего времени требуют. И специально под них подправить индексы.

[АртемЪ]

spotifi: Понятно, у вас какое то супер эффективное ПО.
Которое одинаково эффективно работает с БД вне зависимости от количества записей, на одном и том же железе.
Действительно какая разница 500записей в базе или миллион.
База в 500записей умещается на диске размером 10Гб?
Отлично, значит и база в миллиард записей уместиться.

[spotifi]

АртемЪ:
Обычное ПО, грамотно написанное.
Пробуйте.
Возможности оптимизации - огромны.

[spotifi]

АртемЪ:
Правильно написанный сайт должен успевать выбирать данные из БД быстрее, чем время прохождения запроса между клиентом и сервером.

[spotifi]

АртемЪ:
Это кстати, не мое ПО, а обычные сервера PostgreSQL да Microsoft SQL Server.

[spotifi]

АртемЪ:
Мое - только механизм кэширования.

[АртемЪ]

spotifi: Как он сможет выбирать данные быстрее, если запрос - миллисекунды, а на чтение необходимого объема данных уходят десятки секунд?

[АртемЪ]

Например средний запрос к базе 1с у клиента отрабатывает за секунду. БД на обычном Microsoft SQL Server.
И что если эти запросы делать с веб сервера, то база данных волшебным образом начнет работать в десятки раз быстрее?

[spotifi]

АртемЪ:
Откройте для себя уже индексы и денормализацию (не нормализацию, а денормализацию).
Не нужно читать таких объемов.

[spotifi]

АртемЪ:
1C - уже готовый продукт.
Я же говорил об разработке интернет-магазина, изначально заточенного на скорость.

[АртемЪ]

spotifi: А данные где будет интернет магазин брать вы думали?
В некоторых случаях они будут хранится в БД сайта, в некоторых случаях в сторонних сервисах.

По поводу индексов - тупые разработчики БД конечно же о них не знают.
Иначе давно бы уже разработали базу данных которая работала бы одинаково быстро, вне зависимости от размера.

[spotifi]

АртемЪ:
> А данные где будет интернет магазин брать вы думали?

там в основном товар, остальное мелочи.

1 000 единиц товаров * ( 100 байт название товара + 1000 байт на описание) = 1 мегабайт.
плюс столько же на индексы, если речь идет о жестком индексировании - итого 2 мегабайта на каждые 1000 единиц товара.

> В некоторых случаях они будут хранится в БД сайта, в некоторых случаях в сторонних сервисах.

Вы о чем?

> По поводу индексов - тупые разработчики БД конечно же о них не знают.

Знания нужны, да.
Вот Вы, к примеру, знаете когда нужно использовать индексы типа B-Tree, хеши или битовые?

> Иначе давно бы уже разработали базу данных которая работала бы одинаково быстро, вне зависимости от размера

Уже лет 40 как существует.

[АртемЪ]

spotifi: Вы какой-то бред несете.
Нафига тогда яндексу, гуглу и прочим крупным сервисам строить датацентры?
Если существуют БД которые работают одинаково быстро вне зависимости от размеров, значит можно все эти БД размещать не в датацентрах, а на обычном ноутбуке.

[spotifi]

АртемЪ:

1. Их БД не влазят в один-единственный компьютер.
2. Число их пользователей исчиляется десятками миллионов одновременных запросов.
3. Запросы этих пользователей - разноплановы.

Вы приводили в пример 1С....

При начиличе БД 1С на 100 терабайт - когда вы приходите покупать что-то, то компьютер продавца находит в БД десяток товаров, десяток цен и десяток остатков товаров. Это даже не мегабайты, а в лучшем случае килобайты. С этим справляется обычный современный компьютер.

Если бы пользователями 1С были сотни миллионов человек одномоментно, то на ту же БД им пришлось построить датацентр.

Answer 2

[Дмитрий Александров]

Может с такими нагрузками лучше и дешевле будет собрать свой сервер и купить белый статический IP ? Тогда сможете наращивать мощность по необходимости, поменять проц или докинуть оперативы, на крайний случай поставить 2 сервер на который вынести только БД и это сильно разгрузит основной сервер.

Как сделать чтобы не покупать домен (он уже есть на действующем сервере, хотелось бы отладить новый сайт для начала и только после всех проверок резолвить)

Вариант на коленке:
Имеем(пример):
1) Старый сервер IP 10.200.50.1
2) Новый сервер IP 10.100.80.5
3) Днс записи ссылающиеся на старый сервер magaz.ru и supermagaz.ru

Делаете следующее:
1)Дампите базы и переносите все на новый сервак
2)На новом сервере прописываете ему имена как будто на боевой сервер(чтобы сервер считал что онmagaz.ru и supermagaz.ru) но не перекидываете у днс хостера записи на этот новый сервак(DNS всему миру будет говорить что сайты все еще на старом адресе).
3) На компе\компах откуда будете все отлаживать в hosts(C:\Windows\System32\drivers\etc\hosts) создаете записи:

10.100.80.5 magaz.ru
10.100.80.5 supermagaz.ru

В итоге весь мир по старинке работает с магазинами на старом сервере, а Ваши компы из п3 работают с магазинами уже на новом сервере, сервер чувствует себя хорошо и считает настоящим и боевым. Когда все доделаете то просто у DNS хостера меняете записи IP сервера на новые, клиенты вообще не заметят подмены и перехода.

Comments

[spotifi]

только там нет таких нагрузок, чтобы нужно было наращивать сервер.

[Дмитрий Александров]

spotifi: ситуации разные бывают, может быть там кто то когда то сделал не особо оптимизировав все. Клиент был доволен, сейчас тоже доволен и переделывать ничего не хочет т.к. все и так устраивает а вот запас ресурсов хочет сделать и это проще для него. Может они хотят в магазинах тотальную акцию устроить со скидками в 50-75%, тогда из 15000 посетителей вырастет до 100000-150000.

[spotifi]

Дмитрий Александров: вы и метод знаете как добиться такой посещаемости?

[Дмитрий Александров]

spotifi: я как то видел магазинчик с тряпками женскими, маленький такой, народ туда ходил довольно вяло. Так вот они устроили скидку в честь 10 летия, скидка всего в 30%-40%. С магазина за 2 дня выгребли вообще весь товар, даже то что уже пару лет лежало и не продавалось. Владелица магазина относительная знакомая моя, сказала что не заработала ни копейки за эти дни т.к. товар ушел по закупочной цене практически, но клиентская база выросла очень хорошо и так же хорошо сыграла роль на спрос после. Народ стал намного чаще заходить, появилось намного больше заказов. Как дела сейчас(была эта история 4 года назад) не знаю т.к. давно переехал из того города.

Answer 3

[Виктор Таран]

1 варинат - самый быстрый "битрикс веб окружение" интер - интер -интер, готово.
2. вариант веста
3. для тех кто хорошо знает линукс ispconfig3

теперь по домену тут вообще все до тупости просто используешь тот же домен.
Только прописываешь его в host файлах на сервере и у себя.
Как надоест тестить удаляешь его из хоста и переписываешь реальный.

Comments

[V A]

Спасибо, я так понял битрикс окружение, это типо VM

[Виктор Таран]

нет не имхо, но если говорить о производительность-скорость-простота развертывания, то однозначно да.