I can't also trace this query in my code.
QUERY1 :- (@1 nvarchar(88),@0 datetime2(7))UPDATE [dbo].[Sessions] SET [Expires] = @0 WHERE ([SessionId] = @1)
QUERY2 :- (@p0 nvarchar(4000))SELECT TOP (2) [Extent1].[SessionId] AS [SessionId], [Extent1].[Created] AS [Created], [Extent1].[Expires] AS [Expires], [Extent1].[LockDate] AS [LockDate], [Extent1].[LockCookie] AS [LockCookie], [Extent1].[Locked] AS [Locked], [Extent1].[SessionItem] AS [SessionItem], [Extent1].[Flags] AS [Flags], [Extent1].[Timeout] AS [Timeout] FROM [dbo].[Sessions] AS [Extent1] WHERE [Extent1].[SessionId] = @p0
By the looks of the queries I'd guess you're using SQL server as a session state provider and, unfortunately, that comes with a performance cost. In the first instance I'd look at whether you really need to store sessions in SQL server. Presumably you've gone down that route because you're running your site on load balanced servers? If so, maybe you could look at using session affinity rather than round-robin load balancing which would allow you to switch to the in-memory session state provider which is much faster (though be aware that your traffic will be less evenly distributed between servers).
You could also consider your use of session state in your application. If you don't need it or can remove your reliance on it, you can switch it off entirely.
If neither of those options are viable, maybe consider using a faster out-of-process session storage mechanism like Redis or the session state service.
Can you please tell me in little more detail why my system using this query again and again?
You probably have your site configured to use database provider for session. it works with multiple-servers scenario, but as Paul mentioned, it comes at a cost, in this case, performance. You can think about cookie session, or even Redis one (more work is needed)
But can i use sticky session(Inproc) instead of cookie session.