| Вопрос: Сопряжение программ | Добавлено: 17.06.10 15:21 |
Автор вопроса:  Dark Engine | Web-сайт: www.wentas.2bb.ru | ICQ: 343191665 |
| Ответы | Всего ответов: 27 |
|
Номер ответа: 16 Автор ответа:  EROS Вопросов: 58 Ответов: 4255  |
Профиль | | #16 | Добавлено: 19.06.10 00:30 |
|
А если надо будет перебросить таблицу из БД из одного приложения в другое? Формат придумать можно, но передача будет громоздкой
А как, по твоему, тот же WCF передает данные, включая записи БД? Точно так же.. сериализует объект и гонит его по tcp,http протоколу (в зависимости от биндинга). Кроме того, если возникает необходимость передачи большого объема данных, то это уже полноценное клиент-серверное приложение, а не обмен данными между приложениями в рамках одной машины.. это уже совсем другой подход требуется.. Через хук оконной процедуры таблицы из БД ты тоже не перекинешь... |
||
|
Номер ответа: 17 Автор ответа: Dark Engine ICQ: 343191665 Вопросов: 51 Ответов: 98 |
Web-сайт: Профиль | | #17 | Добавлено: 20.06.10 22:55 |
|
EROS пишет:
это уже полноценное клиент-серверное приложение Хуже. Это комплекс программ, взаимодействующих между собой... и запускаемых на сервере. По сути - лихая реализация многопоточности обработки запросов сервером. EROS пишет:
а не обмен данными между приложениями в рамках одной машины скажем так, машина предполагается одна EROS пишет:
Через хук оконной процедуры таблицы из БД ты тоже не перекинешь Отсюда вывод: TCP. Кстати, еще мне намекнули про DDE. Подойдет для таких целей? |
||
|
Номер ответа: 18 Автор ответа: EROSВопросов: 58 Ответов: 4255 |
Профиль | | #18 | Добавлено: 21.06.10 09:47 |
|
Кстати, еще мне намекнули про DDE. Подойдет для таких целей?
DDE - это достаточно древняя технология.. кроме того,если не ошибаюсь, она требует админских прав.. со всеми вытекающими последствиями.. и еще, на многих машинах эта служба по дефолту отключена.. Это комплекс программ, взаимодействующих между собой... и запускаемых на сервере.
странная реализация.. Почему бы не сделать все в рамках одного приложения, если все они твои? Если делать несколько узкоспециализированных приложений, то будет достаточно много геморроя с синхронизацией между ними.. оно того стоит? Тут надо либо поднимать единый центр синхронизации.. что то типа службы или сервиса.. либо по TCP гонять туда сюда между приложениями.. либо регистрировать в системе свои сообщения и слать щироковещательные пакеты и в других приложениях их ловить и как то реагировать.. Вообщем вариантов туча.. осталось только все это реализовать. В любом случае, задача не из простых.. |
||
|
Номер ответа: 19 Автор ответа: Dark EngineICQ: 343191665 Вопросов: 51 Ответов: 98 |
Web-сайт: Профиль | | #19 | Добавлено: 21.06.10 10:40 |
|
EROS пишет:
Почему бы не сделать все в рамках одного приложения, если все они твои? Тогда вопрос на засыпку, если поступает штук 50 запросов в секунду и одно приложение будет их обрабатывать довольно долго, каков выход? По мне так проще все-таки распределить запросы по типу (в разные базы), на каждую базу - свой "сервер". И "сервера" эти связать между собой. Ну коли DDE устарела, пусть связь будет работать через TCP. EROS пишет:
Тут надо либо поднимать единый центр синхронизации.. Ну где-то так и будет. Набор "серверов", запускаемых опционально и какой-то единый блок, контролирующий работу всех этих "серверов". EROS пишет:
В любом случае, задача не из простых.. Признаю. Собственно, потому и поднял на уши всех знакомых, кто мог бы раздобыть VB6 с MSDN в комплекте. И все равно придется сюда бегать, спрашивать 
|
||
|
Номер ответа: 20 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | | #20 | Добавлено: 21.06.10 11:24 |
|
Вопрос в том на чем пишешь проект? Если на .NET, то однозначно WCF.
Если все компоненты написаны на .NET, то пускаем все через Named Pipes (namedPipesBinding). Если используются разные платформы, то basicHttpBinding, wsHttpBinding. Что касается ущерба производительности, в обоих случаях он будет. В случае с Named Pipes - меньше чем в случае с TCP. Но нужно понимать, что передача данных между приложениями в любом случае будет работать на порядоки медленнее, чем передача данных в рамках одного приложения (к примеру, из одного класса в другой). А еще нужно добавить время на сериализацию/десераиализацию. Dark Engine пишет:
Тогда вопрос на засыпку, если поступает штук 50 запросов в секунду и одно приложение будет их обрабатывать довольно долго, каков выход? Dark Engine пишет:
Тогда вопрос на засыпку, если поступает штук 50 запросов в секунду и одно приложение будет их обрабатывать довольно долго, каков выход? По мне так проще все-таки распределить запросы по типу (в разные базы), на каждую базу - свой "сервер". И "сервера" эти связать между собой. Ну коли DDE устарела, пусть связь будет работать через TCP. Это что-то вроде сервера который принимает запросы от клиентов по TCP? С чего ты взял что 50 разных процесов будут обарабывать 50 запросов быстрее чем один процес? Нет объективных причин для этого. Более того, поскольку в каждом процесе имеются общие компоненты (менеджер памяти, рантайм), общие объекты и т.п., каждый из которых занимает ресурсы процессора и памяти, 50 процесов будут работать медленнее чем один. Также добавь затраты на межпроцессорное взаимодействие (на чем бы ты его не делал, оно тоже даст определенное снижение производительности). Разделение сетевого сервера на несколько разных процесов может дать определенные преимущества. Такие как, например, * Изоляция отдельных компонентов друг от друга Если один из процесов повреждается, начинает вести себя неподконтрольно, то можно уничтожить процес, не затрагивая работу других процесов. * Контроль и ограничение ресурсов, используемых процесом Если все компоненты выполняются в рамках одного процеса, непросто или невозможно отследить, какой из них сколько ресурсов потребляет. А также ограничить их. Когда компоненты разделены по разным процесам, это * снижение времени простоя при сбое приложения. Если приложение дало сбой, то потребуется некоторое время для его перезапуска. В это время сервер будет неспособен обрабатывать запросы, и получается простой. Если же определенный компонент запустить в нескольких приложениях и передавать управление в приложения случайным образом, то можно свести этот простой к минимуму. Если одно из приложений падает, все равно остается несколько таких же рабочих приложений, готовых обрабатывать этот тип запросов. Это в теории, на практике реализовать эти преимущества не так просто. Если ты не знаешь как делаются межпроцессорные коммуникации, маловероятно что ты сможешь качественно реализовать подобную схему. К тому же к мастер-приложению, которое собственно принимает запросы и распределяет их, предъявляются довольно высокие требования по качеству и надежности. Примерную реализацию можешь посмотреть на примере архитектуры IIS (в нем, кстати, мастер-приложение работает в режиме ядра). Впрочем (на мой взгляд), главная причина почему обрабокта запросов выполняется в раздельных процесах, состоит в том, что распространенный сценарий использования этого веб-сервера - это условия shared-хостинга, в котором код любого сайта является потенциально вредоносным и некачественным, поэтому его нужно максимально изолировать от системы и от кода других сайтов. Другой очень хороший пример - это SQL Server, в котором все выполняется в рамках одного процеса, и даже пользовательский код (в managed-сборках) выполняется в процесе SQL Server. Поэтому к коду, который выполняется в SQL Server предъявляются намного более серьезные требования, чем к коду, который выполняется в IIS. В том случае если он начнет вести себя некорректно, это затронет весь процес SQL Server, перезапуск которого (и тем более аварийный сбой) - это уже само по себе ЧП. В отличие от рабочего процеса IIS, которые плодятся пачками и постоянно перезапускаются, что нужно учитывать при разрабокте веб-сайтов. Dark Engine пишет:
По мне так проще все-таки распределить запросы по типу (в разные базы), Если разбивать большую БД на несколько маленьких вертикально (т.е. разные таблицы - в разные базы), это не даст никакого выигрыша в скорости. Если есть разные диски, разнос данных по которым может дать увеличение быстродействия, то таблицы легко разносятся по файловым группам, каждая из которых ложится на свой диск. Разбиение большой БД на несколько маленьких горизонтально (к прмеру, все данные за 2005 год - в одной БД, за 2006 - в другой, за 2007 год - в тертьей, или разбивать по городам, или предприятиям) - это может дать ускорение. Впрочем, такое же же ускорение даст и обычное добавление индекса в таблицу. Если есть возмжоность разнести данные по разным дискам, то горизонтально их можно разнести, используя секционирование, это все в рамках одной таблцы и одной БД. Единственное для чего может понадобиться разделять базу приложения на несколько разных баз данных - если используется бесплатная версия SQL Server и уперлисьв лимит размера БД. Тогда может быть смысл разбить базу на несколько маленьких (возможно, при этом забыв о возможности проверки целостности данных). Впрочем я сомневаюсь что у тебя произошло что-то подобное. А на небольших базах до 100 МБ (примерно) практически невозможно упереться в недостаток производительности (если, конечно, не писать реально кретинические SQL запросы). Если же есть недостаток производительности, то надо проанализировать планы выполнения, оптимизировать запросы, сделать индексы. |
||
|
Номер ответа: 21 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | | #21 | Добавлено: 21.06.10 11:24 |
|
Dark Engine пишет:
Признаю. Собственно, потому и поднял на уши всех знакомых, кто мог бы раздобыть VB6 с MSDN в комплекте. И все равно придется сюда бегать, спрашивать Сетевые приложения, серверы, скорость, надежность, VB6 - знаешь какое из слов здесь лишнее? |
||
|
Номер ответа: 22 Автор ответа: EROSВопросов: 58 Ответов: 4255 |
Профиль | | #22 | Добавлено: 21.06.10 11:56 |
|
Тогда вопрос на засыпку, если поступает штук 50 запросов в секунду и одно приложение будет их обрабатывать довольно долго, каков выход?
Выход - обрабатывать эти запросы асинхронно.. в другом(гих) потоке,чтоб основной поток не висел.. Но учитывая специфику VB6 - сделать это не реально.. Кроме того Artyom тебе верно сказал, получить выигрыш в производительности при таком подходе довольно сложно.. Тут оптимизация одного SQL запроса наверяка даст заметно бОльший прирост производительности нежели все эти танцы с бубнами вокруг межпроцессорного взаимодействия.. к тому же на VB6. Только один этот факт сильно сокращает шансы на успешное завершение проекта.. |
||
|
Номер ответа: 23 Автор ответа: Dark EngineICQ: 343191665 Вопросов: 51 Ответов: 98 |
Web-сайт: Профиль | | #23 | Добавлено: 21.06.10 12:24 |
|
Artyom пишет:
Сетевые приложения, серверы, скорость, надежность, VB6 - знаешь какое из слов здесь лишнее? Старый друг лучше новых двух. NET-платформы вечно конфликтуют между версиями - это раз. Сталкивался уже с такой мерзостью, как подобный конфликт и отказ приложений, написанных на 1.1 под 2 и 3. Нежелательна привязка к NET-платформе - два. Под чем поднимать эти сервера - большого значения иметь не должно. А если писать на NET - будут связанные с этим проблемы. Ну и полная перепись уже набросанного проекта - это три. Тут даже разъяснять нет смысла. |
||
|
Номер ответа: 24 Автор ответа: EROSВопросов: 58 Ответов: 4255 |
Профиль | | #24 | Добавлено: 21.06.10 12:34 |
|
Старый друг лучше новых двух. NET-платформы вечно конфликтуют между версиями - это раз.
Ну после такого мне больше сказать нечего... Удачи! |
||
|
Номер ответа: 25 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | | #25 | Добавлено: 21.06.10 12:56 |
|
Dark Engine пишет:
NET-платформы вечно конфликтуют между версиями - это раз. Во-первых, это не правда. Во-вторых, какой смысл писать новый проект на старой версии .NET когда есть новая версия? Сталкивался уже с такой мерзостью, как подобный конфликт и отказ приложений, написанных на 1.1 под 2 и 3
В 1.1 и 2.0 разные рантаймы. Но 1.1 легко ставится рядом с 2.0, 3.0 и т.п. и там нет никаких конфликтов. Dark Engine пишет:
А если писать на NET - будут связанные с этим проблемы. Если писать на .NET, то проблем никаких не будет. Поскольку в нем все технологии для разрабокти сетевых приложений идут в коробке. Если писать на VB6, то ты столкнешься с проблемами. С одной из них ты, похоже, уже столкнулся - отсутствие возможности асинхронной обработки. Также столкнешься с отсутствием (в коробке) многопоточности, завязанность сетевого компонент на объект-форму, отсутствие в коробке возомжности создавать Windows-службы, отсутствием нормальной обработки ошибок. |
||
|
Номер ответа: 26 Автор ответа: Dark EngineICQ: 343191665 Вопросов: 51 Ответов: 98 |
Web-сайт: Профиль | | #26 | Добавлено: 21.06.10 16:39 |
| Всем спасибо за советы. В принципе - суть уловил. Но отсутствие привязки к NET-платформе - обязательное условие. От него и пляшу. | ||
|
Номер ответа: 27 Автор ответа: SharpЛидер форума ICQ: 216865379 Вопросов: 106 Ответов: 9979 |
Web-сайт: Профиль | | #27 | Добавлено: 21.06.10 18:57 |
| С++ поможет тебе. | ||