rPman

первый же запрос в гугл
html transparrent background gif animated

https://www.sitepoint.com/community/t/how-would-i-...

Почти наверняка вы 99% времени меняете DOM объектов, которых даже не видно на экране, так выставьте их реальное перемещение на скроллинг, двигая только те элементы, что сейчас видимы на экране.

Если вам действительно нужна сложная анимация, где элементы двигаются независимо (а иначе их можно было бы разместить в едином div-е и двигать его максимально оптимально) то да, у вас проблема и придется менять используемые инструменты. Например чуть более эффективно работает SVG а еще более эффективно canvas и конечно же 3d-рендеринг с использованием видеоускорителей.

p.s. 99% проблем создает именно HTML DOM, на его изменения обычно тратится уйма времени.

Проверьте запускаете ли вы приложение с сетевого или webdaw диска или с локального (локальным диском так же считается подключенный vhd с сетевого размещения), особенно если вы используете javafxpackager или аналоги, заворачивающие java виртуальную машину в exe приложение. Запуск с помощью java - jar считается локальным (а отладчик так и делает), так как exe-приложением является виртуальная машина java а она у вас скорее всего установлена локально.

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

Существуют еще soft модемы, где практически все эмулируется драйверами и оформляется в виде pci/isa устройства.

я видел очень старый модем isa аппаратный (какой то acorp) там устройство физически подключалось через isa но в системе появлялся com порт.

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

Выкиньте из головы маркетинговую кашу про облака, бедные люди, как вам маркетологи голову запудрили.

100+ гигабайт это выглядит как созданные на пустом месте проблемы (потому как даже с идеальным провайдером долго такие выкрутасы не по делаешь), небось еще в виде архива одним файлом? А там небось внутри 99% файлов уже переданных ранее.

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

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

--------------
подскажите, что у вас за файлы? что в них? постоянные 100гб выглядят как что то необычное? у вас мини коллайдер стоит?

Если баз МНОГО то не только считайте количество тригерами, но и делайте запросы в базу асинхронными, иначе даже после десятка баз последовательный запрос будет выполняться секунды.

Еще есть практика кеширования данных и инвалидация кеша при возникновения событий (тригерить события notify на клиент - методы есть), т.е. делать запрос только в те базы, по которым пришел notify (тут же и проверять).

p.s. будьте осторожны, несколько баз работают независимо и не умеют транзакции, т.е. количество может измениться в процессе чтения и к примеру если вы перемещаете объект между базами, суммарное количество объектов не изменилось (тут убрали там добавили) но при запросе количества можно получить на 2 меньше или больше, т.е. неверное значение.
Одно из решений, храните несколько последних значений подсчетов количества с датой их получения, а запрашивать эти данные только те, дата которых ниже даты запроса

теоретически могут возникнуть проблемы из-за точки в имени но если у вас все работает...

из lua почти всегда есть возможность делать http запросы, в них заворачивайте необходимую информаци.
на своем веб-сервере ожидайте эти запросы и перекидывайте куда хотите

Вам же ради изучения?

Придется, пройти хоть и в ускоренном темпе, всю историю геймдева со времен наверное игровых приставок, только что не придется решать проблемы с ограниченностью ресурсов и скоростью железа.

Т.е. начните с 2D-платформеров, классическое игровое поле (некая виртуальная картинка больше экрана), почитайте про спрайты.

Затем переходите к изометрии, тут простыми спрайтами не всегда можно обойтись (правда близард когда делали diablo очень неплохо соптимизировали движок), прочувствуете всю силу объема, на начальных уровнях.

Затем можете попробовать сделать простую 3D игру, это перевернет ваше представление об игре но благодаря опыту, собранному в предыдущих этапах (что такое игровой цикл например) это будет проще чем если с этого начинать

Само собой, никто не заставляет вас пилить работу с графикой самостоятельно! боже упаси, пользуйтесь возможностями современного железа.

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

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

Если предложения выше вам не помогут, и вам нужно весь файл зачем то считать в память, то воспользуйтесь 64-битной версией php, поправив в php.ini
memory_limit = 8192M

p.s. если ваш файл - картинка, смело умножайте на 4 ваши требования по оперативной памяти

У вас должна быть отдельная сущность - заказ, которых много, у которых есть статус - не оплачен, оплачен, доставлен и т.п. в момент, когда вы нажимаете оплатить - все содержимое корзины должно переехать в новый заказ а корзина очиститься.

Если пользователю понадобится, дайте ему возможность открыть историю заказов и при необходимости набрать корзину заново (или повторно оплатить, если статус - отказ/ошибка/отмена).

unix way - не пытайтесь найти готовый комбаин, собирайте ваше решение из кирпичиков. Пусть за iscsi отвечает тот же istgt а за снапшоты - btrfs.

Если закрыть глаза именно на iscsi (мало ли вы виртуальные машины через них подключаете локально, видел я такие конструкции) У qemu/kvm есть опции когда можно подключить диск но все изменения пишутся в отдельный файл. То же самое есть у всех крупных систем виртуализации, правда называется везде по разному.

Если универсально, то исторически lvm позволяет делать снапшоты на блочных устройствах, но за счет значительного понижения производительности, т.е. вы можете создать 100500 снапшотов на основе вашего базового диска, и каждый отдать в свою отдельную машину. Не рекомендую для вашего случая 256 активных снапшотов это будет фейл.

Вы можете воспользоваться copy on write файловыми системами например btrfs или zfs (хуже в linux работает), в них создание снапшота не понижает производительность (т.е. за это не приходится платить), правда сами файловые системы менее шустрые, так как сильно фрагментируют контент, но если сравнивать с lvm то на порядок эффективнее.

p.s. windows машины очень активно пишут при обновлениях, гигабайтами, наступит момент, когда весь этот сыр бор будет создавать больше проблем чем пользы.
btrfs и zfs имеют фичу - дедупликация, т.е. вы просто рядом складываете все копии ваших контейнеров а система сама находит одинаковые блоки и оптимизирует, правда в зачаточном уровне, btrfs только offline (это относительно новая фича, почти нет нормальных утилит, но если ставить самую свежую версию из исходников, там много что добавили вкусного) а у zfs под linux жутко низкая производительность (я игрался на десктопном железе, не рекомендуется для hdd только ssd), причем ничем не оправданная, и дикое потребление оперативной памяти (70 байт на блок, т.е. для 4кб блоков 1тб hdd будет кушать 18гб ram, правда никто не делает 4к блоки, 16 или 32 да), она будет оправдана в вашем случае и автоматически сократит занятое место одинаковыми машинами.

p.p.s. только что установленный windows со включенным сжатием zfs занимает на диске 8гб места, btrfs чуть больше... через год использования место, занимаемое контейнером (никаких программ не установлено, это машина была исключительно для запуска google chrome) - 26гб (внутри контейнера 46гб).

Когда то давным давно, еще до WFP используя обычные Windows Forms и классы Dataset писал сложную прослойку-кеш для базы данных, десятки таблиц. Речь шла о 'покликать лениво мышкой', вся база в памяти, сохранение штатным сериализатором (в ту же xml - две строчки кода), сотни мегабайт, работало с приемлемой скоростью.

p.s. Сказано что без sql? берите любую готовую nosql базу данных ;) например redis

в РУ зоне эта деятельность под запретом, так что у вас вариант только кредитные карты visa/mastercard и соответствующие иностранные платежки.

Пройдитесь по сайтам секс-игрушек и посмотрите, через кого они проводят переводы.

правьте тайминги в bios, в 99% случаев можно заставить работать на пониженных частотах или других таймингах, все индивидуально под вашу материнскую плату и память.

Самое простое, создать в планировщике заданий с тригером 'однократный' со временем в прошлом и запускать командной строкой, читать SCHTASKS /Run /?

В свойствах задачи можно указать повышенные привелегии