Кэширование

@Leemurchonok · Регистрация: 16.10.2010

Студворк — интернет-сервис помощи студентам

Стало скучно и решил старый проект поднять на новый протокол. Это весь крутой чат, в котором присутствуют персонажи, объекты, их питомцы и так далее. Почти все данные лежат а сервере и подлежат скачиванию для постоянного использования. Назвал я сие чудо кэш, так как там хранится разного рода информация(растры, скрипты, конфиги). Предварительный объем 1,8Гб 22 тыс. файлов.

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

Простите, если не в тот раздел пишу, но ума не приложу в какой раздел будет верным вопрос.

Убежденный · 14.09.2017, 15:27

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

Так что перед тем, как такое делать, надо сначала забабахать прототип и решить,
стоит оно того или нет. А если и стоит, то перед написанием своего велосипеда поискать
уже существующие решения. Например, может оказаться, что какая-нибудь SQLite умеет
держать данные в памяти и делает это весьма эффективно.

Кроме этого, нужно еще решить проблему сохранности данных (и когерентности кэша).
Например, что если сервер вдруг упадет в Blue Screen / Kernel Panic и данные из
памяти потеряются?

Ну это все так, мысли вслух...

@Leemurchonok · 18.09.2017, 09:47 **[ТС]**

Сообщение от Убежденный

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

Ну меня интересовала скорость и вот то, что Вы ответили.
Значит лишняя работа это все. Спасибо за советы.

Новые блоги и статьи Все статьи Все блоги /
PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Access VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .
Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .

@Leemurchonok 23 / 23 / 6 Регистрация: 16.10.2010 Сообщений: 211

	Кэширование 14.09.2017, 14:11. Показов 2680. Ответов 2 Метки кеширование, клиент (Все метки) Стало скучно и решил старый проект поднять на новый протокол. Это весь крутой чат, в котором присутствуют персонажи, объекты, их питомцы и так далее. Почти все данные лежат а сервере и подлежат скачиванию для постоянного использования. Назвал я сие чудо кэш, так как там хранится разного рода информация(растры, скрипты, конфиги). Предварительный объем 1,8Гб 22 тыс. файлов. Суть вопроса заключается в целесообразности создания кэша одним файлом? При условии, что самые горячие данные всегда будут висеть в оперативной памяти, тяжелые(растр) будут в кэше, но при этом точно программа будет знать, есть ли эти данные, а не проверять на винчестере существование(тут ясно выигрыш), и точное положение этих данных в этом файле кэша(время на поиск уничтожаем). Держать файл кэша открытым за все время работы программы или при необходимости открывать дабы минимизировать повреждение кэша? Простите, если не в тот раздел пишу, но ума не приложу в какой раздел будет верным вопрос. 0

Убежденный Ушел с форума 16481 / 7444 / 1187 Регистрация: 02.05.2013 Сообщений: 11,616 Записей в блоге: 1
	14.09.2017, 15:27
	Часто используемые файлы и так лежат в кэше файловой системы. И обращение к ним - это только накладные расходы на "формальные" вызовы функций открытия, чтения и закрытия файлов, фактически там делается простое копирование блоков из одного места в другое. Так что перед тем, как такое делать, надо сначала забабахать прототип и решить, стоит оно того или нет. А если и стоит, то перед написанием своего велосипеда поискать уже существующие решения. Например, может оказаться, что какая-нибудь SQLite умеет держать данные в памяти и делает это весьма эффективно. Кроме этого, нужно еще решить проблему сохранности данных (и когерентности кэша). Например, что если сервер вдруг упадет в Blue Screen / Kernel Panic и данные из памяти потеряются? Ну это все так, мысли вслух... 1