My<cod/>.net
Результаты поиска
ASP.NET кэширование
Недавно я исследовал возможности кэширования в ASP.NET.
Я свернул свой собственный "Cache", потому что я не знал ничего лучше, это выглядело немного так:
public class DataManager
{
private static DataManager s_instance;
public static DataManager GetInstance()
{
}
private Data[] m_myData;
private DataTime m_cacheTime;
public Data[] GetData()
{
TimeSpan span = DateTime.Now.Substract(m_cacheTime);
if(span.TotalSeconds > 10)
{
// Do SQL to get data
m_myData = data;
m_cacheTime = DateTime.Now;
return m_myData;
}
else
{
return m_myData;
}
}
}
Таким образом, значения хранятся некоторое время в singleton, и когда время истекает, значения обновляются. Если время не истекло, и запрос на данные выполнен, то будут возвращены сохраненные значения в поле.
Каковы преимущества использования реального метода (http://msdn.microsoft.com/en-us/library/aa478965.aspx ) вместо этого?
Составлено PHP?
Есть ли у кого-нибудь опыт работы с ускорителями PHP, такими как MMCache или Zend Accelerator ? Я хотел бы знать, делает ли использование любого из них PHP сравнимым с более быстрыми веб-технологиями. Кроме того, есть ли компромиссы для их использования?
Может ли прокси-сервер кэшировать SSL GETs? Если нет, то будет ли достаточно шифрования тела ответа?
Может ли (||любой) прокси-сервер кэшировать содержимое, запрошенное клиентом через https? Поскольку прокси-сервер не может видеть строку запроса или заголовки http, я думаю, что они не могут.
Я рассматриваю настольное приложение, управляемое рядом людей, стоящих за своими компаниями прокси. Это приложение может получить доступ к услугам через интернет, и я хотел бы воспользоваться встроенной инфраструктурой кэширования интернета для 'reads'. Если кэширующие прокси-серверы не могут кэшировать доставленное содержимое SSL, будет ли просто шифрование содержимого ответа жизнеспособным вариантом?
Я рассматриваю все запросы GET, которые мы хотим получить, будут запрошены через http с телом, зашифрованным с помощью асимметричного шифрования, где у каждого клиента есть ключ расшифровки. Всякий раз, когда мы хотим выполнить операцию GET, которая не является cachable, или операцию POST, она будет выполнена над SSL.
System.Web.Caching против блока кэширования корпоративной библиотеки
Для компонента .NET, который будет использоваться как в веб-приложениях, так и в богатых клиентских приложениях, существует два очевидных варианта кэширования: System.Web.Caching или Ent. Библиотека. Блок Кэширования.
- Что вы используете?
- Почему?
System.Web.Caching
Является ли это безопасным для использования вне веб-приложений? Я видел смешанную информацию, но думаю, что ответ будет maybe-kind-of-not-really.
- a KB статья предупреждение против использования 1.0 и 1.1 не веб-приложений
- На странице 2.0 есть комментарий , который указывает, что это OK: http://msdn.microsoft.com/en-us/library/system.web.caching.cache(VS.80).aspx
- Скотта Хансельмана пугает эта идея
- Страница 3.5 содержит предупреждение против такого использования
- Роб Говард поощрял использование вне веб-приложений
Я не собираюсь использовать один из его основных моментов, SqlCacheDependency, но добавление CacheItemUpdateCallback в .NET 3.5 кажется действительно хорошей вещью.
Блок Приложений Кэширования Корпоративной Библиотеки
- другие блоки уже используются, поэтому зависимость уже существует
- сохраняемость кэша не требуется; регенерация кэша при перезапуске составляет OK
Некоторые элементы кэша должны быть всегда доступны, но периодически обновляться. Для этих элементов получение обратного вызова после удаления элемента не очень удобно. Похоже, что клиенту придется просто спать и опрашивать, пока элемент кэша не будет повторно заполнен.
Memcached для клиента Win32 + .NET
Каковы плюсы и минусы, когда вам не нужен распределенный кэш?
Как лучше всего справиться с кэшем и кнопкой возврата браузера?
Как лучше всего обращаться с пользователем, возвращающимся на страницу, на которой были кэшированы элементы в приложении asp.net? Есть ли хороший способ захватить кнопку Назад (событие?) и обрабатывать кэш таким образом?
Схемы кэширования для управляемых языков
Это в основном ориентировано на разработчиков настольных приложений.
Как я могу создать блок кэширования, который хорошо играет с GC?
Как я могу сказать GC, что я только что сделал очистку кэша, и пришло время сделать GC?
Как я могу получить точную меру того, когда пришло время выполнить очистку кэша?
Есть ли какие-либо готовые схемы кэширования, из которых я мог бы заимствовать некоторые идеи?
Какой кэшер PHP opcode следует использовать для повышения производительности?
Я пытаюсь улучшить производительность при высокой нагрузке и хотел бы реализовать кэширование кода операции. Какой из следующих вариантов следует использовать?
Я также открыт для любых других альтернатив, которые ускользнули от моего радара.
В настоящее время работает на складе Debian Etch с Apache 2 и PHP 5.2
[Обновление 1]
HowtoForge добавлены установочные ссылки
[Обновление 2]
Основываясь на полученных ответах и отзывах, я протестировал все 3 реализации, используя следующий план тестирования Apache JMeter в своем приложении:
- Авторизоваться
- Доступ К Домашней Странице
При наличии 50 одновременных подключений результаты выглядят следующим образом:
Нет Кэширования Кода Операции
APC
eAccelerator
XCache
График производительности (чем меньше, тем лучше)
Из приведенных выше результатов следует, что eAccelerator имеет небольшое преимущество в производительности по сравнению с APC и XCache. Однако самое важное из приведенных выше данных заключается в том, что любой вид кэширования кода операции дает огромную производительность boost.
Я решил использовать APC по следующим двум причинам:
- Пакет доступен в официальном репозитории Debian
- Более функциональная панель управления
Чтобы подвести итог моему опыту:
Простота установки: APC > eAccelerator > XCache
Производительность: eAccelerator > APC, XCache
Панель Управления: APC > XCache > eAccelerator