Stockage d'articles volumineux dans SessionState
est généralement une mauvaise idée - cela limitera l'évolutivité de votre application en raison de l'utilisation de la mémoire du serveur. Même si vous déplacez SessionState vers SQL Si vous n'êtes pas en mesure de le faire, cela augmentera les besoins en IO et en stockage de votre application.
Ci-dessous, je suppose que vous avez une action de génération d'image dynamique sur un contrôleur qui est ensuite référencé, par ex. <img src='http://myserver/image/generate/wmAvatar' >
En d'autres termes, la raison pour laquelle vous rendez des images dynamiques est pour la consommation d'un navigateur ?
Si les images dynamiques sont spécifiques "par utilisateur", ou par session : Au lieu d'utiliser l'état de la session, générez et fournissez les images de manière dynamique avec les paramètres appropriés. En-têtes de mise en cache Http et ils devraient ensuite être mis en cache par le navigateur. Il se peut que vous ayez encore besoin de gérer le cas de If-Modified-Since
demande
Si les images peuvent être partagées entre plusieurs utilisateurs, ou au moins réutilisées par le même utilisateur d'une session à l'autre. alors oui, vous pouvez les stocker sur un disque (par exemple, un SSD) dans un dossier configuré pour une mise en cache appropriée (et même précalculer les images si vous le pouvez) et ensuite vos img
Les liens ne seront plus dynamiques ( http://myserver/images/123456.jpg
). Vous devrez cependant gérer le nettoyage des images expirées, ainsi que les erreurs de type 404 pour les images supprimées. Comme ci-dessus, utilisez les en-têtes de mise en cache Http pour réduire les E/S inutiles. Cependant, de nos jours, la mise en cache en mémoire avec une valeur clé / une base de données NoSql est également courante, par ex. Redis qui peuvent ensuite évoluer dans le nuage, par ex. Elasticache