You are here: Foswiki>Gnumed Web>PerformanceDesignRu (10 Feb 2013, IvanLykov)EditAttach

Проектирование производительности

Некоторые исходные потоки и посты на

частичный итог потоков:

Общие показатели

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

Обзор

  • Некоторая оптимизация нам известна: кэширование бизнес-объектов (мы уже делаем это в клинической записи), предварительная загрузка списка ожидания
  • В идеале, коммуникация всех БД должна осуществляться в фоновом потоке, так что пользователь может начать ввод записей и т.д. во время загрузки материала. Вот что мы имеем для асинхронной коммуникации бэкэнда.
    1. комплекс/время запроса инициируется асинхронно на сервере, см. здесь
    2. при готовности сервер уведомляет клиента, что он может теперь предоставить данные
    3. в идеале в бэкэнде мы будем иметь службу xml-rpc или похожую, которая подготавливает все данные на сервере строго так, как нужно клиенту, и затем поставляет их.

Стратегии PostgreSQL

  • эмуляция неблокирующих записей и выбор сокета, используя потоки так же, как мы уже надстроили API БД с gmPG.py
  • объектные запросы статического значения в выборке массива по одному
  • для случаев, подобных get_lab_results(), которые могут возвращать произвольно большие списки результатов, связать их каким-либо образом на указатель и НЕ делать fetchall() on it, , а лучше использовать fetchmany() et al
    Gnumed жестко связан кодом на run_ro_query(), из-за того, что в большинстве случаев мы делаем fetchall()
    • мы не можем много делать с указателем Declare и закрыть указатель, как это делается через модуль DB-API
  • надлежащая индексация/перезапись медленных запросов
  • надлежащая настройка базы данных
  • вместо нескольких простых запросов более сложный одинарный запрос или (особенно за пределами localhost) несколько большие denormalizing представления sql для сокращения времени отклика анализатора запросов и усечения сетевого трафика
  • помогут ли подключения на "запись" для объединения?
    • в настоящее время gnumed устанавливает отдельное TCP-подключение для каждой фиксированной транзакции (они завершаются на уровне подключения глупое ограничение библиотек бэкэнда). Подключение не допускает отдельные параллельные транзакции, и после завершения транзакции объединение подключений для записи потребует упорядоченной формальной разблокировки подключения. Может быть, мы должны по-другому взглянуть на передачу SQL.

Служба XML-RPC

  • преимущества:
    • независимые платформа и интерфейс языка к бэкэнду
    • средства реализации бизнес-логики на стороне сервера
    • для нашего клиента Python это также означает две меньшие сторонние зависимости (pypgsql и mxDateTime)
  • предостережения:
    • медленный протокол с большими издержками
    • требует достаточно хорошего расчета для приемлемой производительности у конечного пользователя

    • Зависит от степени структурированности данных
Topic revision: 10 Feb 2013, IvanLykov
 
Download.png
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark