История изменений
Исправление foror, (текущая версия) :
Что мешает их в очередь, например, отправить?
Причем тут очередь? Если у тебя в тредпуле ограничение на 4 треда, то эти треды будут простаивать ожидая ответа от SSD при синхронном IO. Но процессор в это время простоя мог бы выполнить следующие транзакции, чтобы послать новые запросы на SSD. Но в твоей схеме этого не сделать, тем самым не загрузить SSD на полную мощность.
В SSD задержка на чтение рандомного блока положим 0.1мс - это время простаивания треда. Тогда в секунду у тебя будет 40 000 iops на 4 треда.
А мог бы выжать 1 000 000 iops, если бы не простаивал, а разрешил следующим транзакциям занять простаивающие треды и отправить следующие запросы на SSD. Да, в этом случае задержка подросла бы до 0.6мс, но в сумме всё равно получил бы где-то 1 000 000, а не 40 000 iops.
вот тут вроде бы есть вариант и для IO
Зачем мне очередной хипстерский фреймворк? В джаве есть API для работы с асинхронным IO. Вот еще файберы на подвозе. Будем по итогу тестить и смотреть, стоит менять асинхронные колбеки на последовательный «синхронный» код в файберах или цена удобства слишком высока.
Исправление foror, :
Что мешает их в очередь, например, отправить?
Причем тут очередь? Если у тебя в тредпуле ограничение на 4 треда, то эти треды будут простаивать ожидая ответа от SSD при синхронном IO. Но процессор в это время простоя мог бы выполнить следующие транзакции, чтобы послать новые запросы на SSD. Но в твоей схеме этого не сделать, тем самым не загрузить SSD на полную мощность.
В SSD задержка на чтение рандомного блока положим 0.1мс - это время простаивания треда. Тогда в секунду у тебя будет 40 000 iops на 4 треда.
А мог бы выжать 1 000 000 iops, если бы не простаивал, а разрешил следующим транзакциям занять простаивающие треды и отправить следующие запросы на SSD. Да, в этом случае задержка подросла бы до 0.6мс, но в сумме всё равно получил бы где-то 1 000 000, а не 40 000 iops.
вот тут вроде бы есть вариант и для IO
Зачем мне очередной хипстерский фреймворк? В джаве есть API для работы с асинхронным IO. Вот еще файберы на подвозе. Будем по итогу тестить и смотреть, стоить менять асинхронные колбеки на последовательный «синхронный» код в файберах или цена удобства слишком высока.
Исходная версия foror, :
Что мешает их в очередь, например, отправить?
Причем тут очередь? Если у тебя в тредпуле ограничение на 4 треда, то эти треды будут простаивать ожидая ответа от SSD при синхронном IO. Но процессор в это время простоя мог бы выполнить следующие транзакции, чтобы послать новые запросы на SSD. Но в твоей схеме этого не сделать, тем самым не загрузить SSD на полную мощность.
В SSD задержка на чтение рандомного блока положим 0.1мс - это время простаивания треда. Тогда в секунду у тебя будет 40 000 iops на 4 треда.
А мог бы выжать 1 000 000 iops, если бы не простаивал, а разрешил следующим транзакциям занять простаивающие треды и отправить следующие запросы на SSD. Да, в этом случае задержка подросла бы до 0.6мс, но в сумме всё равно получил бы где-то 1 000 000, а не 40 000 iops.
вот тут вроде бы есть вариант и для IO
Зачем мне очередной хипстерский фреймворк? В джаве есть API для работы с асинхронным IO. Вот еще файберы на подвозе. Будем по итогу тестить и смотреть, стоить менять асинхронные колбеки на последовательный код в файберах или цена удобства слишком высока.