Я знаю, что мантра состоит в том, что база данных всегда представляет собой длинный столб в палатке каждый раз, когда страница создается на стороне сервера.
Но на веб-сервере также происходит немало файлового ввода-вывода. Скриптовый код изобилует операторами include / require. Более того, обычно шаблонный HTML-код хранится вне приложения в файлах, которые загружаются и заполняются соответствующим образом.
Какую роль играет ввод-вывод файлов, когда речь идет о веб-разработке? Становится ли это когда-нибудь проблемой? Когда это слишком много? Кэшируют ли что-нибудь веб-серверы / языки?
В вашем опыте это когда-нибудь действительно имело значение?





Я бы сказал, что скорость ввода-вывода файлов становится проблемой только в том случае, если вы обслуживаете тонны статического контента. Когда вы обрабатываете данные и выполняете код для рендеринга страниц, время на чтение самой страницы с диска незначительно. Файловый ввод-вывод важен в тех случаях, когда статические файлы, которые вы обслуживаете, не могут поместиться в памяти, например, когда вы обслуживаете файлы видео или изображений. Это также может произойти с файлами html, но поскольку размер файлов html настолько мал, это менее вероятно.
10 лет назад диски были настолько быстрее процессоров, что вам не нужно было так об этом беспокоиться. У вас иссякнет ЦП (или вы переполните свою сетевую карту), прежде чем диск станет проблемой. В настоящее время центральные процессоры и гигабитные сетевые карты могут сделать диск узким местом, НО ....
Большую часть использования диска, не связанного с базой данных, так легко распараллелить. Если вы не разработали архитектуру хостинга для горизонтального масштабирования за счет добавления дополнительных систем, это более важно, чем точная настройка доступа к диску.
Если вы разработали горизонтальное масштабирование, обычно дешевле просто покупать больше серверов, чем пытаться выяснить, как оптимизировать диск. Не говоря уже о том, что такие вещи, как SSD или даже RAM-диски для ваших шаблонов, сделают это без проблем.
Очень редко бывает обслуживающая архитектура, масштабируемая по горизонтали, достаточно популярная, чтобы вызвать проблемы с масштабируемостью, но недостаточно прибыльная, чтобы позволить себе разместить еще один 1U в стойке.
Файловый ввод-вывод станет фактором (для статического содержимого и статической страницы) только в том случае, если ваша пропускная способность для внешнего мира аналогична пропускной способности вашего диска. Это будет означать, что либо у вас действительно быстрое соединение, либо вы обслуживаете контент в быстрой локальной сети, либо у вас очень медленные диски (или у вас много конфликтов за диск). Так что, скорее всего, ответ отрицательный.
Конечно, это предполагает, что вы не загружаете большой файл только для небольшой части файла.
Файловый ввод-вывод является одним из многих факторов, включая пропускную способность, сетевое подключение, память и т. д., Которые могут повлиять на производительность веб-приложения. Самый эффективный способ определить, вызывает ли файловый ввод-вывод какие-либо проблемы, - запустить профилирование на сервере и посмотреть, является ли это ограничивающим фактором для вашей производительности.
Во многом это будет зависеть от того, какие типы файлов вы загружаете с диска, многие маленькие файлы будут иметь очень разные свойства по сравнению с несколькими большими файлами. Веб-серверы могут кэшировать файлы как внутри памяти, так и могут указывать клиенту, что файл (например, изображение) может быть кэширован и поэтому его не нужно запрашивать каждый раз.
Не оптимизируйте преждевременно. Это зло или что-то в этом роде.
Однако ввод-вывод - это самое медленное, что вы можете делать на компьютере. Постарайтесь свести его к минимуму, но не позволяйте Кнуту видеть, что вы делаете.
Большинство современных серверов могут перегружать свои сетевые адаптеры до того, как диск станет проблемой, если вы обслуживаете большие файлы. Доступ к диску станет узким местом только в том случае, если вы обслуживаете много очень маленьких файлов.