Достаточно ли быстр AWS EFS для выполнения кода PHP?

Мне интересно, достаточно ли быстр EFS на AWS для хранения PHP и выполнения PHP-кода? Или время, необходимое для доступа к файлам в сети при поступлении HTTP-запроса, делает это плохим решением?


person Nick Lang    schedule 20.09.2017    source источник
comment
У меня нет никаких показателей, но я предполагаю, что доступ к EFS всегда будет быстрее, чем рендеринг PHP веб-сервера + время отправки веб-клиенту.   -  person Nick.McDermaid    schedule 20.09.2017
comment
Это всегда зависит от ваших требований, но использование EFS всегда должно быть оправдано для общей инфраструктуры. Многие популярные PHP CMS прекрасно работают (по моему опыту) под EFS, но, конечно, EBS работает быстрее.   -  person siomes    schedule 20.09.2017


Ответы (2)


Все зависит от вашего варианта использования. Это медленнее, чем EBS или эфемерное хранилище? Да. Это слишком медленно для вашего варианта использования? Сложно сказать.

При использовании EFS вы привязаны к доступности сетевого ввода-вывода в общей инфраструктуре, на которой работает ваша виртуальная машина EC2.

person BryceH    schedule 20.09.2017
comment
Емкость сетевой инфраструктуры в AWS не превышена. Вы не конкурируете ни с кем, кроме себя, за пропускную способность сети. Более важным фактором является тот факт, что EFS масштабирует свою емкость вместе с общим хранилищем. Маленькие файловые системы EFS намного медленнее, чем большие, по своей конструкции. Каждый сохраненный 1 ГиБ приводит к пополнению корзины токенов ввода-вывода со скоростью 50 КиБ/с, и этот аспект дизайна службы часто упускается из виду. Вы можете сделать это быстрее, только увеличив общий объем хранимых данных. - person Michael - sqlbot; 20.09.2017
comment
Вау, интересно, я точно этого не знал. Вы не можете просто платить больше за большую скорость? - person Nick Lang; 22.09.2017
comment
Ты можешь сейчас! aws.amazon.com /блоги/aws/ - person Tim Malone; 08.09.2018

Да, это достаточно быстро, но зачем заморачиваться? EBS работает быстрее, и сам код PHP не должен меняться, пока отдельный экземпляр работает в продакшене. Обычно вы запускаете экземпляр EC2 и развертываете код в хранилище EBS.

Использование EFS для хранения кода вашего приложения было бы ненужным ярлыком ci/cd.

person Samuel Neff    schedule 20.09.2017
comment
Спасибо Самуэль. Причина в том, что я работаю над созданием масштабируемой системы с помощью Docker. Я хочу, чтобы одни и те же данные были доступны во всех контейнерах, поэтому я подумал, что EFS будет естественным выбором. Я использую режим роя, поэтому использование томов и EBS кажется очень сложным в настройке. Есть такие плагины, как rexray, но я не уверен, готовы ли они к производству. Что ты думаешь? - person Nick Lang; 22.09.2017
comment
@NickLang обычно в рамках процесса сборки вы упаковываете свой код в образ докера, а затем можете развернуть его в любом контейнере докера, и ваш код и все зависимости уже содержатся. В своем комментарии вы сказали данные, но php-код не является данными. Если вам нужны общие данные, то EFS — это вариант, но часто есть и лучшие варианты. ElasticCache, база данных, NoSQL, очереди сообщений... - person Samuel Neff; 22.09.2017
comment
правильно, за исключением этого приложения, php-код находится в пользовательском пространстве. это пользователи, которые загружают произвольный код, поэтому я не могу упаковать их код в изображение. однако я упаковываю phpfpm в изображение, которое выполняет код. но образ phpfpm имеет смонтированный том в /mnt, который исходит из тома EFS. вроде не так уж и необычно. я знаю, что использование EBS было бы лучше, но я использую режим роя, поэтому это означает, что всем новым репликам потребуются ОДИНАКОВЫЕ тома на разных узлах. эти тома могут быть большими, поэтому я не был уверен, что их копирование при необходимости целесообразно. - person Nick Lang; 25.09.2017
comment
@NickLang интересно, ситуация кажется очень необычной, поэтому, возможно, альтернативное решение, такое как EFS, будет хорошим выбором в вашем конкретном случае использования. - person Samuel Neff; 25.09.2017