|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Dima TИМХО в пределах одной машины можно по UDP слать. При такой маленькой нагрузке потерь не должно быть. Поизучай ZeroMQ - это легковесная очередь сообщений с различными стратегиями рассылки сообщений. В форуме по дельфям ее подробно обсуждали . Спасибо, поизучаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2018, 12:41 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thДолжно обрабатываться КАЖДОЕ сообщение. Никакой очереди быть не может. Э-э-э... Поясни: какая связь между этими утверждениями? 13thКаждое сообщение должно обрабатываться В СВОЮ ОЧЕРЕДЬ. Ну так каждое сообщение и ждёт в очереди пока не будет обработано. Из середины очереди никто не исчезнет, вне очереди никто не пролезет. 13thТы должен доставить котировку в несколько модулей. Один модуль считает стратегию. Второй - баланс. Третий - отчёт. Поэтому никакого распараллеливания отправки тоже быть не может. Тебе говорят про распараллеливание обработки. Или у тебя отчёт должен подождать подсчёта баланса и стратегии? Тогда нужны последовательные очереди. И, кстати, ничего из сказанного не объясняет зачем у тебя отправляющий поток ждёт окончания обработки перед посылкой следующего сообщения. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2018, 12:51 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thБлижайшая аналогия: поток котировок. Ты должен доставить котировку в несколько модулей. Один модуль считает стратегию. Второй - баланс. Третий - отчёт. Поток котировок, естественно, идёт из одного потока. Задержка в 1..1,5ms терпима. В таком случае тебе больше подходит Actor Model ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2018, 13:38 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
OoCcВ таком случае тебе больше подходит Actor Model Акторы - это очереди, сообщения и обработчики сообщений. Плюс идеология по организации архитектуры приложения. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2018, 13:56 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Dima TOoCcВ таком случае тебе больше подходит Actor Model Акторы - это очереди, сообщения и обработчики сообщений. Плюс идеология по организации архитектуры приложения. Всё правильно. Всё это хозяйство можно поместить в один процесс. В терминах 13th модуль - это актор. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2018, 14:05 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thБлижайшая аналогия: поток котировок. Ты должен доставить котировку в несколько модулей. Один модуль считает стратегию. Второй - баланс. Третий - отчёт. Поток котировок, естественно, идёт из одного потока. Задержка в 1..1,5ms терпима. Но пересылать группами по 100 штук - уже без варика. Так же нельзя менять порядок котировок - по понятным причинам. Должно обрабатываться КАЖДОЕ сообщение. Никакой очереди быть не может. Если бы можно было бы группировать, я бы всё отправил один раз в секунду, и это заняло бы 10ms. Каждое сообщение должно обрабатываться В СВОЮ ОЧЕРЕДЬ. Поэтому никакого распараллеливания отправки тоже быть не может. Клиенты и так работают параллельно. Из того что ты описал можно сделать следующее предположение. Есть три модуля которые обрабатывают сообщения строго последовательно и синхронно. Видимо нужно для бизнеса. Как RPC. И никой механизм IPC не нужен. Ну по крайней мере нет мотивации к его использованию. Поэтому можно выбросить все эти усложнения и сделать просто 1 модуль (процесс) который обрабатывает стратегию, баланс и отчет. За кадром остаётся вопрос как приходит котировка. Возможно здесь можно подумать об асинхронизме и потоках но наверное там уже стоит сетевой протокол который это обеспечивает или нечто в этом роде. Если есть какие-то другие мотивации к разделению на процессы (хот деплой?) то пожалуйста озвучь. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2018, 18:18 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thДолжно обрабатываться КАЖДОЕ сообщение. Никакой очереди быть не может. Ну вот ниже без очереди отправка и ожидание ответа между двумя процессами через разделяемую память. Тут под линукс, но в винде аналогично, просто вместо mmap() по другому разделяемая память создается. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83.
На простеньком Intel Core i3 дает 90000 сообщ/сек. 13thМожешь кусок кода показать? Лень искать. Но поверьте, если код выше, написанный за 5 минут на коленке, дает 90К/с то асинхронная обработка очереди даст на порядки большую скорость. Кстати у вас там в вашем примере с двумя Event неэффективно используется синхронизация. Event Винды внутри это по сути mutex + condition var. Получается в вашем коде два мьютекса, тогда как для передачи сообщения и возврата результата нужен только один мьютекс (и две условных переменных). Может поэтому тормозит. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.04.2018, 18:22 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Anatoly Moskovsky, 10к/c на винде будет прямая зависимость от скорости переключения задач планировщиком процессов ... |
|||
:
Нравится:
Не нравится:
|
|||
01.04.2018, 21:26 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
kealon(Ruslan)10к/c на винде будет прямая зависимость от скорости переключения задач планировщиком процессов Вообще, если процессы разнесены по разным процессорам, то планировщик ничего особо и не переключает в этом случае. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.04.2018, 21:54 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Anatoly Moskovsky, запусти просто под виндой да проверь, у меня Win10 i7 4710HQ - больше 10к/с не выжимает под Linux будет быстрее, как раз из-за более быстрого переключения по поводу: >>Вообще, если процессы разнесены по разным процессорам, то планировщик ничего особо и не переключает в этом случае. подсчитай какова вероятность что два процесса будут работать одновременно, т.е. долю от общего времени ... |
|||
:
Нравится:
Не нравится:
|
|||
01.04.2018, 22:38 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
kealon(Ruslan)запусти просто под виндой да проверь, у меня Win10 i7 4710HQ - больше 10к/с не выжимает Нету винды, не на чем проверить )) kealon(Ruslan)по поводу: >>Вообще, если процессы разнесены по разным процессорам, то планировщик ничего особо и не переключает в этом случае. подсчитай какова вероятность что два процесса будут работать одновременно, т.е. долю от общего времени Ну вот у меня вышеприведенные два процесса при запуске занимают каждый по 70% от одного ядра. Каковы шансы что они выполняются на одном ядре? )) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.04.2018, 23:22 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Типичный шаблон для Unix-pipeline. Под Windows может быть не так быстро. Ну по крайней мере я-бы проверил. Реализация достаточно дешевая и не сложная. Не нужна реализация очереди. Код: plaintext 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 00:53 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
mayton, у ТС классический RPC, надо тупо ждать ответа от другого процесса: синхронно, много-много раз. Если он модель вызова на асинхронку не поменяет, ИМХО ловить особо нечего как костылёк можно увеличить частоту системного таймера , это ускорит его текущую реализацию без всяких доп-ужимок ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 07:26 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Собака зарыта в его бизнес требования. Надо их читать. И зачем там COM. Я бы пересмотрел архитектуру. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 09:19 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
maytonЕсли есть какие-то другие мотивации к разделению на процессы (хот деплой?) то пожалуйста озвучь. Проблем две: 1. первая проблема в том, что поставщик данных - один. Я не могу в каждый процесс добавить по поставщику, т.к. сервер поддерживает только одно соединение; 2. потребитель данных - приложение, подбирающееся к лимиту USER и GDI объектов. Поэтому часть данных открывается в одном процессе, часть - в другом, часть - в третьем. До 5-7 бывает. Разнесения источника данных и клиентов по разным процессам никак не избежать. Переписать UI на WPF - это годы, никто в это вкладываться не будет. Тем более, решив одну проблему, это может принести других. Все узкие места позатыкали, сейчас на очереди - межпроцессные коммуникации. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 12:31 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
maytonСобака зарыта в его бизнес требования. Надо их читать. И зачем там COM. Я бы пересмотрел архитектуру. Хороший совет. Если твой продукт - MS Paint. У меня чуток побольше. Эдак, на пару порядков. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 12:33 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
kealon(Ruslan)mayton, у ТС классический RPC, надо тупо ждать ответа от другого процесса: синхронно, много-много раз. Если он модель вызова на асинхронку не поменяет, ИМХО ловить особо нечего как костылёк можно увеличить частоту системного таймера , это ускорит его текущую реализацию без всяких доп-ужимок Нет, синхрон в примере, что бы пользоваться общей памятью. В продукте, конечно, COM-вызовы все асинхронные. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 12:48 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thНет, синхрон в примере, что бы пользоваться общей памятью. В продукте, конечно, COM-вызовы все асинхронные.блин ..., если у тебя асинхронные то что моск уже вторую страницу морочишь с синхронизацией? оценки нужно получить что именно тормозит. потом маршалинг попытаться на свой заменить для узких мест, в сети вроде примеры были как это делается - IMarshal ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 13:38 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13th, Если предел близок по user/gdi - переписать под opengl ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 14:14 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
kealon(Ruslan)13thНет, синхрон в примере, что бы пользоваться общей памятью. В продукте, конечно, COM-вызовы все асинхронные.блин ..., если у тебя асинхронные то что моск уже вторую страницу морочишь с синхронизацией? синхронизация нужна в пределах одного обработчика, что бы не нарушился порядок обработки. Но когда производительности не хватает, задержка нарастает, и в некоторых модулях достигает одного часа. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 14:52 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13th, 500*3600 сообщений в очереди ждут? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 16:03 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
Изопропил, да. Но это уже когда проблема не в передаче, а в обработке. Приёмник имеет два потока: один принимает и складывает в очередь на обработку. Второй поток берёт из очереди и обсчитывает. Иногда бывает такой тяжёлый обсчёт, что в очереди скапливается сообщения за час. Да, 500 * 3600. Тут ничего поделать нельзя. Но профилировка показывает, что при некоторых кейсах передача сообщений занимает до 20% процессорного времени. Если, сменив технологию передачи, я снижу этот процент до 5% - будет великолепно. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 16:10 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thИзопропил, да. Но это уже когда проблема не в передаче, а в обработке. Приёмник имеет два потока: один принимает и складывает в очередь на обработку. Второй поток берёт из очереди и обсчитывает. Иногда бывает такой тяжёлый обсчёт, что в очереди скапливается сообщения за час. Да, 500 * 3600. Тут ничего поделать нельзя. Но профилировка показывает, что при некоторых кейсах передача сообщений занимает до 20% процессорного времени. Если, сменив технологию передачи, я снижу этот процент до 5% - будет великолепно. давай по порядку 1. вызываешь метод который ложит в очередь, синхронно? 2. ожидание отработки задачи как реализовано? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 16:24 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
kealon(Ruslan), COM-объект, Singleton. Клиенты, создают сервер-синглетон, подписываются на события (Advise). Ждут данные. Приходят данные в сервер. Он их рассылает подписчикам. Подписчики обходятся синхронно (используется connection_point_container). Подписчик, получив данные, кладёт в FIFO очередь. Другой поток подписчика выбирает данные из очереди и обрабатывает. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 17:21 |
|
Межпроцессное взаимодействие - что быстрее?
|
|||
---|---|---|---|
#18+
13thkealon(Ruslan), COM-объект, Singleton. Клиенты, создают сервер-синглетон, подписываются на события (Advise). Ждут данные. Приходят данные в сервер. Он их рассылает подписчикам. Подписчики обходятся синхронно (используется connection_point_container). Подписчик, получив данные, кладёт в FIFO очередь. Другой поток подписчика выбирает данные из очереди и обрабатывает. т.е. выходит следующее: >>Подписчики обходятся синхронно (используется connection_point_container) минимум ожидание двух переключений контекста на каждого клиента: Сервер->Подписчик->Сервер >> Подписчик, получив данные, кладёт в FIFO очередь. я так понимаю ещё миинимум 2 переключения на каждого подписчика если с серверного объекта читается: Подписчик->Сервер->Подписчик 4N переключений на одну порцию данных, много конечно... на сервере ложишь пришедшие данные в расшаренный буфер - на 2N сократит количество переключений при получении данных от сервера если поменяешь модель уведомлений на "оповестить всех сразу", то ещё в N раз ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 20:07 |
|
|
start [/forum/topic.php?fid=57&msg=39623700&tid=2017690]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
33ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 143ms |
0 / 0 |