ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Нужен совет. Частота запросов к базе. Производительность
25 сообщений из 49, страница 1 из 2
  1  все
Нужен совет. Частота запросов к базе. Производительность
    #39288209
fankhm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fankhm
Гость
День добрый.

Нужен совет, информация.
Делаю проект, в котором необходимо максимально обеспечить актуальность отображаемых данных во времени. Серверная часть - ФБ 2.5 SuperClassic
- создаётся заказ на стороне клиента. пишется в базу (статус "создано")
- у операторов с частотой (желательно раз в секунду) обновляется список созданных заказов
- оператор принимает заказ, по мере обработки меняет статусы ("принято", "в работе", "готово"). Промежуток между "принято" и "готово" - около 5 минут.
- статусы аналогично актуально отображаются клиенту
- забирает заказ - статус "выполено"

Думаю сделать общую таблицу заказов и плюс к ней - вспомогательную таблицу только актуальных заказов - в ней будут только статусы "создано", "принято", "в работе", "готово"

как ведёт себя ФБ при такой частоте запросов ?

PS: в начале рабочей сессии будет запускаться принудительный сборщик мусора.
...
Рейтинг: 0 / 0
08.08.2016, 12:17
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288221
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
fankhmНужен совет
Делай трёхзвенку или отдельный сервер рассылки изменений по push-технологии. Прикручивать
pull при таких условиях - бесперспективняк.

Рассматривай свою задачу как online-MMORPG.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
08.08.2016, 12:27
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288230
fankhm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fankhm
Гость
Dimitry Sibiryakov,

т.е. не потянет частые запросы ?
клиентских мест - до 5-ти (т.е. 5 возможных одновременных заказа)
операторских - до 10-ти
это в будущем, вначале 1 клиентское и 2 операторских.
...
Рейтинг: 0 / 0
08.08.2016, 12:35
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288235
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
fankhmт.е. не потянет частые запросы ?
Потянет, но это совершенно криво и бессмысленно.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
08.08.2016, 12:44
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288364
Andrey_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey_
Гость
fankhmDimitry Sibiryakov,

т.е. не потянет частые запросы ?
клиентских мест - до 5-ти (т.е. 5 возможных одновременных заказа)
операторских - до 10-ти
это в будущем, вначале 1 клиентское и 2 операторских.Потянет, даже если к твоим исходным данным нолик дописать, хотя конечно это будет увлекательный танец по граблям. Но, как сказал Dimitry Sibiryakov, "сервер рассылки изменений по push-технологии" будет гораздо изящнее.
...
Рейтинг: 0 / 0
08.08.2016, 15:13
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288569
fankhm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fankhm
Гость
Andrey_fankhmDimitry Sibiryakov,

т.е. не потянет частые запросы ?
клиентских мест - до 5-ти (т.е. 5 возможных одновременных заказа)
операторских - до 10-ти
это в будущем, вначале 1 клиентское и 2 операторских.Потянет, даже если к твоим исходным данным нолик дописать, хотя конечно это будет увлекательный танец по граблям. Но, как сказал Dimitry Sibiryakov, "сервер рассылки изменений по push-технологии" будет гораздо изящнее.

почитал про "технология Push".

Технология Push — один из способов распространения информации (контента),
когда данные поступают от поставщика к пользователю на основе установленных
параметров. Пользователь же в свою очередь либо отвергает, либо принимает данные.

Противоположностью Push-технологии является технология Pull, где запрос инициирует
клиентское программное обеспечение.

не понял как её реализовать в моём случае ?
на каких принципах и какими инструментами ?

надо поднимать сервер - чего ? (POP3, SMTP, IRC, NetSend)
синхронизировать его с работой клиентов и операторов.
ещё одно звено - минус в надёжности, я так думаю...

если можно - объясните про "сервер рассылки изменений по push-технологии" - принцип работы и инструментарий. везде только описание конечного результата "всплывающие информационные плашки", а как информация туда попала ?
...
Рейтинг: 0 / 0
08.08.2016, 20:27
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288570
fankhm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fankhm
Гость
Andrey_,

про "будет увлекательный танец по граблям" тоже не очень понятно. если работает чётко по транзакциям, в чём может быть проблема ?

я вижу только проблему в сборе "мусора" и обновлении статистики индексов, но это обычное, знакомое и предсказуемое.
...
Рейтинг: 0 / 0
08.08.2016, 20:30
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288572
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
fankhmа как информация туда попала ?
С сервера. Любым подходящим способом. Обычно - через TCP.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
08.08.2016, 20:36
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288573
fankhm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fankhm
Гость
хотя конечно можно сделать этот push просто на сокетах... когда-то чат делал на ICS компонентах

или есть что-то уже стандартизированное и обкатанное ?
...
Рейтинг: 0 / 0
08.08.2016, 20:38
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288584
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Раз чат делал, значит он у тебя уже обкатан. Кого волнуют стандарты?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
08.08.2016, 21:08
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288595
afgm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
afgm
Участник
fankhmне понял как её реализовать в моём случае ?
на каких принципах и какими инструментами ?
Посмотри Redis Pub/Sub
...
Рейтинг: 0 / 0
08.08.2016, 22:20
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288605
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
fankhm,

такси, что-ли? если да, то на ФБ их полно. И обсуждение кое-каких аспектов было тут несколько лет назад.

fankhmв начале рабочей сессии будет запускаться принудительный сборщик мусора.
такая фраза настораживает, потому что версии обычно накапливаются из-за длинных транзакций (не read read committed), а в этом случае "сборщики мусора" бесполезны.
Нужно будет смотреть на результат многопользовательской работы такой системы, и уже ПОТОМ либо чинить длинные транзакции, либо ... не беспокоиться о мусоре.
...
Рейтинг: 0 / 0
08.08.2016, 23:11
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288633
fankhm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fankhm
Гость
kdvfankhm,

такси, что-ли? если да, то на ФБ их полно. И обсуждение кое-каких аспектов было тут несколько лет назад.

fankhmв начале рабочей сессии будет запускаться принудительный сборщик мусора.
такая фраза настораживает, потому что версии обычно накапливаются из-за длинных транзакций (не read read committed), а в этом случае "сборщики мусора" бесполезны.
Нужно будет смотреть на результат многопользовательской работы такой системы, и уже ПОТОМ либо чинить длинные транзакции, либо ... не беспокоиться о мусоре.

нет. не такси. что-то вроде фастфуда

версии будут накапливаться из-за большого числа вставок/удалений в одной таблице, см. первый пост - "Думаю сделать общую таблицу заказов и плюс к ней - вспомогательную таблицу только актуальных заказов - в ней будут только статусы "создано", "принято", "в работе", "готово".
Заказы. Статусы. Из этого формируется очередь. Вот "живую очередь" думаю вывести/продублировать в отдельную таблицу для скорости запроса. Но из-за того, что там будет постоянно вставка/удаление - будут накапливаться версии. Которые периодически будут "собираться". Где-то так.
...
Рейтинг: 0 / 0
09.08.2016, 02:03
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288678
Фотография Хнык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хнык
Участник
fankhmнет. не такси. что-то вроде фастфуда

версии будут накапливаться из-за большого числа вставок/удалений в одной таблице, см. первый пост - "Думаю сделать общую таблицу заказов и плюс к ней - вспомогательную таблицу только актуальных заказов - в ней будут только статусы "создано", "принято", "в работе", "готово".
Заказы. Статусы. Из этого формируется очередь. Вот "живую очередь" думаю вывести/продублировать в отдельную таблицу для скорости запроса. Но из-за того, что там будет постоянно вставка/удаление - будут накапливаться версии. Которые периодически будут "собираться". Где-то так.
Вам таблица не нужна. Сделайте сервис и храните актуальные заказы в памяти. При подъеме сервиса считывайте актуальную заказы и оповещайте этот сервис об их изменении.
...
Рейтинг: 0 / 0
09.08.2016, 08:30
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288691
MikeDD
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MikeDD
Участник
fankhmнет. не такси. что-то вроде фастфуда

Думается вам нужно пересмотреть постановку ТЗ. Вы имеете дело не с бездушными железками, которые беспрерывно хреначат данные, а с людьми. Какой смысл опрашивать очередь раз в секунду если как я понимаю заказ клиент получит не раньше чем через 5 минут? Кроме того поступившие заказы обрабатывают тоже люди. Они же не просто тупо меняют статус заказа с "принято" на "в работе" а еще чего-то делают? А это значит что следующий поступивший заказ все равно не будет обработан до тех пор пока оператор не разделается с предыдущим.
...
Рейтинг: 0 / 0
09.08.2016, 09:10
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288695
Фотография Хнык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хнык
Участник
MikeDDfankhmнет. не такси. что-то вроде фастфуда

Думается вам нужно пересмотреть постановку ТЗ. Вы имеете дело не с бездушными железками, которые беспрерывно хреначат данные, а с людьми. Какой смысл опрашивать очередь раз в секунду если как я понимаю заказ клиент получит не раньше чем через 5 минут? Кроме того поступившие заказы обрабатывают тоже люди. Они же не просто тупо меняют статус заказа с "принято" на "в работе" а еще чего-то делают? А это значит что следующий поступивший заказ все равно не будет обработан до тех пор пока оператор не разделается с предыдущим.
Видимо количеством заказов небольшое. И основное время занимает не заполнение заказов, а простой менеджера до следующего заказа.
...
Рейтинг: 0 / 0
09.08.2016, 09:18
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288697
MikeDD
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MikeDD
Участник
Хнык, время выполнения заказа больше в десятки раз. Какой смысл ловить блох в ПО если 99% времени ожидания заказа клиентом приходится на кухню?
...
Рейтинг: 0 / 0
09.08.2016, 09:23
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288705
Фотография Хнык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хнык
Участник
MikeDDХнык, время выполнения заказа больше в десятки раз. Какой смысл ловить блох в ПО если 99% времени ожидания заказа клиентом приходится на кухню?
Возможно, заказчик одним из плюсов автоматизации видит уменьшение простоя менеджеров. Если цикл заказа пять минут, то простой в две минуты может быть довольно ощутимым.
...
Рейтинг: 0 / 0
09.08.2016, 09:35
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288711
MikeDD
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MikeDD
Участник
Хнык, но ТС ведь гоняется за секундами! На мой взгляд на общее время выполнения заказа существенно не увеличится если период опроса очереди будет не 1 секунда а к примеру 5.
...
Рейтинг: 0 / 0
09.08.2016, 09:47
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288715
Фотография Хнык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хнык
Участник
MikeDDХнык, но ТС ведь гоняется за секундами! На мой взгляд на общее время выполнения заказа существенно не увеличится если период опроса очереди будет не 1 секунда а к примеру 5.
Что секунда, что пять, какая разница на таком количество операторов? Зато нет видимой задержки между попаданием заказа в очередь и оповещением менеджера. Заказчик будет доволен осознавая, что приложение не тратить ни одной лишней секунды его денег.
...
Рейтинг: 0 / 0
09.08.2016, 09:53
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288721
MikeDD
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MikeDD
Участник
Хнык, кстати а сколько заказов поступает в минуту? Ведь на то, чтобы заказать еду пусть и в фастфуде тоже уходит время. Я сильно сомневаюсь что количество заказов будет измеряться сотнями в минуту. На деле в лучшем случае их будут десятки в минуту. Тогда спрашивается нафига городить всю эту реалтайм фигню если с этим легко справится post_event?
Я к чему все это - требования к ПО должны идти не с потолка а строго из предметной области. Ну и делать с запасом раза в 2-3 на случай роста бизнеса. Все остальное - пустая трата времени.
...
Рейтинг: 0 / 0
09.08.2016, 10:03
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288740
Фотография Хнык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хнык
Участник
MikeDDХнык, кстати а сколько заказов поступает в минуту? Ведь на то, чтобы заказать еду пусть и в фастфуде тоже уходит время. Я сильно сомневаюсь что количество заказов будет измеряться сотнями в минуту.
Скорее всего, есть пики, когда ваш подход оправдан, т.е. количество заказов столько, что с ними не справляются и оперативное обновление очереди никому не интересно (если честно, странно обновлять для оператора очередь, если он оформляет заказ). В остальных случаях, если операторы успевают разбирать очередь и количество заказов в день, скажем, 500, лишние 5 секунд превращаются в 2500 секунд во время которых оператор ничего не делает, а только напряжённо всматривается в экран, к примеру.
...
Рейтинг: 0 / 0
09.08.2016, 10:24
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288781
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Хныклишние 5 секунд превращаются в 2500 секунд во время которых оператор ничего не делает, а
только напряжённо всматривается в экран, к примеру.

Как давно Вы последний раз вглядывались в экран своего сотового, ожидая когда кто-нибудь
выйдет на связь? Звонок к телефону прикрутили ещё два века назад. Закипающий чайник
оснастили свистком и то гораздо позже.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
09.08.2016, 11:28
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288783
Фотография Хнык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хнык
Участник
Dimitry SibiryakovХныклишние 5 секунд превращаются в 2500 секунд во время которых оператор ничего не делает, а
только напряжённо всматривается в экран, к примеру.

Как давно Вы последний раз вглядывались в экран своего сотового, ожидая когда кто-нибудь
выйдет на связь? Звонок к телефону прикрутили ещё два века назад. Закипающий чайник
оснастили свистком и то гораздо позже.

Я думаю, если вам в качестве мелодии телефона поставить вашу любимую музыку и звонить по 100 раз в день, вы довольно скоро перейдёте на беззвучный режим и только иногда будете читать смс-ки о пропущенных звонках.
...
Рейтинг: 0 / 0
09.08.2016, 11:32
| Ответить | Цитировать | Написать  
Нужен совет. Частота запросов к базе. Производительность
    #39288798
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Хныки только иногда будете читать смс-ки о пропущенных звонках.
дык. Собственно, задача "магазина с экраном о заказах в онлайне", такси, фастфуда, обменников, и прочего, решается двумя способами, про которые тут уже сказали
1. Pull. Клиент дергает сервер с определенным интервалом (раз в 1-5 секунд) - "нет-ли чего нового?". И если есть, верещит об этом пользователю программы.
Проблемы начинаются когда таких клиентов 5, 10 и больше. То есть, начинается конкуренция за ресурс, даже по чтению. И для Firebird это выливается в большое количество read locks (страниц) и соответственно высокий mutex wait в выводе fb_lock_print.
Система тормозит, при этом толком нихрена не делая.
(один из типичных примеров - "календарь событий" в организациях. Утром толпы сотрудников запускают приложение, которое им всем открывает календарь (одну и ту же таблицу), и ...).

2. Push. Когда сам сервер сообщает клиенту о некоем событии. ФБ имеет механизм post_event. Однако, вероятно, лучше сделать трехзвенку, которая сама будет "более умно" сообщать клиентам о происходящих событиях (как минимум, в post_event нет масок событий, регистрируются только конкретные события по имени).

Дальше, в примере со звонками, уже проблема частоты push. Например, на мобиле gmail синхронизируется с сервером через заданные интервалы времени. Яндекс-почта наоборот, уведомляет о каждом новом письме, что невероятно раздражает.
Та же фигня с уведомлениями соц-сетей. Якобы фэйсбуковое приложение (да и OK) лепит отдельные уведомления на каждый случай, что тоже невероятно раздражает. Другие умудряются как-то группировать уведомления. Но это уже вопрос важности событий для получателя. Понятно, что "группировка" ни для такси, ни для фастфуда не подойдет.
...
Рейтинг: 0 / 0
09.08.2016, 11:58
| Ответить | Цитировать | Написать  
25 сообщений из 49, страница 1 из 2
  1  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Нужен совет. Частота запросов к базе. Производительность
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=39288705&tid=1562022]:
 0ms
get settings:
 10ms
get forum list:
 16ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 54ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 53ms
get tp. blocked users:
 2ms
others: 16ms
total:  171ms
созд. / загр.: 171ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]