Hello! > > Предложенная вами архитектура не годится. Хотя бы потому, что 1 > > "слушающий" процесс всегда будет "узким местом". > > Не будет. Его задача состоит только в том чтобы делать read() на сокет > клиенты и write() на сокет процесса выполняющего вычисления, потом > обратно, и так по кругу для всех клиентов. Нагрузка около нуля.
Еще есть ненулевое время на открытие сокета, обработку заголовков запроса, ожидание свободного процесса из пула процессов для вычислений и проч. > > Далее, операции чтения с диска могут > > выполняться параллельно многими процессами (есть кэш диска плюс кэш > > операционной системы). И для записи даже для SATA-диска размер очереди > > команд, равный 1, далеко не оптимум, а для SAS дисков тем более. > > Вопрос конечно спорный. Скажу только, что если не принимать во внимание > кэш ФС то в один момент времени один винт может обрабатывать равно один > запрос, поэтому чтение одним процессом может быть производительнее, > особенно если его очередь постарается сделать чтение более > последовательным. Совершенно неверно. Для SATA дисков, если не ошибаюсь, эффективная очередь равно примерно 4, а для SCSI и вовсе около 20. Контроллер диска может переставлять команды в очереди так, чтобы требовалось минимальное кол-во перемещений головки. Для SSD дисков и вовсе параллельное чтение заложено в архитектуре. > Насчёт кэша. Как вариант можно делать несколько процессов на диск, или > кэшировать прям в процессе. > > Хотя стой, не надо плодить процессы и встраивать кэш. В любом случае > один процесс читающий последовательно будет не медленее чем два > параллельно. Кэш ФС тут помощник как в первом случае так и во втором. В пределах оптимальной очереди команд для диска и при помощи кэша ФС каждый из параллельных процессов чтения будет работать не медленнее, чем если бы он был единственный. То есть запуск N процессов чтения увеличит производительность в N раз при оптимальной нагрузке (линейно). Понятно, что при возрастании нагрузки линейной зависимости уже не будет. > > Не говоря уже о бессмысленности создания "бутылочного горла" > > между читающими и вычисляющими процессами. > > Не знаю, на сколько это узкое горло, но если перейти от сокетов/пайпов к > общей памяти или от процессов к нитям с общей памятью, этот вопрос точно > отпадёт. Ерунда. Что вы будете держать в общей памяти - кэш всего жесткого диска? Данные обрабатываемого запроса в других процессах/потоках никому просто не нужны. А с диском/сетью/БД лучше работать пулам процессов, как уже рассмотрено выше. А насчет общей памяти - от этого решения уже и многие СУБД отказываются. В результате использования shared memory тот же оракл масштабируется намного хуже терадата. PostgreSQL так же использует shared memory, что приводит к различным проблемам. Я уж не говорю про сложность такого решения. > Я не пытаюсь угадать, я пытаюсь размышлять. Размышления строятся на основе фактов, а не на догадках. Best regards.