АБ
Size: a a a
2021 July 03
𝕄
при обновлении биоса ноуты не горят, это не сложная задача
АБ
Я узнал про обнову спустя неделю, биос сам обновился из центра обновлений:)
Y
Коммунистическая партия Китая одобряет
Y
Почему Вы по выводу консоли подумали, что она синхронная?
Y
Что значит "не работает с изображениями"?
Если Вы оборачиваете HTML чем-то на каждом запросе, это уже не статика.
А что мешает записать в stream сначала head, потом контент файла, а потом footer? Зачем сначала вычитывать все из stream в память и передавать в новый stream, если можно сделать pipe?
Если Вы оборачиваете HTML чем-то на каждом запросе, это уже не статика.
А что мешает записать в stream сначала head, потом контент файла, а потом footer? Зачем сначала вычитывать все из stream в память и передавать в новый stream, если можно сделать pipe?
AS
HTML контента оборачивается общим для всех страниц header и footer, не более того, я думал, что это небольшая оптимизация такая
А на счёт последовательного прочтения - каким образом вы предлагаете это делать?
У меня же несколько ReadStream'ов, как я могу запайпить их друг на дружку?
А на счёт последовательного прочтения - каким образом вы предлагаете это делать?
У меня же несколько ReadStream'ов, как я могу запайпить их друг на дружку?
Y
А в чем оптимизация? Меньше места на диске занимать?
Пайпайте их в write stream по очереди
Пайпайте их в write stream по очереди
AS
Типа такого?
[headPath, contentPath, footerPath]
.map(filePath => fs.createReadStream(filePath))
.forEach(stream => stream.pipe(res, { end: false }));
res.end();AS
Оптимизация в том, чтобы банально читать меньший объем файла
Забыл сказать - я же кеширую прочитанный head и footer
Просто в мапу их складываю, и достаю их оттуда по необходимости
Забыл сказать - я же кеширую прочитанный head и footer
Просто в мапу их складываю, и достаю их оттуда по необходимости
Y
Вроде того.
Y
Судя по коду Вы их читаете каждый раз с диска.
Как мне кажется, отдать один файл стримом быстрее, чем целиком читать его в память на каждый запрос и склеивать.
Плюс, тогда Вы можете кешировать файлы целиком, что будет еще быстрее.
Как мне кажется, отдать один файл стримом быстрее, чем целиком читать его в память на каждый запрос и склеивать.
Плюс, тогда Вы можете кешировать файлы целиком, что будет еще быстрее.
Y
Мне кажется, что оптимизация сомнительная.
Вы делали benchmarks до и после оптимизации?
Вы делали benchmarks до и после оптимизации?
AS
Нет, конечно, это же чисто учебный проект
Y
А, тогда понятно
Я уже начал писать о том, что статику нужно ложить на CDN)
Я уже начал писать о том, что статику нужно ложить на CDN)
AS
Вариант с кешом каждого файла рассматривал, думал, что будет слишком много оперативки есть
А чтение файла стримом - это свобода по объему файла и не очень долго, потому как файлы большими быть не могут по определению (проект чисто учебный опять же)
А чтение файла стримом - это свобода по объему файла и не очень долго, потому как файлы большими быть не могут по определению (проект чисто учебный опять же)
AS
Ага, это я и так знаю)
Спасибо за помощь
Спасибо за помощь
Y
При большом количестве запросов опреративки может быть занято еще больше, так как Вы будете читать один и тот же файл целиком в память столько раз, сколько запросов придет. Со стримом такой проблемы не будет.
Второй момент. Не нужно ложить все файлы в память (если их мало, то можно, конечно же). Почитайте про LRU и LFU cache
Второй момент. Не нужно ложить все файлы в память (если их мало, то можно, конечно же). Почитайте про LRU и LFU cache
Y
Не за что)
AS
Почитаю, спасибо