производительность доступа к моно-серверу через удаленное взаимодействие - PullRequest
0 голосов
/ 23 сентября 2008

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

Идея состоит в том, чтобы создать веб-страницу, содержащую форму, в которую пользователь вводит те же данные и получает те же результаты, что и выше. Из-за доступных веб-серверов компании, первая идея состояла в том, чтобы создать моно-веб-сервис, но это было отклонено по неизвестным причинам. «Служба» не должна запускаться как веб-служба, но должна вызываться сценарием PHP. В настоящее время это реализуется путем вызова моно-приложения через shell_exec из PHP.

Так что теперь я застрял с монопортом моего приложения, которое работает нормально, но выполняется слишком долго. Я уже удалил все ненужные библиотеки, методы и т. Д., Но вызов приложения через командную строку - отправка нужных данных через параметры командной строки - занимает примерно 700 мс. Мы ожидаем около 10 обращений в секунду, поэтому это может работать только при настройке большого количества серверов для этой задачи.

Я предполагаю, что 700 м связаны со стоимостью запуска приложения каждый раз, потому что это не имеет большого значения с точки зрения времени, если я обработаю запрос только один или пятьсот раз (я беру исходный ввод, меняю его и делать 500 итераций каждый раз с «новыми» данными. Начиная со второй итерации, время обработки уменьшается примерно до 1 мс за итерацию)

Моя следующая идея состояла в том, чтобы настроить моно приложение в качестве удаленного сервера, чтобы его можно было запустить только один раз, а затем обрабатывать входящие запросы. Поэтому я написал еще одно моно приложение, которое служит клиентом. Вызов клиента, разрешение клиенту передавать данные на сервер и получение результата теперь занимает 344 мс. Это лучше, но все же намного медленнее, чем я ожидал и хочу, чтобы это было.

Затем я реализовал новый проект с нуля на основе этого сообщения в блоге и застрял с теми же проблемами с производительностью.

Вопрос в том, упускаю ли я что-то, связанное с монопроектами, которое может улучшить скорость клиент / сервер? Хотя идея создания веб-службы для этой задачи была отклонена, будет ли веб-служба работать лучше в этих условиях (поскольку мне не нужно клиентское приложение для вызова службы), хотя говорят, что удаленное взаимодействие выполняется быстрее, чем веб-службы?


Я мог бы сделать это более понятным, но внедрение веб-сервиса в настоящее время не вариант (и, пожалуйста, не спрашивайте почему, я не написал требования;))

Тем временем я проверил, что это действительно запуск клиента, который занимает большую часть времени в сценарии удаленного взаимодействия.

Я мог бы представить себе доступ к серверу через каналы из командной строки, что было бы идеально в моем сценарии. Я думаю, это будет сделано с помощью сокетов?

Ответы [ 2 ]

3 голосов
/ 24 сентября 2008

Вы можете попытаться использовать AOT, чтобы уменьшить время запуска. В .NET вы использовали бы ngen для этой цели, в моно просто сделайте mono --aot для всех сборок, используемых вашим приложением.

Код AOT медленнее, чем код JIT, но имеет преимущество, заключающееся в сокращении времени запуска.

Вы даже можете попробовать AOT сборки сборки, такие как mscorlib и System.

1 голос
/ 23 сентября 2008

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

Рассматривали ли вы использование веб-сервисов SOAP через HTTP? Это также поможет вам в сценарии «веб-страницы».

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

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