LINUX.ORG.RU

Объем памяти рантайма js

 ,


0

1

Сколько данных можно напихать в массивы js?

Поясню кейс: Крупная торг-компания. Заказы клиентами делаются через сайт, но это фигня. Через сайт же работают и ТП (торговые представители, а не то что ты подумал). Причем работают с планшетов, мобильно. Иногда не в самых лучших условиях связи. Необходимо минимизировать количество запросов к серверу и их объем. Часто ТП работают с заказами которые уже были - просматривают их, повторяют. Работают со списком этих заказов. Каждый заказ совершен по какому-то договору, которых у одного клиента может быть штук 5-6 при этому у одного ТП может быть до 100 клиентов. Вобщем список обширный... Вот что я сделал - на клиент передается список заказов в JSON который не содержит ни каких данных о договоре - только его ID (ну прямо как в базе хранится). Скрипт просматривает JSON, собирает ID договоров и делает отдельный запрос к серваку вытягивая данные по договорам с нужными ID, добавляет их в JSON и передает его дальше для генерации HTML. Но данные не забывает, а сует их в «глобальный» массив с ключами == ID. В следующий раз (ТП пролестнул страницу списка заказов) скрипт уже добавляет данные из этого массива, и если встречен новый ID, делает запрос еще один для получения данных с сервера. Т.е. вначале запросов вроде как больше, но вскоре все договоры попадают в массив и пока не зкрат браузер (а он у них по полдня не закрывается) лишние данные не гоняются.

Вроде все нормально. Но тут меня посетила мысль, а что если то же сделать с товарами - клиенты заказывают обычно одни и те же товары и ТП просматривают ограниченный список их. Соответственно в составы заказов, да и в каталоге, можно гонять только ID товаров, а их свойства ( а их может быть штук по 10 текствых), ссылки на картинки, цены хранить точно так же...

Это вообще нормально? Сколько данных можно держать в памяти js интерпретатора?

★★★★★

Какой JS фреймворк используется? Какой-нибудь MVC/MMVM фреймворк было бы удобно (Knockout.js, Ember.js, Backbone.js).

Black_Roland ★★★★
()
Ответ на: комментарий от Black_Roland

Да, я знаю. Собираюсь использовать между сессиями. Но мне кажется доступ туда будет медленее чем напрямую из массива в памяти, поэтому в рантайме массив.

Suntechnic ★★★★★
() автор топика
Ответ на: комментарий от Black_Roland

Никакой. Просто несколько скриптов. Там нет каких-то сложностей великих. Да и не сталкивался я с js фремоврками особо. Я редко берусь за js вообще. Но спасибо за наводку. Посмотрю что это.

Suntechnic ★★★★★
() автор топика

Сколько данных можно держать в памяти js интерпретатора?

Столько, сколько поместится в память говнопланшетки. Может, чуть меньше.

anonymous
()

Это вообще нормально? Сколько данных можно держать в памяти js интерпретатора?

Там нету строгого ограничения, нужно тестировать на конкретной задаче, устройстве, браузере.

TDrive ★★★★★
()

Для твоих целей всегда используется localStorage. Доступен из JavaScript. Твой паттерн называется кеширующий прокси :-) Ты пытаешься кешировать в RAM, но кешировать надо на solid носитель, путём API, которое называется как написал комментатор выше.

menangen ★★★★★
()
Ответ на: комментарий от Suntechnic

Нет, доступ туда быстрый, т.к. для движка используется заточенная sqllite, она быстра и кэш её бд ОС держит в оперативке какое-то время (около 10 мин на мобилках после закрытия(kill) браузера). В ios браузер вообще не кикается дефолтом.

menangen ★★★★★
()
Ответ на: комментарий от menangen

Ясно. Я думаю не сложно мне будет все поправить на LocalStorage. Но я так же думаю о том, что данные о товарах (остаток, цены) обновляются 4 раза в день и это тоже надо помнить. LocalStorage будет хранить данные подольше чем это необходимо. Я вообще не планировал сохранять там данные которые меняются с такой частотой... Но я придумаю что-нибудь.

Suntechnic ★★★★★
() автор топика

Кстати, совсем уж нубский вопрос (не нашел вменяемого способа это сделать): я, перед получением данных о договорах, сохраняю их IDs в массив айдишников, чтобы потом их за один запрос забрать. Ну то-есть там вообще все примитвно - в цикле обрабатывается JSON, и если нужные данные есть, они сразу добавляются в html и выводятся, а ID для которых нет данных, накапливаются в массиве (в html улетает пустой тэг с классом delayUpdate и айдишником в rel). В итоге этот массив выглядит так примерно: 10,11,11,11,10,8,8,11,10,8,7,10,11 и т.п. Т.е. ID дублируются. Это не есть гут. В PHP я бы сделал добавление примерно такое $arIDs[$ID]=$ID что автоматом бы обеспечило уникальность, а в js... вобщем и так ясно к чему это приводит. А как правильно?

Suntechnic ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Говнопланшетки с 2Гб на борту кажется. Надо поинтересоваться. Но думаю у меня там все данные будет измеряться в единицах Мб - я не собираюсь пихать туда картинки в DATAURL - их и браузер неплохо кэширует.

Suntechnic ★★★★★
() автор топика

только его ID (ну прямо как в базе хранится)

параноик предлагает необратимую функцию .

qulinxao ★★☆
()
Ответ на: комментарий от Suntechnic

Но думаю у меня там все данные будет измеряться в единицах Мб

Блджад... а пафоса в вопросе на 50 терабайт... Я уж думал серьёзное что-то.

Надо IndexedDB и WebSQL. Оба, потому что часть браузеров поддерживает одно, часть другое. localStorage сразу не надо, у него после пары мегабайт пендык по квотам наступит.

Проблема в том, что у сторов радикально отличаются интерфейсы. А всякие эмуляторы работают так себе... У IndexedDB по удобству вообще какой-то ынтырпрайз. WebSQL кавайный, но объявлен deprecated. Его надо ради айпадов поддерживать и т.п.

У меня были задачи, которые в KV вписывались, для них навалял вот такую хрень https://github.com/nodeca/bag.js . Всякие пакеты, которые упрощают работу с IndexedDB в bower-е найдёте.

Vit ★★★★★
()
Ответ на: комментарий от Suntechnic

LocalStorage будет хранить данные подольше чем это необходимо.

Дату в них запиши или версию. Как маленький, чесслово.

anonymous
()

Ящитаю, несколько десятков тыщ итемов вполне можно без лагов интерфейса жонглировать в жс.

zz ★★★★
()

Необходимо минимизировать количество запросов к серверу и их объем.

спрос на товары настолько велик, что сервер не справляется?

Это вообще нормально? Сколько данных можно держать в памяти js интерпретатора?

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

По ID в общем правильно, но не забывай что иногда это не очень безопасно. В некоторых случаях на сервере лучше использовать кэш, вместо обращения к БД - своего рода буфер rowset-а

swwwfactory ★★
()
Последнее исправление: swwwfactory (всего исправлений: 1)
Ответ на: комментарий от Vit

Ага. Спасибо - гляну. А у LS кирдык наступает после 5Мб а не после пары.

пафоса в вопросе на 50 терабайт

Я не большоей спец в js. Т.е. я вообще не спец - обычно этим верстальщики занимаются. И я захожу временами на сайты типа юлмарта например, и вижу тормоза в любом браузере на системе с 16Gb оперативы и четырьмя (ну почти четырьмя) ядрами. Вот я и решил поинтересоваться почему js такой медленный.

Suntechnic ★★★★★
() автор топика
Ответ на: комментарий от swwwfactory

спрос на товары настолько велик, что сервер не справляется?

Ну там есть определенные траблы с сервером, но минимизировать запросы надо прежде всего из-за временами плохого/медленного инета у ТП.

Поэтому надо очень аккуратно: правильная зачистка мусора и предотвращение неоправданных расходований ресурсов. По возможности - с согласия и/или возможностей клиента.

Так я и хочу же аккуратно. Моби верся сильно упрощена. Я заставил дизайнеров отказаться от любых слишком усложняющих штук в ней. От рисованных бэкграундов. Выпилил половину необязательных возможностей.

В некоторых случаях на сервере лучше использовать кэш, вместо обращения к БД - своего рода буфер rowset-а

Все очень агрессивно кэшируется на сервере. Я даже недавно с этим встрял - кэш выжрал 60Gb ((( В резальтате ошибки в кэш стали отлетать данные отдельно для каждого клиента.

Suntechnic ★★★★★
() автор топика
Ответ на: комментарий от zz

несколько десятков тыщ итемов вполне можно без лагов интерфейса жонглировать в жс.

Звучит неплохо. Вот и посмотрим.

Suntechnic ★★★★★
() автор топика
Ответ на: комментарий от Suntechnic

А у LS кирдык наступает после 5Мб а не после пары

Это зависит от браузера. Гугль в помощь. Можно на 2.5 мегабайтах влететь.

Вот я и решил поинтересоваться почему js такой медленный.

Не обязательно JS. Есть миллион причин, он кривых ассетов до переусложненного DOM. Долго объяснять. Гуглите «ускорение загрузки сайта».

Vit ★★★★★
()
Ответ на: комментарий от Suntechnic

кэш выжрал 60Gb

это как??? не многовато ли для кэша? Похоже на хранение в БД или кэше, сериализованных объектов, картинок и прочей бинарщины.

В резальтате ошибки в кэш стали отлетать данные отдельно для каждого клиента.

получается практически каждому клиенту по персональной копии БД...

swwwfactory ★★
()
Ответ на: комментарий от swwwfactory

получается практически каждому клиенту по персональной копии БД...

Вот именно так и вышло. Там какая фишка - у большинства клиентов есть свои цены на отдельные товары. Т.е. буквально, скажем для этого клиента персональная цена на товар F и товар D скажем. И эти цены хранятся в профилях клиентов... долго объяснять короче из-за некоторых накладок на старые, не мои еще скрипты, которые я лишь мельком глянул, эта хрень начала кэшироваться и каждый клиент получил свой персональный кэш. Починил конечно резво, но было несколько неприятных моментов.

Suntechnic ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.