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