Понятия не имею. Чисто гипотетически - любая.
Ну и пусть загрузка стремится к 100% в обоих вариантах. Ну должны же быть сопутствующие потери на виртуализацию ?
Раз "пятничная" тема, у меня вопрос теоретического плана:
А сама технология VPS сколько накладных расходов несёт ?
Ну скажем берём один E-5 процессор, N оперативной памяти и для чистоты эксперимента отдельный raid контроллер с 4 дисками в raid 10
Теперь добавляем второй такой же E-5 на плату, ставим 2N оперативки, ставим 2-ой raid контроллер 4 дисками в raid 10. Делаем 2 VPS каждому по процессору, по N памяти и по отдельному raid контроллеру с дисками.
На сколько % один VPS второго варианта будет "медленнее" чем первый вариант ?
http://rus-linux.net/MyLDP/sys-conf/memory.html
Cached
Страничный кэш в системе Linux ("Cached:" в meminfo) является в большинстве систем самым крупным потребителем памяти. Каждый раз, когда вы выполняете операцию чтения read () из файла, расположенного на диске, данные считываются в память и помещаются в страничный кэш. После того, как операция read() завершается, ядро может просто выбросить страницу памяти, так как она не используется. Однако, если вы второй раз выполняете операцию чтения той же самой части файла, данные будут считываться непосредственно из памяти и обращения к диску не будет. Это невероятно ускоряет работу и, поэтому, в Linux так интенсивно используется кэширование страниц: ставка делается на то, что если вы обратились к некоторой странице дисковой памяти, то вскоре вы обратитесь к ней снова.
dentry/inode caches
Каждый раз, когда вы в файловой системе выполняете операцию "ls’" (или любую другую операцию: open(), stat() и т.д.), ядру требуются данные, которые находятся на диске. Ядро анализирует эти данные, находящиеся на диске, и помещает его в некоторых структуры данных, независимые от файловой системы, с тем, чтобы они могли в различных файловых системах обрабатываться одним и тем же образом. Таким же самым образом, как кэширование страниц в приведенных выше примерах, ядро может после того, как будет завершена команда "ls", стереть эти структуры. Тем не менее, делается такое же предположение, как и раньше: если вы однажды считали эти данные, вы обязательно прочитаете их еще раз. Ядро хранит эту информацию в нескольких местах "кэша", которые называются кэш памятью dentry и inode. Кэш память dentries являются общей для всех файловых систем, но каждая файловая система имеет свой собственный кэш inodes.
Эта оперативная память является в meminfo составной частью "Slab:"
Вы можете просмотреть различную кэш память и узнать ее размеры с помощью следующей команды:
head -2 /proc/slabinfo; cat /proc/slabinfo | egrep dentry\|inode
Buffer Cache
Кэш буфера ("Buffers:" в meminfo) является близким родственником кэш памяти dentry/inode. Данные dentries и inodes, размещаемые в памяти, представляют собой описание структур на диске, но располагаются они по-разному. Это, возможно, связано с тем, что у нас в копии, расположенной в памяти, используется такая структура, как указатель, но на диске ее нет. Может также случиться, что на диске байты будут располагаться не в том порядке, как это нужно процессору.
https://www.ibm.com/developerworks/ru/library/l-linux-filesystem/index.html
Буферный кэш
За исключением отдельных реализаций файловых систем (которые можно найти в ./linux/fs), в нижней части уровня файловой системы располагается буферный кэш. Здесь хранятся запросы на чтение и запись от отдельных файловых систем и физических устройств (посредством драйверов устройств). Из соображений производительности в Linux предусмотрен кэш запросов, позволяющий не обращаться по каждому запросу к физическому устройству. Вместо этого в нем кэшируются последние использованные буферы (страницы), которые могут быть быстро предоставлены отдельным файловым системам.
Нет, что Вы не nginx а именно ОС (напрмер Centos) - обращения к файловой системе кэшируются в памяти именно самой операционной системой - нет необходимости tmpfs создавать и туда файлы кэша складывать.
Вот смотрите - мой случай - вывод команды free -h:
total used free shared buff/cache available
Mem: 62G 2,3G 51G 446M 9,3G 59G
Swap: 0B 0B 0B
Как видно - 9.3 Gb это и есть кэширование запросов к файловой системе. А тип хранения кэша вэбсервера у меня именно "Файлы" а не мемкэшед.
При одном единственном сервере и большом кол-ве оперативки хранение кэша "Файлы" всяко быстрее и лучше чем мемкешед.
Причем не надо даже монтировать никакой диск в памяти для кэша, ОС сама прекрасно закэширует в оперативке что надо по обращениям к файловой системе.
На сервере если у Вас есть доступ по ssh.
P.S.
В целом после даже маленьких обновлений надо быть готовым к тому что придётся звать либо программиста по Битриксу либо админа либо обоих :)
Cтабильно раз в пару месяцев после обновлений что-то, мелочь какая-то но перестаёт нормально работать - приходится звать Чип и Дейла :)
Зачем ?
Будет только потеря времени на подключении к серверу мемкешеда. Зло - использовать его когда только один сервер, здесь же не идёт речь о кластере мемкешед серверов.
Нет, в тарифе за 300 этого нет, Да и тип записей который поддерживается мизерен. Да и проект по сравнению с dyn пока никому неизвестный.
Зачем нужен балансировщик если и он упасть может ?
Берёте как и хотели 2 сервера в разных ДЦ и репликацию налаживаете.
А затем берёте на dyn.com тариф за 160 долларов месяц, ,будет одновременно хостинг DNS и лоадбаланс - два IP в записи А указали, настроили и затем сервис сам всё отслеживает - упал один сервер - за секунду перенаправление всё на другой пошло :)
Я закрывать не стал но сделал с каждого объявления rel=canonical на сам раздел объявлений.
