Как уменьшить количество записей в файл при наличии нескольких потоков?

Question

вот ситуация.

В Java Web App меня назначили подать, меня попросили улучшить общее время ответа на стресс-тесты во время QA.Это веб-приложение не использует базу данных, поскольку оно должно быть легким и простым.(И я не могу изменить это решение)

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

Используя Jmeter, я обнаружил, что в данном тестовом примере 2 запроса занимают большую часть времени.Оба эти запроса добавляют или изменяют некоторые объекты конфигурации.Поскольку доступ к файлу должен быть синхронизирован, когда многие пользователи изменяют конфигурацию, файл должен быть полностью записан несколько раз в течение нескольких секунд, и запросы ожидают, чтобы произошла запись файла.

Я думалчто все эти сериализации вообще не нужны, поскольку мы переписываем большинство объектов снова и снова, изменения в каждом запросе относятся к одному отдельному объекту, но каждый раз файл записывается целиком.

Итак, есть ли способ уменьшить количество реальных записей файлов, но при этом гарантировать, что все изменения в конечном итоге сериализуются?

Любые предложения приветствуются

Answer 1

Один из вариантов - внести изменения в память и сохранить один поток в фоновом режиме, запускать его с заданными интервалами и сбрасывать изменения на диск. Помните, что в случае сбоя вы потеряете данные, которые не были сброшены.

Фоновый поток можно запланировать с помощью ScheduledExecutorService .

ИМО, было бы лучше использовать БД. Разве вы не можете использовать встроенную БД, такую ​​как Java DB , H2 или HSQLDB ? Эти базы данных поддерживают одновременный доступ, а также могут гарантировать согласованность данных в случае сбоя.

Answer 2

Один из способов - сделать то, что делает Lucene, и вообще не перезаписывать старый файл, а написать новый файл, содержащий только «обновления».Это зависит от того, что ваши обновления являются ассоциативными, но в любом случае это обычно так.

Идея состоит в том, что если ваш старый файл содержит "8" и у вас есть 3 обновления, вы пишете "3" в новый файл, иновое состояние "11", затем вы пишете "-2", и теперь у вас есть "9".Периодически вы можете агрегировать старые и обновления.Любой физический файл, который вы пишете, никогда не обновляется, но может быть удален после того, как он больше не используется.

Чтобы сделать эту идею более актуальной, рассмотрите, являются ли приведенные выше числа записями какого-либо рода.«3» может переводиться как «Добавить три новые записи», а «-2» - «Удалить эти две записи».

Lucene является примером проекта, который очень успешно использует этот стиль стратегии аддитивного обновления.

Answer 3

Если вы абсолютно не можете использовать базу данных, очевидным решением будет разбить ваш отдельный файл на несколько файлов, по одному файлу для каждого из объектов конфигурации. Это ускорит сериализацию и процесс вывода, а также уменьшит конфликты блокировок (запросы, которые изменяют различные объекты конфигурации, могут записывать свои файлы одновременно, хотя это может стать IO-привязанным).