Quote from: fxpc on January 27, 2020, 09:43:31 AM

Не совсем верно. Термин масштабирование означает увеличение производительности при добавлении ресурсов (обычно аппаратных, но не всегда).

Да, я просто частный случай упомянул, и то не совсем корректно, увеличение тактовой частоты (т.е. обычный разгон) ведь тоже увеличение мощности железа

Quote from: kzv on January 27, 2020, 09:43:31 AM

Ну тогда сортировка пузырьком тоже масштабируется...

Какой смысл обсуждать масштабирование с ростом частоты, понятно, что тут почти все масштабируется

Да только уже давно частоты CPU уже давно не растут...
Предлагаю вернуться к ядрам CPU, тут сортировка пузырьком никак не масштабируется, но есть работающие алгоритмы параллельной сортировки, в редких случаях бывают полезны.

Quote from: kzv on January 27, 2020, 09:43:31 AM

ЗЫ: я тут на досуге документацию почитал, все таки я спрашивал про многопоточность в нгинкс, а вы переводите стрелки на процессы. Надеюсь вы в курсе, что потоки и процессы это разные вещи?

Это зависит от конкретной ОС, в винде это принципиально разные объекты, потоки одного процесса имеют только свой собственный контекст исполнения (регистры, стек, TLS и все что туда входит), все потоки одного процесса имеют общее адресное пространство, файловые дескрипторы, и.т.д.
В линуксе нет такой четкой границы между потоком и процессом, например 2 таких объекта могут иметь разные идентификаторы (тогда падение одного из них не затронет остальные), но работать в одном адресном пространстве, а может быть наоборот (см. параметры системного вызова clone).
Рабочие процессы в nginx в линуксе имеют отдельные идентификаторы, но предполагаю, что они имеют общее пространство файловых дескрипторов (иначе не очень понимаю, как реализивать опцию reuseport). Теперь по сути, вы называете nginx однопоточным и асинхронным, а апач синхронным многопоточным, реально же их рабочие процессы по сути одни и теже сущности в ОС (пусть будут процессы), только один рабочий процесс nginx обслуживает множество подключений одновременно, а в апаче только одно, и если nginx будет использовать классические потоки (то же самое что threads в винде), с точки зрения производительности не изменится абсолютно ничего, стабильность только пострадает.

Quote from: kzv on January 27, 2020, 09:43:31 AM

По умолчанию поддержка многопоточности выключена (http://nginx.org/ru/docs/http/ngx_http_core_module.html#aio)

Это уже совсем другая настройка, так включается пул потоков для запуска синхронных (блокирющих) операций без блокировки цикла сообщений. В зависимости от типа нагрузки опция может поднять производительность на тысячи процентов, а может и ничего не дать.

Quote from: kzv on January 27, 2020, 09:43:31 AM

Остался еще один шаг: что по вашему делает "мастер процесс"?

Если говорить про сеть, то раньше он висел на приеме входящих соединений, с появлением опции reuseport это тоже переехало в worker-ы, так что теперь мастер просто читает конфиг и управляет worker-ами.

Quote from: kzv on January 27, 2020, 09:43:31 AM

Можно... Если хотите чтобы все встало колом из-за ваших потоков и опросов

Это с каких пор epoll колом встает из-за его вызова из нескольких потоков? Может тесты какие подтверждающие есть?

Это у kqueue такие проблемы есть и там рекомендуют использовать несколько независимых экземпляров для цикла сообщений, а у epoll и виндового iocp всегда все ок с этим было.

Quote from: kzv on January 27, 2020, 09:43:31 AM

Хотите увидеть пример программиста, который решил сделать многопоточное приложение потому что так проще и якобы эффективнее, а в итоге сломал себе весь мозг костылями из нагромождений локфри структур и получил через год то же самое, что другой программист сделал в одном потоке за неделю?
К счастью у меня нет готового примера, хотя... Можно глянуть на разработчиков апача наверное.

А чего обсуждать криворуких программистов, да многопоточность это сложно и требования к квалификации разработчиков намного выше.

---

Что-то перестал понимать что мы тут обсуждаем, поэтому хочу вернуться к мысли, которую хотел донести еще в первом сообщении, многопоточность и асинхронности никак не связаны между собой, первое про количество одновременно исполняемых потоков, второе про архитектуру, и, естесственно, асинхронные приложения более эффективно используют ресурсы. Но ничто не мешает асинхронному приложению быть многопоточным - запускать цикл сообщений одновременно в нескольких потоках, использовать отдельные потоки для тяжелых вычислений, или комбинировать все это, получая прирост производительности.