Я к тому, что странно бороться с мерцанием, не зная что это:
Я к тому, что не у рукожопов эта проблема в офисных приложениях отсутствует как класс настолько давно, что упоминание вызывает удивление.
И решения из коробки не было и в 90-х
В том же vb4 приложении использовались вызовы winapi функций из gdi32 библиотеки.
Какие конкретно уже не помню. В памяти остались лишь ключевые слова getDC, HWND
Ну майкрософт создает как-то же?
Угу, ровно там и так, что надо очень постараться, чтобы его заметить и воспроизвести.
Это сильно отличается от ваших приложений от которых, по вашим словам «вытекают глаза».
Как вы интересно боролись если не знали о мерцании?
Легко боролись.
Точно так же как друг на курсовой боролся с ним же при рендере самодельной ртс.
Но вот где-то с начала 2000-х как-то не доводилось встречать настолько криворукие офисные приложения где прямо необходимо было с этим бороться.
Отсюда и удивление, что кто-то сейчас умудряется это мерцание встречать…
И что удивительно создавать его в своих приложениях, чтобы
Но админ масштабируется примерно так же как и сервера. И как прочие разработчики.
Главное лишнюю бюрократию не разводить, которая крайне замедляет процесс реакции.
Вопрос цены актуален, но эффективность таких специалистов на порядок выше чем швецов-жнецов-дудецов из разработчиков.
А они в свою очередь могут отлично сосредоточиться на разработке.
К сожалению двух команд под рукой не было, чтобы сравнить стоимость и уровень рисков между командой dash-специалистов и командой T-специалистов.
Мы вот даже не стали думать свое делать, а просто взяли облако, ибо намного предсказуемее.
При наличии хорошего админа об этом не задумываешься.
В свое время на проектах команды которую я вел использовалось свыше 200 виртуалок.
А сколько уж реальных серверов было — нас, как разработчиков, не сильно интересовало.
На проект я просил типовые инстансы в количестве 4-5 штук. (2 бек, 2 сфинкс, отдельно мемкеш, отдельно бд, отдельно статика)
И масштабировалось все путем клонирования оных и подброса под haproxy и nginx
На пике нагрузки на одном проекте могло быть 22 бека, 18 сфинксов, 1 БД, 2 с демонами, 2 мемкеша.
ЕМНИП, году в 1996/1997 на VB4.0 решалась подобная задача путем отрисовки «всей» формы в буфер и только после этого вывода ее.
Наследовать компоненты не требовалось, более того этот механизм работал и с вообще чужими компонентами, которые и знать не знали что мы боремся с мерцанием.
Можно разруливать через приложение, которое по функции определяет к какой шарде обращаться
Можно разруливать через nginx, где функцию определения шарды реализовать при помощи того же lua
Что из себя представляет функция? В простейшем виде, например, остаток от деления айди на количество серверов, или маппинг по регулярным выражениям от хеша имени файла и т.п.
Отдача и проверка прав через скрипт и X-Accel-redirect заголовок
Техника стара как мир, если погуглить, то можно найти даже решения с expired токенами в ссылке на скачивание
Миграции при добавлении новых шард.
Аналогично легко гуглится. В простейшем случае это несколько скриптов которые производят вычисление шарды по старому и новому методу (добавление или удаление шарды влечет за собой изменение функции).
И затем выполняют копирование файлов на новый сервер (как и чем? Например, rsync)
Процесс верификации может быть или одновременно с копированием (мы проверяем идентичность и доступность файла в новом месте), или отдельной задачей по завершению переноса.
Если есть ошибки, то повторить копирование и/или выдать сообщение в лог для разбора.
Процесс удаления старых файлов выполняется только при успешной верификации и так же может идти для каждого файла сразу при копировании, или пакетно для всех по завершении верификации.
бекап выполняется для всей системы сразу и отдельно администратором.
Бекап отдельного аккаунта иногда целесообразен, если подразумевается активное удаление/добавление файлов самим пользователем и приложение хочет предоставить возможность отката действий самого пользователя.
В общем случае вместе с отправкой этого бекапа куда-либо это функция экспорта информации. Выполняется отдельным скриптом/модулем приложения.
Компрессия/декомпрессия файлов не относится к общему случаю.
Объём диска обычно дешевле процессорного времени, если вы не файл/фото хостинг
Поэтому сжимать изначально — нет смысла, поскольку это относится к оптимизации.
Лучше потратить время разработки на более критичные фичи.
Компрессия/декомпрессия, и Linux и Windows умеют сжатие разделов целиком. То есть это можно настраивать вне вашего приложения и абсолютно прозрачно для него.
Отдача, nginx умеет кешировать соответственно буде мы решили сжимать файлы самостоятельно и поштучно, то можно настраивать кеширование для распакованных файлов. Удалять nginx будет самостоятельно, следить нам не надо, только выставить нужные сроки инвалидации
Загрузка файлов.
При наличии множества шард нам придётся реализовать загрузку на выбранную шарду
Механизм похож на скачивание. Сначала определить на какую шарду поместить хотим, затем залить.
Можно генерировать служебное имя файла заранее, тогда адрес загрузки вместе с нужным именем шарды отдавать сразу с формой клиенту и он при отправке будет грузить сразу в нужное место.
Но можно и изначально грузить на сервер приложения и переносить на нужную шарду.
Не вижу проблемы хранения картинок в виде файлов.
Что касается простоты.
Да, хранить все в одной БД — проще.
Это пока единственный аргумент "за".
Но для случаев, когда "проще" имеет смысл — о масштабировании проще забыть.
Или то, или другое.
Более конкретные рецепты реализации зависят от того что именно пишется.
Какие задачи выполняет приложение и т.д.
Ну и для почитать http://ruhighload.com/server
Отдача файла посредством того же nginx в разы более легкая задача в сравнении с отдачей этого же файла из БД да еще и через приложение.
И Oracle и MSSQL Server для этих целей сделали отдельное легковесное апи, которое позволяет отдавать файл напрямую из БД минуя приложение.
В случае MySQL и FireBird такая возможность отсутствует.
Хранить файлы в БД нужно в достаточно редких и исключительных случаях (или тогда когда у вас ну очень простой бложик и вы хотите иметь абсолютно весь контент в одном месте — БД). Поэтому для большинства случаев правильный ответ — не хранить.
Тогда когда вам это потребуется — вы будете знать достаточно чтобы это сделать. Чаще всего это моменты связанные с шардингом и репликацией данных между шардами. И интенсивной работой с самими файлами.
В обычном случае в БД храним метаинформацию о файле
— реальное имя файла загруженного пользователем
— размер
— дату
— путь где хранится файл (включая служебное имя сгенерированное вами) и возможно имя файлсервера
На файлсервере вы встраиваете дерево с учетом того чтобы не хранить более 1000-2000 файлов в одном каталоге. Для этого можете именовать файлы при помощи хеширующей функции и разбивать на группы по части имени.
Ну предположим, что я совсем идиот, и флаг "отображать содержимое" у меня был отключен.
Проблема в том, что он был включён и поведение не воспроизводилось.
Аналогично с вкладками компьютера.
Вы можете уточнить свою конфигурацию, на которой вы это воспроизводите?
Я к тому, что не у рукожопов эта проблема в офисных приложениях отсутствует как класс настолько давно, что упоминание вызывает удивление.
И решения из коробки не было и в 90-х
В том же vb4 приложении использовались вызовы winapi функций из gdi32 библиотеки.
Какие конкретно уже не помню. В памяти остались лишь ключевые слова getDC, HWND
Угу, ровно там и так, что надо очень постараться, чтобы его заметить и воспроизвести.
Это сильно отличается от ваших приложений от которых, по вашим словам «вытекают глаза».
Легко боролись.
Точно так же как друг на курсовой боролся с ним же при рендере самодельной ртс.
Но вот где-то с начала 2000-х как-то не доводилось встречать настолько криворукие офисные приложения где прямо необходимо было с этим бороться.
Отсюда и удивление, что кто-то сейчас умудряется это мерцание встречать…
И что удивительно создавать его в своих приложениях, чтобы
Но админ масштабируется примерно так же как и сервера. И как прочие разработчики.
Главное лишнюю бюрократию не разводить, которая крайне замедляет процесс реакции.
Вопрос цены актуален, но эффективность таких специалистов на порядок выше чем швецов-жнецов-дудецов из разработчиков.
А они в свою очередь могут отлично сосредоточиться на разработке.
К сожалению двух команд под рукой не было, чтобы сравнить стоимость и уровень рисков между командой dash-специалистов и командой T-специалистов.
Я сильно удивлю, если скажу что админ был один? :)
И вел он не только нашу команду, но и еще как минимум 2 о которых я знал… :D
По его ЗП — без понятия.
Железо на пиках обходилось порядка 8 000 $ в месяц, это из того что краем уха слышал.
При наличии хорошего админа об этом не задумываешься.
В свое время на проектах команды которую я вел использовалось свыше 200 виртуалок.
А сколько уж реальных серверов было — нас, как разработчиков, не сильно интересовало.
На проект я просил типовые инстансы в количестве 4-5 штук. (2 бек, 2 сфинкс, отдельно мемкеш, отдельно бд, отдельно статика)
И масштабировалось все путем клонирования оных и подброса под haproxy и nginx
На пике нагрузки на одном проекте могло быть 22 бека, 18 сфинксов, 1 БД, 2 с демонами, 2 мемкеша.
1. путем поднятия еще такого же сервера
2. в рамках цодов хетцнера или любого другого крупного хостера с аналогичными же тарифами
И, да, не из коробки.
Без понятия :D
Одно я знаю точно Амазон и Азур жестоко дорого для более-менее равномерной нагрузки и без использования основной массы их фич.
Вот такое
Перекрывает потребности практически любого стартапа, который в состоянии поднять один человек за 2-4 месяца
Наследовать компоненты не требовалось, более того этот механизм работал и с вообще чужими компонентами, которые и знать не знали что мы боремся с мерцанием.
Действительно надо достаточно долго его туда/сюда дергать.
Но я не уверен, что подобное требует фикса :)
Например так:
Техника стара как мир, если погуглить, то можно найти даже решения с expired токенами в ссылке на скачивание
Аналогично легко гуглится. В простейшем случае это несколько скриптов которые производят вычисление шарды по старому и новому методу (добавление или удаление шарды влечет за собой изменение функции).
И затем выполняют копирование файлов на новый сервер (как и чем? Например, rsync)
Процесс верификации может быть или одновременно с копированием (мы проверяем идентичность и доступность файла в новом месте), или отдельной задачей по завершению переноса.
Если есть ошибки, то повторить копирование и/или выдать сообщение в лог для разбора.
Процесс удаления старых файлов выполняется только при успешной верификации и так же может идти для каждого файла сразу при копировании, или пакетно для всех по завершении верификации.
Бекап отдельного аккаунта иногда целесообразен, если подразумевается активное удаление/добавление файлов самим пользователем и приложение хочет предоставить возможность отката действий самого пользователя.
В общем случае вместе с отправкой этого бекапа куда-либо это функция экспорта информации. Выполняется отдельным скриптом/модулем приложения.
Объём диска обычно дешевле процессорного времени, если вы не файл/фото хостинг
Поэтому сжимать изначально — нет смысла, поскольку это относится к оптимизации.
Лучше потратить время разработки на более критичные фичи.
При наличии множества шард нам придётся реализовать загрузку на выбранную шарду
Механизм похож на скачивание. Сначала определить на какую шарду поместить хотим, затем залить.
Можно генерировать служебное имя файла заранее, тогда адрес загрузки вместе с нужным именем шарды отдавать сразу с формой клиенту и он при отправке будет грузить сразу в нужное место.
Но можно и изначально грузить на сервер приложения и переносить на нужную шарду.
Что касается простоты.
Да, хранить все в одной БД — проще.
Это пока единственный аргумент "за".
Но для случаев, когда "проще" имеет смысл — о масштабировании проще забыть.
Или то, или другое.
Более конкретные рецепты реализации зависят от того что именно пишется.
Какие задачи выполняет приложение и т.д.
Ну и для почитать http://ruhighload.com/server
Отдача файла посредством того же nginx в разы более легкая задача в сравнении с отдачей этого же файла из БД да еще и через приложение.
И Oracle и MSSQL Server для этих целей сделали отдельное легковесное апи, которое позволяет отдавать файл напрямую из БД минуя приложение.
В случае MySQL и FireBird такая возможность отсутствует.
Боже, какая все же печаль....
Итак, по пунктам:
Тогда когда вам это потребуется — вы будете знать достаточно чтобы это сделать. Чаще всего это моменты связанные с шардингом и репликацией данных между шардами. И интенсивной работой с самими файлами.
— реальное имя файла загруженного пользователем
— размер
— дату
— путь где хранится файл (включая служебное имя сгенерированное вами) и возможно имя файлсервера
Все.
Формальной не встречал.
Но сильно может помочь граф процессов.
Это если с этапа проектирования или рефакторинга.
Для существующих систем смотреть нужно на связность классов.
Чем меньше двунаправленных связей, тем выше шанс получить выигрыш.
Наложить на это результаты профилирования. И результаты пересечения и будут первейшими кандидатами на отделение.
Ну предположим, что я совсем идиот, и флаг "отображать содержимое" у меня был отключен.
Проблема в том, что он был включён и поведение не воспроизводилось.
Аналогично с вкладками компьютера.
Вы можете уточнить свою конфигурацию, на которой вы это воспроизводите?
Открыл Device Manager — ничего не мерцает, как я ни меняю размер окна.
С какой частотой и как быстро его надо менять?
Блин, вы о чем?
Что за мерцание?
Пример такого стандартного Windows приложения и как это самое мерцание воспроизвести?