Все, что изложено ниже, является вольным пересказом некоторых интересных примечаний из книги M. Dashorst, E. Hillenius "Wicket in Action".
Есть одно важное отличие в плане разработки между традиционным "тонким" клиентом и современным полнофункциональным web-приложением, о котором не так часто говорят. Это отличие - в том, что при разработке web-приложения нужно стремиться к минимуму используемой им памяти.
Представим для начала, что для работы с сервером вам требуется написать просто desktop-приложение. Будете ли вы в первую очередь беспокоиться о том, сколько памяти оно будет требовать для своей работы? Учитывая, что дни компьютеров с 640 KB на борту давно позади, и мы живем в те времена, когда для того, чтобы купить несколько тысяч лишних MB оперативы, не нужно копить несколько лет, работая на трех работах, даже если ваше приложение будет требовать для работы 10-20 MB памяти, это значит лишь, что вам просто не о чем волноваться. Не так уж и плохо, учитывая, что iTunes может запросто скушать 145 MB.
Но если вы пишете web-приложение, которым будут пользоваться 100 человек одновременно, то тогда требования к памяти сервера взлетают сразу же до 1 GB! А что будет, если ваше приложение станет популярным и о нем узнают тысячи человек? В таком случае у вас будет два выхода (вариант "бросить нафиг это гиблое дело" мы пока что рассматривать не будем), первый из которых совсем не исключает второго: придется вложить кучу денег в оборудование и/или найти путь снизить требования приложения к памяти.
На самом деле, хранение большого количества данных в пользовательской сессии на сервере само по себе не очень хорошая затея. Пользовательские сессии содержат в себе по сути копии объектов данных, и эти копии обычно быстро становятся устаревшими. Так, если некий пользователь Вася случайно нажмет кнопку "Назад" в браузере, то он может быть немного озадачен: "Что произошло? Я же уже вводил здесь информацию о своем любимом коте!". И еще, чем больше пользователей, тем больше копий одного и того же объекта будет храниться в памяти. А это пустая трата памяти, которая могла бы быть использована для других данных и пользователей.
Кроме того, если приложение выполняется на кластере, то чрезмерное раздувание пользовательских сессий может сказаться на производительности. Дело в том, что в случае выполнения на кластере состояние сессии должно быть синхронизировано между всеми узлами кластера. И чем больше это состояние, тем больше информации должно быть синхронизировано. Синхронизация стоит времени чтения из канала и записи в канал (по-научному это называется операциями ввода-вывода) и ширины этого самого канала. И также, обычно, синхронизация производится с использованием - не поверите! - сериализации. А это явно не может сказаться лучшим образом на производительности. Поэтому уменьшение количества данных, которые требуется синхронизировать, - обычно самый верный способ избавиться от тормозов в такого рода приложениях.
В принципе, альтернативой хранению данных в клиентской сессии может быть получение данных каждый раз по запросу клиента. Но этот способ тоже чреват проблемами с производительностью.
Выходом здесь может быть реализация механизма кэширования. Во-первых, помещение небольшого кэша между базой данных и web-сервером позволяет быть уверенным, что единовременно только одна копия объекта данных содержится в памяти. Во-вторых, кэш - на то он и "небольшой" - может быть сконфигурирован таким образом, чтобы использовать только определенное количество памяти. И это позволит нам всегда иметь доступную память для обработки запросов и хранения данных новых, долгожданных пользователей!
Комментариев нет:
Отправить комментарий