Пользователь
0,0
рейтинг
19 марта 2012 в 07:16

Разработка → Скорость работы корпоративных приложений из песочницы

Cовременные процессоры очень и очень быстры, но вместе с тем, работая на крупном предприятии, всё время сталкиваешься с невероятной тормознутостью программного обеспечения. Никуда не годится, когда процедура закрытия месяца в бухгалтерии идёт больше суток и если что-то где то не так, то расчёт приходится запускать заново.
В статье рассмотрены фундаментальные причины медлительности приложений и даны опорные цифры, которые послужат опорой для выбора архитектуры будущих программ.

Рассмотрим типовую схему современного приложения

image

Общая скорость работы приложения обуславливается двумя категориями:
1) скоростью работы каждого из звеньев приложения;
2) скоростью взаимодействия между звеньями приложения.

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

Разберём второй пункт. Разные звенья приложения работают как минимум в разных процессах операционной системы, поэтому для взаимодействия двух звеньев между собой операционной системе нужно, как минимум, два раза переключится между процессами. Значит, даже если сервер приложений и база данных находятся на одном компьютере, то из-за накладных расходов времени, мы не можем рассчитывать на выполнение более 8000 SQL-запросов за секунду. В сетевом взаимодействии задействовано ещё больше процессов, соответственно и число запросов уменьшается практически до 1000. Взаимодействие между веб-сервером, веб-клиентом и сервером приложений обычно гораздо менее интенсивное, чем между сервером приложений и базой данных. Единственное, связь между пользователем и веб-сервером характеризуется относительно большим временем отклика, особенно на спутниковых каналах. Так что тучу ajax-запросов устраивать тоже не стоит (чем часто грешили первые ajax-приложения). Но вернёмся к базе данных.

В нормальном режиме работы, тысячи запросов в секунду вполне хватает. Проблемы начинаются, при какой-либо массовой обработке данных. Но особенно критичным данное ограничение становится при использовании объектных надстроек, в том числе и такой популярной, как система 1С. Особенность применения ООП в том, что оно порождает кучу мелких обращений к базе данных. И из этой ситуации сейчас существует два выхода:
а) разместить логику приложения внутри базы данных;
б) кэшировать данные внутри сервера приложений.

Выбрав вариант «а», вы сможете увеличить скорость примерно на два порядка порядок: до 100 000 запросов в секунду. Неудобство в том, что при этом мы вынуждены логику реализовывать на встроенном языке базы данных. Вариант с С# или Java –процедурами не подходит, т.к. такие процедуры выполняются в виртуальной машине, которая фактически является отдельным процессом и по времени взаимодействия практически не отличается от внешнего сервера приложений. И хотя встроенный язык программирования не очень приспособлен для реализации логики приложения, во многих банках используется именно такой подход. В основном в таком случае используется, конечно же, Oracle со своим встроенным PL/SQL.

Рассмотрим далее вариант «б». Если «на пальцах», то реализация логики при данном варианте выглядит следующим образом: загружаем большими блоками все данные, которые могут понадобиться в массивы в памяти. Обрабатываем. Выгружаем результаты обработки в базу данных. Из базы данных строки загружаются очень быстро – порядка миллиона штук в секунду. Обрабатываются данные тоже очень быстро. Проблема в загрузке данных в базу. Здесь у нас опять 1000 строк в секунду. Нестандартными приёмами можно загружать до 100 000 строк в секунду. Для очень крупных предприятий такой метод не подходит, т.к. объёмы данных таковы, что не помещаются в оперативной памяти. Вместе с тем, такой способ наиболее подходит для оптимизации 1С, не нужно только забывать, что линейный поиск очень медленен даже в оперативной памяти и вам придётся делать собственную реализацию индексов.

Откуда же взялась граница в 100 000 строк в секунду, которую мы никак не можем преодолеть, используя базу данных. Ответ прост – это примерная средняя скорость построения индексов в базе данных. Да, несмотря на то, что современный процессор может отсортировать 100 млн строк за полсекунды, Oracle тратит около 20 секунд на построения индекса в 1 млн элементов. Это надо иметь ввиду при разработке приложения. И даже этих 100 тысяч строк в секунду можно добиться только благодаря процедурам на строенном языке либо массовой загрузкой данных из файла. При использовании SQL-комманд, мы получим максимум 10 000 запросов в секунду. Можно повысить общую скорость путём кластеризации, но время отклика повысить очень и очень сложно.

Напомню, что речь идёт о массовой обработке данных, например закрытия месяца или закрытия года. В повседневном режиме обычной скорости работы вполне хватает.

Теперь поговорим о перспективах. Сейчас тихо и незаметно происходит настоящая революция в компьютерной технике – переход на 64-бита. И это не просто возможность установить больше 4 гигабайт памяти – такая возможность была ещё на Pentium II путём использования расширенных режимов процессора. 64 бита, это возможность включить любой объём данных в адресное пространство процессора. Вкупе с развитием твёрдотельных дисков, которые по своей сути больше похожи на оперативную память, нежели на классические жёсткие диски, это кардинально меняет облик будущих систем обработки данных. По всей видимости, в скором будущем мы увидим объединение сервера приложения и базы данных. Первые шаги сделаны: Oracle купила технологию Java, а Microsoft уже встраивает SQL-запросы в язык C#. Т.е. они стараются засунуть логику внутрь своей СУБД. Недостатком данного подхода является то, что логика, строящаяся на принципах ООП не очень хорошо ложиться на реляционную модель данных – при этом на порядок увеличивается число запросов к базе данных. Впрочем, крупные банки, которые будут использовать данный подход, могут себе позволить вообще не переходить на новые технологии разработки. Так, ИТ-департамент Сбербанка по численности сопоставим с общей численностью персонала. В компаниях же производственного сектора программистов гораздо меньше и новые технологии здесь, как ни странно, более востребованы.

Другой подход противоположный – встраивание базы данных внутрь сервера приложений. Из существующих технологий наиболее близкими являются NoSQL-базам данных. При таком подходе, мы можем использовать всю мощь современного процессора. Производительность приложений сходу повышается в тысячи, в миллионы раз. Но, при таком подходе используется ООП, главной особенностью которого является необходимость в быстром доступе к случайным областям базы данных. Наиболее эффективно это можно реализовать путём маппирования файла базы данных в адресное пространство сервера приложений. Необходимо отметить, что, такие популярные языки программирования, как C#, 1C, Java, не имеют средств, для прямой работы с памятью, и, поэтому, для них необходимо создавать дополнительные прослойки unsafe-кода, для возможности такой работы.

Оценим объём необходимой оперативной памяти. Повсеметное использование мультимедиа-технологий даёт немного не правильные представления об объёмах памяти, занимаемой информацией. Сейчас возможно прозвучит неожиданно, но 1 мегабайт может уместить в себе томик Войны и Мира. В этом легко убедится, перемножив количество страниц в книге, число строк текста на старанице и число букв в строке. Мы получим примерно 1 млн символов. Далеко не каждый пользователь, не владеющий навыками слепой печати, «вбивает» в компьютер по несколько томов Толстого ежегодно. Даже продовщица, непрерывно сканирующая продукты в магазине порождает всего порядка 10 мегабайт информации за год. Для офисных же пользователей, мы можем смело ставить 1 мегабайт в год на человека. Да, есть вордовские файлы, скан-копии документов, фото, музыка, фильмы — но, согласитесь, все эти виды информации лежат в базе данных «как есть» и никак не обрабатываются (за исключением полнотекстового индексирования), поэтому и в оперативной памяти они не нуждаются.

Выводы. ООП, доказавшее, за 30 лет своего существаования, свою эффективность, не может использоваться нами полностью, т.к. оно плохо совместимо с реляционными базами данных. В топике даны ориентировочные цифры, используя которые, можно выбрать оптимальную глубину внедрения ООП, и знать границы возможностей будущего приложения.
Рамиль Сабиров @Sabirman
карма
0,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (49)

  • +31
    Мне кажется, что автор данного топика не совсем понимает, о чем ведет речь.
    • 0
      Я обобщил результаты работы по расшиванию узких мест в своих проектах, сделал выводы и изложил их здесь. Если у кого-то другие данные, буду рад увидеть и узнать, как вы этого добились.
  • +1
    К сожалению, нынче модные интерпретируемые и полуинтерпретируемые языки программирования, такие как C#, 1C, Java, не имеют средств, для прямой работы с памятью, поэтому в нынешнем виде они непригодны для разработки в будущем.

    Вообще-то всякие маленькие базы данных типа SqlCE работают in-process с приложением — не важно на чем оно написано. Тут скорее не язык должен это поддерживать, а сама база данных.
    • +5
      Ну и справедливости ради: c# и java уже давно не интерпретируемые, потому и достаточно шустрые. А процедуры на них (соответственно в mssql и oracle/postgres) работают с объектом соединения фактически на разделяемой памяти, что опять же не может положительно сказываться на производительности. Ну и массированную запись опять таки можно распараллелить по какому-либо показателю между серверами приложений. Точно так же с выборкой. — таблицы кластеризуются например по годам. Проверено как раз на АБСке одного крупного производителя в ритейле
      • +3
        таблицы кластеризуются например по годам

        — эта штука вроде называется «партиционирование».
        • 0
          Да, конечно. Прошу прощения — когда писал комментарий, запамятовал это слово.
      • –2
        Поэтому я их назвал «полуинтерпретируемыми»
        • +2
          Дважды компилируемые все же, имхо. Сначала в промежуточный код при сборке, а при запуске jit-ятся в процессорозависимый.
      • +1
        | Проверено как раз на АБСке одного крупного производителя в ритейле

        Извиняюсь, за возможно некорректный вопрос… Хотелось бы оценить объём данных, с которыми приходится работать ритейлу. Т.е. интересно, на сколько гигабайт растёт база в год и на сколько гигабайт растёт размер сжатого архива этой базы (для оценки фактического объёма данных в базе)
        • –1
          Извините, не могу. NDA.
  • +3
    Какая-то каша.
    Хотя если считать основной мысль о том, что неплохо бы ОРМ совершить некоторый эволюционный скачок, то я соглашусь.
    Совсем не раскрыта роль кэшей, а без них в тяжелых приложениях никак. Ну и NoSQL решения уже давно шагают по планете, на них хотя бы можно переложить сбор внутренней статистики и протоколирование некритичных операций.

    Разговаривать про некие «общесистемные» пороги ограничений бессмысленно, пока речь не идет о конкретной архитектуре, конкретной БД с ее скоростью индексов, и конкретных ресурсах. Какие-то ограничения относительно БД всегда будут и проблема их существования решается архитектурно, путем балансированием в пределах CAP в соответствии с задачами.
  • +2
    Интересуют тесты в результате которых получены цифры и конфигурация железо\СУБД
  • +11
    Статья в которой читатель узнаёт, что 1С это нынче модный язык программирования, но у него как и Java с 1С нет никаких шансов в будущем.
    • –2
      1) ну да, слово «модные» не совсем удачное, можно вместо него читать «распространённые»
      2) точная фраза «в нынешнем виде они непригодны для разработки в будущем»
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Разумеется, красивых цифр не бывает. Разумеется, на разных системах были разные данные. Напрмер, в статье приведены данные, о том, что Oracle строит индекс по 1 млн элементов за 20 секунд, т.е. 50 000 строк в секунду. Тем не менее, я оцениваю этот показатель в 100 000 строк в секунду. Естесственно, при таком округлении не имеет значение, было ли там 20 секунд или 22 секунду. На смысл статьи это не влияет. FireBird строит индексы, например, со скоростью 20 000 строк в секунду. И это самый большой недостаток этой базы данных, с которой мне пришлось несколько лет работать. Процессор Pentium III 1000 МГц 1 Гб ОЗУ строит индекс по 100 млн элементов за 0,54 — это данные, которые я получил сам в далёком 2003-м году.
      Надо сказать, что я оценивал качество своих тестов, сравнивая достигнутые результаты с результатами у других людей. И у других цифры были гораздо ниже.
      • +1
        >«Oracle строит индекс по 1 млн элементов за 20 секунд, т.е. 50 000 строк в секунду. Тем не менее, я оцениваю этот показатель в 100 000 строк в секунду» — я чего-то догоняю
        • +1
          Ну вы сравните 100 тысяч и 100 миллионов — разница в три порядка. И округление в 50 000 на фоне такой разницы (кстати, в пользу баз данных) не имеет большого значения.
          • +2
            Логика статьи мне непонятна. Тесты приводим по одним объемам, рассуждаем о других. При этом не скромно «округляя». И какой смысл рассуждать о размещении бизнес логики, всяких джавах и сишарпах, когда фиксация в БД является узким горлышком и, собственно, определяет тему топика?
            • +1
              Вы правильно подметили, что узким местом является база данных. Нехило округляя, мы тем самым даём большую фору системам управления базам данных. И даже с такой форой базы данных оказываются очень медлительными на фоне настоящих возможностей современной техники.
      • +3
        Oracle строит индекс по 1 млн элементов за 20 секунд

        Вы же понимаете, что это ооооочень сильно зависит от железа и нагрузки.
        Вот мой тестовый сервак, здесь железо далеко не продуктивное:
        SQL> set timing on
        SQL> create table test as select level val from dual connect by level <= 1e6;

        Table created

        Executed in 1.312 seconds
        SQL> create index test$val$idx on test(val);

        Index created

        Executed in 0.75 seconds


        И нельзя, нельзя сравнивать построение индекса и скорость сортировки. Индекс это построение сбалансированного двоичного дерева, цель которого — увеличение скорости доступа к данным. Это куда больше чем просто получение отсортированного набора данных. Если вы попытаетесь самостоятельно построить двоичное дерево, пусть и без сброса на диск, лишь в оперативе, я полагаю вам придется изрядно потрудиться, чтобы таки померяться с ораклом.
  • +12
    >Особенность применения ООП в том, что оно порождает кучу мелких >обращений к базе данных.
    Кучу мелких запросов в БД делает неопытный программист, и не важно какой подход к разработке применяется.
    • –3
      ООП поощряет неопытного программиста к созданию кучи мелких запросов, а у опытных не всегда есть время, чтобы помогать исправлять такие вещи
      • +3
        При чем здесь ООП вообще? Каким образом оно что-либо поощряет? В конструкторе объектов по дефолту зашито обращение к БД?
        ООП и БД — это абсолютно разные, непересекающиеся, друг от друга независимые вещи.

        При прочтении статьи у меня сложилось впечатление, что ваша профессия — системный аналитик, консультант или что-либо наподобие, потому что (моё мнение) вы никогда не писали код. Вы не являетесь специалистом по Java, C#, теории языков программирования, вы не знаете, что такое JIT компиляция и т.д.
        8000 SQL-запросов за секунду

        Что это за цифра? Откуда она взялась, какие конкретно запросы вы имели ввиду, какая СУБД, какое железо, какой совокупный объем данных, какие индексы БД?

        В общем для того, чтоб делать ТАКИЕ громкие заявления, в статье не хватает аргументов.
        • –4
          1) При чём здесь ООП
          ООП, за 30 лет своего существования, подтвердило свою эффективность. Поэтому всегда стараются писать в объектном стиле, даже если программируют для реляционных баз данных.

          2) Каким образом ООП поощряет к созданию кучи мелких запросов
          Вы правильно отметили, что ООП и БД это разные вещи и они сложно друг с другом сочетаются. Давайте рассмотрим случай, когда есть два класса: «книга» и «автор». У автора есть поле «Имя». У книги есть «Название» и ссылка на автора. Предполагается, что если вы пишете на объектно-ориентированном языке, то вывод списка книг с именами авторов будет выглядеть примерно следующим образом

          for (int i=0; i<books_count; i++)
          {
          print ("%s %s", book[i].name, books[i].autor.name);
          }


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

          3) Про 8000 строк — подобный вопрос уже был, я на него ответил ниже. Это число было получено в результате очень сильной оптимизации алгоритмов репликации данных между серверами

          4) Про «ТАКИЕ громкие заявления»
          Выводы напрямую следуют из цифр, полученных в результате тестов. Для того чтобы сделать другой вывод нужно либо найти ошибку в цепочке логиечских рассуждений, либо показать, что цифры неверны.

          • +1
            Охренеть.
            Ну если мозги отключить и выбросить, то да. Но это ещё постараться надо.
        • 0
          При чем здесь ООП вообще?


          ООП это прежде всего подход. Подход, при котором еденица воздействия — объект. Если мы попытаемся применить этот подход к обработке больших массивов данных, мы будем вынуждены работать не с множествами объектов, а с каждым объектом по отдельности.

          ООП и БД — это абсолютно разные, непересекающиеся, друг от друга независимые вещи.

          Абсолютно верно. Но в последнее время действительно имеется тенденция применения объектной парадигмы при работе и с реляционными данными. Многие фреймворки маскируют реляционный слой, предоставляя его ОО обертку. 1С — прекрасный тому пример.
  • +2
    > поскольку мы всегда можем поставить рядом ещё один сервер и распараллелить сервера приложений и веб-сервера.
    Вы научились распараллельвать произвольный алгоритм на произвольное число узлов? ACM в курсе?

    > даже если сервер приложений и база данных находятся на одном компьютере, то из-за накладных расходов времени, мы не можем рассчитывать на выполнение более 8000 SQL-запросов за секунду
    > сетевом взаимодействии задействовано ещё больше процессов, соответственно и число запросов уменьшается практически до 1000.
    Очень интересно узнать: как измеряли/считали?
  • –1
    >> поскольку мы всегда можем поставить рядом ещё один сервер и распараллелить сервера приложений и веб-сервера.
    > Вы научились распараллельвать произвольный алгоритм на произвольное число узлов? ACM в курсе?

    здесь видимо претензия к тому что, я включил в список на распараллеливание сервер приложений. Здесь имеется ввиду то, что если вы программируете JSP/JSF или ASP.Net, или PHP (а именно на них в большинстве случаев идёт разработка), то как правило все веб-запросы выполняются независимо друг от друга. Поэтому, если вы специально не блокировали такую возможность, вы можете к одной базе данных подключить несколько веб серверов с серверами приложений.

    >Очень интересно узнать: как измеряли/считали
    Данные получены в результате работы над системами репликации данных между серверами баз данных. Достоверность данных проверялась, путём сопоставления с даннымми из других источников.
    Например только сегодня появилась статья:
    habrahabr.ru/post/139708/
    В ней автор с седьмой попытки выжал «1000» запросов в секунду из FireBird-а. Так что достоверность данных из статьи в очередной раз подтвердилась.

    Тем не менее кто-нибуть предоставит более высокие данные — буду рад посмотреть, как ему удалось их получить.
    • +1
      Скорость работы корпоративных приложений вообще не зависит ни от языка, ни от компилятора, ни от базы данных. У них сложность высокая, описанные в статье факты не занимают и десятка процентов от общей сложности.

      На этом же сайте есть блог ЕРП, он как раз про корпоративные приложения. Статей непосредственно по коду или скриптам там практически нет, именно по вышеописанной причине.
      • –1
        Да, верно, скорость работы корпоративных приложений практически не зависит ни от языка программирования, ни от базы данных. Узким местом, как это и показано в статье, является связь между «языком программирования» и базой данных. И чтобы это узкое место убрать, нужно либо логику разместить внутри базы данных, либо базу данных разместить внутри сервера приложений. Оба этих метода в статье рассмотрены.
        • +2
          раз ни база ни язык программирования не являются узким местом то и не важно что там между ними происходит.

          Статья из раздела «Я сам даже маленькую бухгалтерию не написал но сейчас буду рассказывать как это делать правильно».
          • –1
            Тесты показывают, что вы ошибаетесь, и накладные расходы на взаимодействие очень велики.
            • +2
              нет тут никаких тестов. Повторюсь:

              Статья из раздела «Я сам даже маленькую бухгалтерию не написал но сейчас буду рассказывать как это делать правильно»
              • –1
                Вы не доверяете каким-то цифрам? — давайте перепроверим…
                • +2
                  Что перепроверять-то? Вот утверждение из текста:

                  Значит, даже если сервер приложений и база данных находятся на одном компьютере, то из-за накладных расходов времени, мы не можем рассчитывать на выполнение более 8000 SQL-запросов за секунду.

                  да легко SQL-сервер может выполнять 8000 SQL-запросов в секунду. На хабре полно людей которые с такой нагрузкой работают. Вот и всё.

                  Для справки
                  — результат запроса может кешироваться SQL-сервером
                  — отдельные части результатов запроса могут кешироваться и объединяться
                  — данные могут кешироваться в памяти
                  — план запроса SQL-сервером строится как в зависимости от данных так и в зависимости от нагрузки

                  И это при том что само использование термина запрос в таком контексте некорректно т.к. запросы могут выполняться мгновенно а могут расчитываться в течении пары суток.
                  • –2
                    Вы можете себе представить, чтоб ваш SQL-сервер выполнял 100 млн запросов в секунду? Нет? — вот об этом и идёт речь. Никто не спорит, и в статье об этом говорится, что в результате различных оптимизаций SQL-сервер можно разогнать до 100 тысяч запросов в секунду. Но 100 миллионов ему не по зубам.
                    • +1
                      При желании можно и один запрос написать который завалит сервер.

                      Дурное дело нехитрое.
                    • +1
                      Так можно целую серию статей написать %) «Почему нельзя читать со скоростью 100 млн знаков/с», «Почему коты не бегают со скоростью 100 млн км/ч»…

                      «Можно повысить общую скорость путём кластеризации» это и есть те самые различные очень тонкие способы оптимизации?
          • –3
            Посмотрел ваш профиль…

            Не подскажете, можно ли в Java каким-либо образом организовать маппирование файла в память. Например, через native-интерфейс вызвать системную функцию по маппингу файла и потом каким-либо образом работать с выделенным участком адрессного пространства как с обычным Java-массивом.
        • +1
          С вашим выводом я, в общем и целом, согласен, как и с некоторыми тезисами.

          Применение парадигмы ООП действительно существенно увеличивает показатель запросов/секунду. Закрытие периода выполненное в традициях этого подхода, действительно заспамит базу данных запросами. В то же время можно и обойтись десятком — другим запросов, но это уже больше ближе к выносу логики на сторону сервера.

          Однако подводка… действительно заставляет недоумевать.

          Разумное зерно в вашей статье безусловно есть. Но оно далеко не на поверхности. И от него очень отвлекают спорно сформулированные тезисы и сферические цифры в вакууме.

          Думаю, люди вас просто не поняли — очень подкачало изложение.
          • 0
            Спасибо. Как говорится, первый блин…
    • 0
      > Здесь имеется ввиду то, что если вы программируете JSP/JSF или ASP.Net, или PHP (а именно на них в большинстве случаев идёт разработка), то как правило все веб-запросы выполняются независимо друг от друга. Поэтому, если вы специально не блокировали такую возможность, вы можете к одной базе данных подключить несколько веб серверов с серверами приложений.
      Независимые друг от друга запросы мало кому нужны, обычно хочется чтобы после обновления баланса одной тётенькой-бухгалтером его и остальные увидели обновлённым. Все эти JSF, MVC, Rails и прочие по умолчанию переносят все проблемы синхронизации и межпроцессного взаимодействия на БД. Соответственно они и всплывают все и сразу на этом уровне.

      > В ней автор с седьмой попытки выжал «1000» запросов в секунду из FireBird-а.
      Автор занимался не тестированием РДБ, тем более что выборка ведётся из служебной таблицы содержимое которой даже ен приведено в статье, а запись даже не рассматривалась. Статья посвящена исследованию взаимодействия конкретного фреймворка с БД.

      Взгляните ещё раз внимательно проблему которую пытаетесь рассмотреть в статье — она состоит из нескольких очень ортогональных частей. Вы пытаетесь свалить всё в кучу и решить оптом, это очень-очень сложно.
      • 0
        | Все эти JSF, MVC, Rails и прочие по умолчанию переносят все проблемы синхронизации и межпроцессного взаимодействия на БД.

        Мы с вами говорим об одном и том же. В статье как раз и указывается, что мы можем распараллелить всё, кроме базы данных — именно в ней и происходит синхронизация.

        | Статья посвящена исследованию взаимодействия конкретного фреймворка с БД.

        Извините, но вы не вникли в суть вопроса: мы именно обсуждаем взаимодействие фреймворка с базой данных И говорим, что именно накладные расходы на такое взаимодействие съедают все возможности современной техники
  • –1
    Судя по отрицательному отношению к статье, можно сделать вывод, что сейчас лучше отказаться от использования маппирования файлов в память. При этом наш высоконагруженный сервер приложений должен при загрузке потратит некоторое время на кэширование данных из базы данных. Зато потом он будет работать очень быстро и при этом мы по прежнему будем вести разработку в 64-битном режиме на защищённом языке программирования: Java, C# и т.п.
    • 0
      Да ладно, все проще, можно сделать вывод что написана ахинея %)
      • 0
        Так можно про всё что угодно сказать. А где конструктивные комментарии? — нету. Где комментарий о том, что в четвёртом фреймворке появилась возможность маппирования сверхбольших файлов? — нету… Где предложения попытаться что-нть сделать? — тоже нету… Плохо, очень плохо…

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.