Cache Mechanism

Product: PowerShell Universal
Version: 1.4.6

Hi, i’m still using an old UD Version, but i would like to switch to PSU.
I’m only using the REST Endpoints parts . ( no dashboards at all ! )

In UD i was using Scheduled Endpoint to populate some Cache variables, and fetch data in my REST endpoints.

I’m struggling to reproduce the same behavior with PSU.

if i create a basic script $cache:test = 1..1000 | get-random and the schedule it with the admin console, i’m not able to retrieve the content of $cache:test in my REST endpoint.

So maybe i’m missing something, or not understanding someething correctly :frowning:

thanks in advance for the help :slight_smile:

At least for newer versions… If you are looking to utilize the cache, I’d say use Set-PSUCache and Get-PSUCache. They function in a similar manner and I can confirm they work.

I don’t know if the Cache scope is tied to those functions but I have not had much luck using that scope in my personal testing.

ok so in your experience, you can define a cache variable in a scheduled endpoint and use it in a rest endpoint ?

From my understanding of the Documentation, the PSUCache is available throughout the product. But there is no reference to the $Cache: variable scope in the docs for this functionality. They may not be directly related.

The $Cache scope only works in dashboards. The *-PSUCache cmdlets work throughout the product. The difference is that the PSUCache stores items are CliXml rather than live objects like the $Cache scope.

You can create a scheduled job in PSU to set the variables and then use them in your endpoint as the cmdlets will be available in both places.

2 Likes

Arf ok ! thanks for the reply @adam
thats settle it … i wont be able to migrate to PSU at the moment :frowning:

I was using the cache variable to store Exchange Online pssession (live object) and use these sessions in my REST endpoints… !

If you are persisting exchange online sessions for performance reasons, I’d suggest using a persistent runspace for your API environment.

Module.psm1

function Get-EOSession {
    if ($Global:EOSession  -eq $null)
    {
           $Global:EOSession = Connect-EOSession 
    }
   $Global:EOSession
}

Environments.ps1

New-PSUEnvironment -Name 'Persistent' -Path 'pwsh' -PersistentRunspace -Module @('Module.psm1')

Settings.ps1

Set-PSUSetting -ApiEnvironment 'Persistent'

What this will do is not flush the runspace state after every execution. You will be able to store your PSSession in a global variable. The module will be automatically loaded into each runspace and you will have access to the Get-EOSession function so you can retrieve your session in your endpoints.

2 Likes

omg … i have to test that … !!! thank you @adam !

1 Like

I actually just realized how useful this is for Azure as well. I hadn’t really considered it (I have a script that runs every so often to maintain the connection, since it seems to persist across the system regardless) but this seems like it could be very useful :thinking:

yes it’s super useful … i can tell you exactly what i did, but you can guess … :wink:

1 Like

ok @adam i tried you solution and it kinds of work ^^

i’m saying this, because it’s not totaly what i was looking for …

when i mentionned that i had a cache variable holding pssession i meant more than one Exo session.
And even with one session i dont think i can use your example, because, when the session dies, i will be forced to recreate the session, when a user makes a call to the endpoint, by calling the function.
This will crumble the performance of the endpoint as i have to wait for the creation of the session.
(dunno if i’m clear … )

What i’m doing right now with UD (old version … ): I have a schedule route, that will manage the
Exo sessions for me … when a session dies, it will recreate a new one, and the user experience will be intact.

I had the same mechanism for refreshing some cache variable imported from big csv ( the csv were also generated using some scheduled endpoints.). For this, i think i can use the PSUCache cmdlet and a PSU Schedule + PSU Script. Or maybe switch to a real Database + a PSU Schedule.

If i’m not very clear (sorry english is not my primary language) i can show you some code sample of how i managing it with my old UD.

the question is: can we hope for a cache variable scope that is available through the whole product ? or maybe available for the Rest api part ??

the question is: can we hope for a cache variable scope that is available through the whole product ? or maybe available for the Rest api part ??

No because everything is in a separate process. The server-wide cache works by serializing everything across the process boundaries.

What you could do is store the sessions in global scope in your module. Then create an endpoint that is responsible for refreshing that cached global scope sessions. Then call that endpoint on a schedule.

2 Likes