Подобряване на производителността при масивно вмъкване на IndexedDB

Опитваме се да кешираме предварително голямо количество данни при зареждане на нашето уеб приложение в индексирана база данни. От моите тестове за производителност скоростта е прилична в настолен браузър (напр. Internet Explorer), където мога да вмъкна 10 000 записа за около 2 секунди. Но сравнявайки абсолютно същата функционалност на iPad, тя пада до 30 секунди. Това сравнение направо ми взриви ума.

Някой знае ли за някакви съвети или трикове за вмъкване на големи набори от данни в indexedDB. Не знам дали изобщо е възможно, но ако можем да изградим копие на страна на индексиран DB сървър с всички предварително попълнени данни и след това просто да го изпратим на клиента и той просто да го съхрани в браузъра. Възможно ли е нещо в тази насока?

Благодаря


ios javascript ipad performance indexeddb
person Matt    schedule 25.03.2015    source източник
comment
погледнете този въпрос stackoverflow.com/questions/ 25914265/   -  person Deni Spasovski    schedule 30.03.2015
comment
Не съм сигурен, че променя нещо, но ако сте тествали Chrome на настолен компютър, тогава разликата може да се дължи до голяма степен на разликите между Chrome и Safari, а не изцяло на настолни компютри срещу мобилни устройства. Вижте stackoverflow.com/questions /41824512/   -  person nbrustein    schedule 05.03.2017

Отговори (3)


arrow_upward
1
arrow_downward

Имах проблеми с масивно масово вмъкване (100 000 - 200 000 записа). Реших всичките си проблеми с производителността на IndexedDB с помощта на библиотеката Dexie. Има следната важна характеристика:

Dexie има страхотно изпълнение. Неговите групови методи се възползват от недобре позната функция в indexedDB, която прави възможно съхраняването на неща, без да се слуша всяко събитие onsuccess. Това ускорява максимално производителността.

Dexie: https://github.com/dfahlander/Dexie.js

person Francesco    schedule 16.06.2017
comment
Прочетох (изключително разпръснатия и голям) код на Dexie и открих (вижте dbcore-indexeddb.ts), че магическият сос е, че той хваща последната извършена операция и задава обратните извиквания на тази и приема, че всички предишни операции са били завършени до момента, в който тези са ударени. Така че успехът на последната заявка на групова операция събира данните и разрешава обещанието. Нито една от останалите заявки няма манипулатори onsuccess, както е посочено. - person Yet Another User; 20.07.2021

arrow_upward
0
arrow_downward

Как се съхраняват вашите данни в indexeddb? Всичко ли е в едно хранилище на обекти или използвате ли множество хранилища на обекти. Имате ли нужда от всички кеширани данни незабавно?

Ако имате само едно хранилище на обекти, можете да започнете със съхраняването на всички данни, от които първоначално се нуждаете, да извършите тази транзакция и да започнете нова за всички останали. По този начин можете да започнете да извличате първоначалните данни, докато вмъквате останалите. IndexedDB е асинхронен, така че трябва да ви блокира.

Ако имате множество магазини за обекти, можете да използвате една и съща стратегия. Първо попълнете незабавно магазина за обекти, от който се нуждаете, и отложете останалите.

Или може би обмислете използването на AppCache API вместо indexeddb API. Използвайки това, можете просто да кеширате javascript файл, съдържащ всички json обекти, които искате да кеширате. Това е по-скоро случаят, когато не се нуждаете от много запитвания към данните.

person Kristof Degrave    schedule 25.03.2015

arrow_upward
0
arrow_downward

Някои доста лоши проблеми с производителността на IndexedDB могат да бъдат причинени от продължителен период от време, когато браузърът просто извиква обратни извиквания onsuccess и се натъква на цикъл на събития, след като работата действително е свършена. Моделът на производителност, наблюдаван от моето приложение, което правеше това, беше, че свърши куп работа, след което просто отговори на хиляди обратни извиквания много неефективно:

екранна снимка на chrome Profiler, показваща куп неща с четливи имена на функции в плътно запълване, след това куп по-светли региони, почти сякаш оцветени в сиво

Дясната част на това изображение е обратните повиквания за всяка заявка. Решението да направите това е, разбира се, да не поставяте обратно извикване на всяка заявка, но преди това не ми беше ясно как да направя това.

Начинът, по който Dexie.js постига това (за подробности вижте src/dbcore/dbcore-indexeddb.ts), е, че запазва последната заявка (напр. IDBObjectStore.put и т.н.) изпрати и задава onsuccess обратно извикване на това, което след това събира резултатите от останалите заявки. По този начин се избягва адът за обратно извикване.

Друг подход от това е да се използва събитието IDBTransaction.oncomplete и изобщо да не се притеснявате за обратните извиквания на отделните заявки.

(забележка: да, знам колко стар е този въпрос, имах този проблем днес и исках да поставя нещо по-полезно за този въпрос, който е високо в резултатите на Google)

person Yet Another User    schedule 20.07.2021