Re: Функционал и интерфейс
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.
Reply to: