Что должна кэшировать правильная информация? Что такое хорошее время загрузки страницы?
Это не свойство по умолчанию тега select.
Чтобы понять это, вы должны сделать свою собственную функцию в javascript.
Вы также должны включить Jquery для этого.
Это абсолютно недостижимо в JavaScript. Вы можете добавить data атрибутов к элементам.
<select id="cars" data-selected="audi">
<option value="volvo">Volvo</option>
<option value="saab">Saab</option>
<option value="vw">VW</option>
<option value="audi">Audi</option>
</select>
В javascript вы можете прочитать значение и установить его для опции.
var selected = $("#cars").attr("data-id");
$('#cars option[value="'+ selected +'"]').prop('selected', true);
Но в любом случае, зачем тебе это?
<select selected="audi"> никогда бы не сработало ...
6 ответов
Я реализовал бы кэширование на каждом слое Вашего приложения если вообще возможный.
Можно кэшировать страницы на высшем уровне, объекты на уровне кода, и удостовериться, что база данных кэширует оба запроса и ключевые данные правильно на самом низком уровне.
С точки зрения того, ЧТО необходимо кэшировать, любые объекты, которые будут repeadedly, получили доступ, должен кэшироваться, особенно те, которые вряд ли будут изменяться очень часто. Можно затем сбросить кэш того объекта только, когда он редактируется. (Будьте осторожны из кэширования объектов, которые часто обновляются, поскольку постоянный цикл замены кэша почти на каждой загрузке ухудшит производительность вместо того, чтобы улучшить его),
Для того, чтобы измерить уровень, я не посмотрел бы на то, сколько времени единственная страница берет, чтобы загрузить, но погуглить для некоторых измерительных инструментов производительности, поскольку действительно необходимо протестировать, как быстро каждая страница работает под давлением. Ваша страница информации о пользователе не могла бы быть самой большой целью кэширования, если к ней редко получают доступ, например. Необходимо фокусироваться на наиболее в большой степени используемых страницах.
Типичный ответ:
- Информация о кэше, которая редко обновляется.
- Не кэшируйтесь что изменение часто.
В Вашем случае Вы могли кэшировать все в плоских файлах (один файл на пользователя, например) и уничтожить пользовательский файл кэша каждый раз, когда что-то обновляется соответствием. Если файл кэша не существует, Вы создаете его прежде, чем отобразить связанное содержание.
Теперь о времени загрузки (который может очень отличаться в зависимости от пользовательского местоположения), вот некоторые информативные числа от форума PHP играющего сайта:
- Время загрузки JS: 0.274
- Количество запроса: 15
- Время загрузки PHP: 0.0524
- Использование памяти: 1,013 МБ
И это рассматривает сообщество как хороший опыт. Но это ужасно субъективно.
Вопрос загрузки страницы уже задали:
Что считают хорошим временем отклика для динамического, персонализированного веб-приложения?
С точки зрения кэширования необходимо измерить количество времени, которое было бы проведено, загрузив данные каждый раз по сравнению с загрузкой из кэша. Чем больше кэш, тем менее эффективным это становится. Таким образом, Вы не хотите загружать слишком много данных в кэш. Что мы используем, вот прокручивающийся кэш, при этом последние использованные данные отбрасываются, после того как мы поражаем предел размера кэша. Вы затем настраиваете предел согласно фактическим результатам проверки производительности.
Для профиля пользователя определенные данные сохраните так, как Вы можете в билете FormsAuth / cookie. Кэширование (HttpContext. Текущий. Кэш), пользователь, определенные объекты потребуют X ресурсов на Вашем сервере на пользователя, то же как сессия, был бы (но с меньшим количеством головной боли). Если можно разгрузиться как можно больше в пользовательский Билет или cookie (как 4K) затем, Вы действительно поможете своей производительности серверов при масштабировании.
Необходимо только получать биты информации, в которой нуждается страница. Например, при загрузке данных блога не загружайте фотографию. Его больше работы, да, но если Вы хотите масштабировать Вас, должно будет проанализировать потребности в каждой странице.
Удостоверьтесь, что Вы понимаете, что существуют различия между Кэшированием Запроса Базы данных (повторное использование плана выполнения), кэширование Объекта (Httpcontext. Кэш), и кэширование страницы (Ответ. Заголовки [Истекают]).
Гуру веб-дизайна Vincent Flanders предполагает, что что-либо, более чем 4 секунды являются слишком длинными, чтобы веб-страница загрузилась. Я думаю, что это - довольно хорошее эмпирическое правило.
До кэширования или другой оптимизации производительности идут, я рекомендовал бы выполнить некоторое тестирование производительности. Существует много наборов тестирования производительности, доступных на рынке. Тестирование покажет, где проблемные области. Нет никакого смысла в Вас логики кэширования добавления к чему-то, что уже работает хорошо. С другой стороны, проблемы производительности могут произойти, где Вы не могли бы ожидать их, включая данные Вы, возможно, не рассмотрели кэширование.
Что-то, что я также нашел с тестированием производительности, - то, что оно может найти пятна в Вашем коде, где мертвые блокировки происходят, или где простая оптимизация базы данных помогла бы. Возможно, добавление индекса к таблице ускорит страницу вместо того, чтобы добавить набор кэширования логики.
Я сохранил бы это простым, и осуществил бы рефакторинг для производительности только там, где необходимо сделать так.
Кроме того, тест рано и тест часто. Я знаю, что много людей говорит для рассмотрения производительности в последний раз, но можно действительно кодировать себя в угол, если Вы не, по крайней мере, начинаете рассматривать это рано в жизненном цикле разработки.
Некоторое исследование предлагает, чтобы интерактивное приложение обеспечило обратную связь в 250 мс, чтобы не заставить пользователя думать, что это застревает или что операция перестала работать. Приемный уровень в сети несколько выше, хотя, и обычно обратная связь обеспечивается webbrowser, который загружает новая страница. С Ajax необходимо заботиться для обеспечения som вида обратной связи хотя, потому что браузер не покажет то, что происходит.