У нас есть база данных значений ключей GDBM в качестве бэкэнда для веб-приложения с балансировкой нагрузки, которое реализовано в C ++. Данные, обслуживаемые приложением, стали очень большими, поэтому наши администраторы переместили файлы GDBM из «локального» хранилища (на веб-серверах или очень близко) к большой общей удаленной файловой системе, смонтированной в NFS.
Это повлияло на производительность. Наши тесты производительности (в тестовой среде) показывают, что время загрузки страницы изменяется от сотен миллисекунд (для локального диска) до нескольких секунд (по NFS, локальной сети), а иногда достигает 30 секунд. Я полагаю, что большая часть проблемы заключается в том, что приложение делает много случайных чтений из файлов GDBM, и что они медленнее по сравнению с NFS, и это будет еще хуже в производственной среде (где интерфейсные и серверные части имеют даже больше сетевого оборудования между ними), а наша база данных становится еще больше.
Хотя это не критичное приложение, я хотел бы повысить производительность и предоставить некоторые ресурсы, включая время разработки приложений и администраторов Unix. Моим главным ограничением является то, что у времени есть ресурсы только на несколько недель.
На мой взгляд, у меня есть следующие варианты:
Улучшение производительности NFS путем настройки параметров. Мой инстинкт состоит в том, что мы не получим много пользы от этого, но раньше я ошибался, и я не очень много знаю о настройке NFS.
Перейти к другой базе данных значений ключей, например memcachedb или Tokyo Cabinet .
Замените NFS другим протоколом (iSCSI упоминался, но я не знаком с ним).
Как мне подойти к этой проблеме?