Должен ли я использовать файлы с отображением памяти для моего простого потока?

Меня интересует реализация следующего простого потока:
Клиент отправляет серверному процессу простое сообщение, которое сервер сохраняет. Поскольку сообщение не имеет какой-либо иерархической структуры, IMO, лучший подход - сохранить его в файле, а не в rdb.
Но я хочу выяснить, как это оптимизировать, поскольку, как я вижу, есть 2 варианта:

  1. Сервер отправляет клиенту 200 OK и затем сохраняет сообщение, чтобы клиент не заметил задержки
  2. Сервер сохраняет сообщение и затем отправляет 200OK, но затем клиент замечает накладные расходы на файловый ввод-вывод.

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


person Cratylus    schedule 08.09.2013    source источник
comment
Файловый ввод-вывод выполняется довольно быстро, поскольку данные кэшируются в ОЗУ дискового кэша. Я не буду беспокоиться перед измерением; и решение 1 небезопасно!   -  person Basile Starynkevitch    schedule 08.09.2013
comment
@BasileStarynkevitch: Если ввод-вывод такой быстрый, то почему у нас есть опция отображения памяти?   -  person Cratylus    schedule 08.09.2013
comment
mmap может быть полезен для большого количества операций ввода-вывода, но вам нужно провести сравнительный анализ, если он полезен (иногда mmap может замедлять работу). А в вашем случае узким местом может быть и сеть...   -  person Basile Starynkevitch    schedule 08.09.2013
comment
@BasileStarynkevitch: Зачем мне здесь проводить бенчмаркинг? Мне кажется очевидным, что доступ к HD изначально медленный. Если только мы не используем SSD, чего я не делаю.   -  person Cratylus    schedule 08.09.2013
comment
Потому что файловый ввод-вывод не должен выполнять фактический дисковый ввод-вывод, если данные остаются в кеше. См. linuxatemyram.com и т. д.   -  person Basile Starynkevitch    schedule 08.09.2013
comment
@BasileStarynkevitch: я не отметил linux в OP. Но на самом деле linux - моя главная цель.   -  person Cratylus    schedule 08.09.2013
comment
Если вы отправляете клиенту «ОК» до того, как все в порядке, вы, по сути, лжете клиенту. Клиент не заинтересован в более быстром получении неправильного ответа.   -  person user207421    schedule 09.09.2013
comment
@EJP: Да, вы правы. Но кажется, что nio не так быстрее, чем обычный файловый ввод-вывод. Поэтому я не уверен, какой дизайн мне предпочесть.   -  person Cratylus    schedule 09.09.2013


Ответы (1)


Сервер сохраняет сообщение, а затем отправляет 200OK, но затем клиент замечает накладные расходы на файловый ввод-вывод.

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

Поэтому я подумал, могу ли я использовать nio и файлы с отображением памяти.

Я использую отображение памяти, поскольку оно может сократить накладные расходы на запись до 5 микросекунд. Это важно для вас? Если нет, я бы придерживался самого простого подхода.

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

Если ОС не падает, то да.

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

Открытие и закрытие файлов, вероятно, будет быстрее и дороже, чем запись данных. (на порядок) Я бы предложил свести такие операции к минимуму.

Вы можете найти эту мою библиотеку интересной. https://github.com/peter-lawrey/Java-Chronicle позволяет сохраняйте сообщения в порядке одной цифры микросекунд для текста и доли микросекунды для небольшого двоичного сообщения.

person Peter Lawrey    schedule 08.09.2013
comment
Я никогда не говорил, что клиент будет человеком. Клиентом будут клиентские приложения. - person Cratylus; 08.09.2013
comment
Я обязательно проверю вашу библиотеку. Это описание persisted, messaging and event driven in memory database кажется противоречивым. Оно хранится в памяти или постоянно? - person Cratylus; 08.09.2013
comment
I use memory mapping as it can reduce the overhead per write by up to 5 micro-second. Выгода только на 5 мс быстрее или общие накладные расходы составляют 5 мс? - person Cratylus; 08.09.2013
comment
@Cratylus 5 микросекунд — это 0,005 мс. ;) Пользы обычно гораздо меньше. Ближе к 2 микросекундам или 0,002 мс. - person Peter Lawrey; 08.09.2013
comment
@Cratylus Он находится в памяти И сохраняется, т. Е. Он имеет производительность в памяти, но также сохраняется ОС. - person Peter Lawrey; 08.09.2013
comment
@Cratylus Клиентские приложения должны иметь очень точные таймеры, то есть лучше миллисекунды, чтобы заметить разницу. Это обычное дело в высокочастотной торговле, но в других приложениях обычно не имеет значения. - person Peter Lawrey; 08.09.2013
comment
Я не понимаю. Сопоставление памяти с файлом всего на 5 мс быстрее, чем обычный ввод-вывод? - person Cratylus; 08.09.2013