sim3x, все зависит от требований к железу, требований по нагрузке и прочего...
Например если у вас много терминалов но одновременно нагружено не много - то вариант с терминальным решением наилучший среди прочих. В подавляющем большинстве случаев это так.
Или например, если приложение требует современную видеокарту, с большим количеством оперативной памяти, но нагружает ее не сильно, т.е. на сервере задача может быть мультипицирована на десятки-сотни инстансев (отличным примером может являться небольшое количество полигонов но сложные/тяжедые текстуры, которые могут шариться между инстнасами на сервере), то выгоднее использовать стриминг.
В случае, если к задержкам нет высоких требований, а судя по всему это так, то можно использовать облачные технологии, арендуя необходимое количество серверов у провайдеров динамически (на том же амазоне) по мере появления нагрузки - в этом случае это очень СИЛЬНО позволяет сэкономить на железе. Обычно нагрузка на терминалы считанные проценты от всего их времени использования, в остальное время, например, там крутится простой видеоролик (который потянет любая железка за $30-$50 совсем не трогая сервер).
Это стриминг, нагрузка определяется параметрами видеокодирования.
Требования к каналу определяет не столько сложность сцены, сколько нагруженность текстурами и динамика (как сильно меняется изображение между кадрами), т.е. если вы сделаете 1 единственную сцену с пестрым фоном и тетраэдром по середине, и начнете двигать камеру, то это займет канал точно так же как полноценная онлайн игра с миллионами полигонов.
Если же у вас на сцене камера не двигается, фон остается неизменным или редко меняется, а в один момент времени меняется только маленькая часть (измеряется площадью в пикселах на экране клиента) то и требования к каналу падают пропорционально.
Оценить нагрузку на сервер по простому можно только экспериментально. Чтобы оценить это эмпирически, нужно значительно изучить возможности используемой видеокарты на сервере, используемые технологии и их ограничения. Главной проблемой, на мой взгляд, помимо классической траты оперативной памяти, является требования к кеш-памяти шейдерных процедур, как только она заканчивается, скорость падает драматически (сужу по своим эксприментам в использовании математических вычислений на gpu, вроде бы запас по количеству исполняемых потоков есть, но скорость при их увеличении падает)
sim3x, бывает ситуация, когда твои клиенты очень близко, десятки километров дают пинг меньше 10мс
пример, возможно не топиккастера, в торговом центре (примерочные?), вместо установки нормального железа на местах, используется дешевое железо (в т.ч. моноблоки или те же тонкие клиенты за 50$) и серверное оборудование в подвале или даже у провайдера в датацентре, удобно, дешево, быстро и защищено от вандалов.
АртемЪ, оптический канал это две башни и луч лазера
я про это и говорил, что обычный частник, без поддержки государства, не сможет провести сам провода по земле
что значит бумаги собрал и поставил?
боюсь даже в чистом поле за это с вас снимут шестизначный ценник и выпьют сотню литров крови, а в городе права уже розданы опсосам.
настройки и раньше и сейчас в игре были одинаковые?
может игра не позволяла раньше выставлять максимальные настройки текстур?
p.s. в этой статье есть отличные графики потребления оперативной памяти современными играми, все они выше или на уровне 8гб
т.е. если у вас что то еще запущено, например браузер (который может несколько гигабайт отъесть на какой-нибудь чат) то у вас все упрется именно в оперативную память
Хочется уточнить, у вас 8 гигабайт реальной оперативной памяти, не виртуальной? В данном случае, увеличение размера файла подкачки погоды не сделает (но его наличие обязательно, минимум в половину доступной памяти), в него будут помещены данные опрационной системы и не очень нужные на время игры данные самой игры (современный игродел жутко не эффективно использует железо).
Дело в том что на практике (хотя это и не обязательно, но так проще программистам), все что размещается в памяти видеокарты, дублируется в оперативной памяти (плюс еще что то), точнее наоборот но надеюсь моя мысль ясна. Если ваши игры заполняют всю оперативную память видеокарты, смело вычитайте этот объем из оперативной.
Операционная система, если ее активно не тюнить, отнимает порядка 2 гигабайт оперативки, итого на саму игру у вас осталось 2-3 гигабайта,... это не то чтобы мало, но вполне близко к тому чтобы не хватало.
Для hi-end игр рекомендация на компьютере иметь 16 гигабайт минимум.
Уменьшайте качество текстур в настройках, именно они съедают оперативную память и в видеокарте.
O_o
в чем проблема во время деплоя вашей очередной версии веб-приложения пересобирать заново изображение-архив? максимум частые обновления будут сводить на нет кеширование на стороне пользователя (это если вы каждый день будете новую картинку выкладывать, но тогда нужно другие решения придумывать, например обновленные картинки выкладывать в новом файле с дырками)
Я тестировал на не совсем новом amd phenom fx 6100 со включенной поддержкой аппаратной виртуализацией, kvm-qemu, после проброса видеокарты внутрь виртуалки, все равно заметно сильное понижение производительности.
Синтетические тесты это одно, реалии другое. Жаль я мало тестов делал, в том случае была необходимость только в запуске конкретной игры и решения не получилось.
да и параллельным программированием более менее я пользовался только при использовании cuda, в остальных случаях я сам управлял потоками, распределяя задания между ними вручную и использовал семафоры и шаред мемори (не java).
не доверяю я автоматическим решениям, точнее считаю что область их эффективного применения ограничена.
Когда я изучал вопрос (не так, просто смотрел существующие решения) мне показалось что на java все решения (гугл строку предложил в ответе) какие то перегруженные, неудобные, слишком объектно-ориентированные, как и все в java.
да, этот подход используется в electrum, это python библиотека opensource так и алгоритм.
Так тоже можно и может быть даже нужно, так как это очень удобно. Но нужно понимать что ровно столько ключей, сколько сгенерировано было на сервере публичных, столько же нужно будет сгенерировать на кошельке приватных, в случае с генерацией сотен тысяч ключей (например ваш магазин под ddos атакой) у вас могут возникнуть трудности траты этих монет... понадобится ставить свой electrum сервер или еще как анализировать адреса на наличие входящих переводов.
Я не стал предлагать electrum так как ожидается что он будет использоваться весь, а не только для генерации ключей, но его инфраструктура предполагает использование публичных серверов у которых запрашивается балансы и транзакции, это не так надежно как полностью ваша нода, ни от кого не зависимая.
karasique, у этого решения главный бонус в его разарботке, весь код базы генерируется простейшим скриптом (отдельно триггеры наполнения), а избыточность самих данных... жесткие диски дешевеют почти с экспоненциальной скоростью.
Можно предложить перекодировку проводить на стороне клиента (опционально, например за плюшки, а то обладателям мобильников и вообще слабого железа будет плохо), т.е. в процессе загрузки видео на сервер оно перекодируется тут же на лету, но готовых красивых решений нет.
Например если у вас много терминалов но одновременно нагружено не много - то вариант с терминальным решением наилучший среди прочих. В подавляющем большинстве случаев это так.
Или например, если приложение требует современную видеокарту, с большим количеством оперативной памяти, но нагружает ее не сильно, т.е. на сервере задача может быть мультипицирована на десятки-сотни инстансев (отличным примером может являться небольшое количество полигонов но сложные/тяжедые текстуры, которые могут шариться между инстнасами на сервере), то выгоднее использовать стриминг.
В случае, если к задержкам нет высоких требований, а судя по всему это так, то можно использовать облачные технологии, арендуя необходимое количество серверов у провайдеров динамически (на том же амазоне) по мере появления нагрузки - в этом случае это очень СИЛЬНО позволяет сэкономить на железе. Обычно нагрузка на терминалы считанные проценты от всего их времени использования, в остальное время, например, там крутится простой видеоролик (который потянет любая железка за $30-$50 совсем не трогая сервер).