Будет ли интерфейс REST замедлять мою поисковую систему? - PullRequest
1 голос
/ 25 января 2010

Чтобы быстро создать поисковый веб-сайт, я планирую разделить работу между двумя командами: одна для создания поисковой системы и одна для создания веб-интерфейсов (мобильных / настольных). Мой план состоит в том, чтобы создать поисковую систему как набор служб REST на основе .NET 3.5. Интерфейсы могут быть построены с использованием другой технологии.

Вопросы: может ли интерфейс REST стать узким местом для производительности? Как лучше этого избежать?

Ответы [ 3 ]

1 голос
/ 25 января 2010

REST не является узким местом в этом сценарии. Из вашего поста не было ясно, выполняли ли вы вызовы REST напрямую из своего HTML-интерфейса на клиенте, или вы выполняли вызовы REST между серверами на серверной части. Итак, я расскажу оба случая ниже.

Если ваши REST-вызовы выполняются между вашим клиентским пользовательским интерфейсом и вашими серверами, то использование REST или другого HTTP-метода удаленного взаимодействия не имеет большого значения - время, необходимое для выполнения поиска на серверной части и последующей отправки результатов обратно вниз клиент должен уменьшить влияние самого вызова REST. Если вы хотите улучшить производительность, сфокусируйтесь на уловках на стороне клиента (например, сжатие HTTP, правильные заголовки кэширования и т. Д.) И оптимизации самой поисковой системы.

Если ваша архитектура представляет собой один уровень серверов (на котором размещается ваш веб-интерфейс), вызывающий другой уровень (ваш механизм поиска), то вызов между этими уровнями через REST также не должен слишком сильно увеличивать общую задержку. Это связано с тем, что (как и выше) выполнение поиска и отправка результатов обратно клиенту обычно занимает не менее нескольких сотен миллисекунд, а накладные расходы на внутренний вызов REST (если все сделано правильно) обычно составляют 50 мс или меньше. ,

Тем не менее, легко запутать клиентскую часть HTTP-вызовов от сервера к серверу. Например, многие клиентские библиотеки HTTP (включая .NET) по умолчанию ограничивают количество одновременных клиентских подключений, что имеет смысл, если вы создаете реальное клиентское приложение, но убивает вашу масштабируемость, если используется от «клиента», который на самом деле сервер, обслуживающий сотни пользователей одновременно. Другие потенциальные проблемы включают в себя проблемы с аутентификацией, проблемы с прокси, DNS и т. Д. Поэтому будьте осторожны, чтобы тщательно собрать и настроить свой клиентский код REST, и обязательно проведите нагрузочное тестирование с несколькими сотнями одновременно работающих пользователей!

0 голосов
/ 25 января 2010

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

Не забудьте прочитать эту ссылку http://www.ytechie.com/2008/10/aspnet-mvc-what-about-seo.html

0 голосов
/ 25 января 2010

Нет. ОТДЫХ не является (и вообще не может быть) узким местом. REST - это HTTP без красивой HTML-страницы. Это дешевле и быстрее, чем обычная веб-страница.

...