Асинхронный выходной буфер для календаря (c #)

Question

Хорошо, в настоящее время я пишу веб-приложение для планирования для большой компании, и оно должно быть быстрым . Обычный быстрый (<1сек) не подходит этим ребятам, поэтому мы стремимся к <0,5сек, чего трудно достичь при использовании обратных передач. </p>

У меня вопрос: есть ли у кого-нибудь предложения о том, как лучше всего буферизовать данные календаря / расписания для ускорения загрузки?

Мой план состоит в том, чтобы загрузить данные выбранной недели и еще одну неделю по обеим сторонам и использовать их для буферизации вывода: т. Е. Никогда не будет загружаться запрашиваемая неделя, это ' Он всегда будет в памяти, и он будет буферизовать недели с обеих сторон для следующего изменения.

Однако я не совсем уверен, как именно этого добиться, асинхронная загрузка проста при использовании ajax-методов, но вопрос в том, где хранить данные (временно) после их загрузки: в настоящее время я использую статический класс. со словарем>, чтобы сделать это, но это, вероятно, не лучший способ масштабирования до большой базы пользователей.

Есть предложения?

EDIT

Количество загружаемых данных не особенно велико (для каждой встречи имеется несколько полей, которые преобразуются в небольшой контейнерный класс и на них выполняется некоторая обработка для организации дат и расчета одновременных встреч, и это маловероятно из-за домена будет более ~ 30 встреч в неделю), однако база данных находится под очень высокой нагрузкой из других областей приложения (это крупномасштабная система очень с тысячами пользователей, передающих большой объем информации вокруг).

Answer 1

Итак, вы помещаете свой буферизованный контент на клиент или сервер? Я бы подумал, что нужно сделать так, чтобы данные за предыдущие и последующие недели были объединены в структуру данных javascript на странице, а затем клиент мог бы организовать их для вас. Тогда вы могли бы просто асинхронно возвращаться к серверу в течение следующей недели, когда открывается одна из ваших буферизованных соседних недель, так что вы всегда на неделю вперед, как вы сказали, предполагая, что данные будут доступны только через неделю недельный путь.

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

Может быть действительно легко предположить, что, поскольку у вас есть инструмент, такой как Ajax, вы должны использовать его все время, но затем я использую молоток для почти всех работ по дому, поэтому Я в порядке, чтобы говорить на этом фронте.

Answer 2

Буферизация не поможет на первой странице, однако - только при последующих запросах назад / вперед.

Tbh Я не думаю, что есть много смысла, так как вы захотите поддерживать гиперссылки и перенаправления из других источников в той же или большей степени, чем просто назад / вперед. Вы также можете «прыгнуть» на месяц. Принуждение пользователей переходить назад и вперед, чтобы перейти к тому месяцу, который они хотят, на самом деле займет больше времени и будет более разочаровывающим, чем время ответа

Вам лучше вообще кэшировать данные (используя что-то вроде Velocity), так что вы почти никогда не попадете в базу данных, но даже это будет сложно для многих пользователей.

Моя рекомендация - заставить его работать, а затем использовать инструмент профилирования (например, ANTS Profiler), чтобы увидеть, какие биты кода можно оптимизировать, если он будет функционально корректным.