none
Оптимизация автодополнение RRS feed

  • Вопрос

  • (asp.net mvc3,   entity fw)

    Возникла потребность существующей системы автодополнение. На данный момент она функционирует след. образом:

    Получение от пользователя маски(3 буквы) -> Запрос к сервису с маской -> Получение результата и его кеширование.

    Предлагаемые варианты оптимизации:

    1. Предварительное заполнение таблицы данными типа - searchTerm(маска) и jsonresult (выборка). Соответственно, к сервису не обращаемся, берем результаты из этой таблицы.

    1.1 Теперь надо определить, искать в базе результат по маске, либо выгрузить всю таблицу в Hashtable, например, и искать уже в нем.

    какой вариант оптимальнее?

    Может быть есть еще более оптимальные варианты?


    • Изменено matyual 28 сентября 2012 г. 9:00
    28 сентября 2012 г. 8:51

Ответы

  • Да Пользователь -> Контроллер -> Сервис -> БД -> Возврат результата от сервиса контроллеру -> Генерирование json и возврат пользователю.

    Идея оптимизации в том, чтобы все возможные результаты сервиса предварительно занести в таблицу вида запрос (searchTerm, 3 буквы) и jsonresult (результаты выполнения этого запроса)


    • Изменено matyual 28 сентября 2012 г. 10:40
    • Помечено в качестве ответа Abolmasov Dmitry 3 октября 2012 г. 6:55
    28 сентября 2012 г. 10:39

Все ответы

  • Тут очень много если и масса факторов. Пока, что определённо ответить невозможно. Давайте по порядку. Чем не устраивает первый вариант, почему нужно оптимизировать? Т.е. Вы нашли узкие места, знаете где точно, что тормозит и хотите поменять? Если нашли и знаете то пожалуйста более подробно. В целом понятно, но всё зависит от конкретной ситуации, и каждый из подходов может работать как лучше так и наоборот.
    28 сентября 2012 г. 9:10
    Модератор
  • Лично я узкие места не искал, но, очевидно, нынешняя модель не устраивает скоростью работы, хотят чтоб было быстрее.
    28 сентября 2012 г. 9:15
  • Ну как известно все заказчики хотят быстрей, это всегда так. Но и как обычно бывает проблема может быть не всегда в вашем коде или проекте, а от других факторов, например ресурсов сервера на котором работает приложение. Может сервера перегружены, или сеть, приложению мало ресурсов выделено, или сервер БД находится на "краю света". Надо попытаться найти узкие места, а потом уже пытаться поправить их. Не зная, может Вы и модифицируете приложение, а потом окажется что оно будет работать хуже, причина была в совершенно другом. Одним словом нужно знать причину, хотя бы примерно, что бы менять что-то иначе лучше не трогать.
    28 сентября 2012 г. 9:22
    Модератор
  • Все это понятно. Я о том, что до меня уже руководство потрогало и решило сделать иначе, предложив мне вариант без сервиса с таблицей.

    Решения на уровне  "ничего не делать, искать узкие места, возможно будет хуже" я не принимаю. Мне поставили задачу - я делаю и не жужжу)


    • Изменено matyual 28 сентября 2012 г. 9:28
    28 сентября 2012 г. 9:27
  • Что сказать, Вам видней. Т.е. раньше у Вас контроллер запрашивал сервис, тот в свою очередь БД, возвращал результаты назад, а контроллер обратно? Или запрос шёл напрямую к сервису? " "1. Предварительное заполнение таблицы данными типа - searchTerm(маска) и jsonresult (выборка). Соответственно, к сервису не обращаемся, берем результаты из этой таблицы." -  а отсюда подробней, я же не Вы, не знаю как там у Вас всё устроено.

    28 сентября 2012 г. 9:38
    Модератор
  • Да Пользователь -> Контроллер -> Сервис -> БД -> Возврат результата от сервиса контроллеру -> Генерирование json и возврат пользователю.

    Идея оптимизации в том, чтобы все возможные результаты сервиса предварительно занести в таблицу вида запрос (searchTerm, 3 буквы) и jsonresult (результаты выполнения этого запроса)


    • Изменено matyual 28 сентября 2012 г. 10:40
    • Помечено в качестве ответа Abolmasov Dmitry 3 октября 2012 г. 6:55
    28 сентября 2012 г. 10:39
  • Первое, если возможно делайте запрос напрямую к БД, через контроллер, т.е. в обход сервиса, так будет быстрей, ну если это возможно в вашем случае. Сделайте контроллер максимально простым, без данных сессии и прочего. Второе: используйте ADO.NET и хранимые процедуры, тут важна скорость, а EF на это звание не слишком лучший кандидат. Ну и конечно заготовка данных во временную таблицу и быстрая выборка тоже улучшат производительность. Правда тут один тонкий момент назревает, на сколько большой будет таблица, ведь этих сочетаний может оказаться слишком много. Вообщем теоретически всё это должно повысить производительность, если правильно всё реализовать.
    28 сентября 2012 г. 18:57
    Модератор
  • От EF вряд ли удастся отказаться, придется оптимизировать то, что он сгенерирует. 

    Тонкий момент уже проверен, таких вариантов не так уж и много 33 буквы русского алфавита в комбинации по 3 дает 33*33*33=35937. Сгенерировав все возможные комбинации проверил на сколько из них ответ сервиса содержит результат. Оказалось, таких вариантов не более 2500. Столько записей в таблице и есть. 

    29 сентября 2012 г. 10:08
  • "От EF вряд ли удастся отказаться, придется оптимизировать то, что он сгенерирует. " - никто не говорил отказываться. Просто реализуйте только функию автодополнения без EF, хранимая процедура + вызов через SqlCommand. Ну если там у Вас только русские буквы, то дело намного облегчается. А 35000 записей это немного. Получается очень легковесный вариант, если таблица не будет состоять из множетсва комбинаций запрос + результат.  Я думал у Вас поиск будет искать текст в больших кусках через регулярное выражение.
    29 сентября 2012 г. 10:51
    Модератор