Hi everyone I need your expert opinion on the following.
We have a monolithic Asp.net Webforms application, Which is integrated with the SQL Server database, and its working since last 10 years.
Now we are planning to shift that application to .NET 6 to increase the application performance. There is 80% of the logic is written in store procedures.We want to run both
application parallel with the same database.
client want us to use same database and build all new architecture with the existing database but there will be new changes as well
one option is we will clone the SP and make changes in it – 50 SP – clone 50 SP
what other best option we can do?
Thank You
2
Answers
Why can’t you rewrite the logic of SP? In this way, you can get rid of SPs and implement new logic as well.
Really? Who suggest that to you? Perhaps a used car salesman?
I mean, what kind of performance increase you expect to get here? And why?
I NEVER seen ANYONE float the idea that a poor performing applcation can or will EVER be fixed by updating to some next version of .net (beyond silly to think that).
Good performance is a result of a good design – not some blame on the tools or frame work. (This is a beyond silly position to take, or even suggest).
The idea that upgrading the version of .net is going to address, fix, help, or even address performance is so beyond laughable, it is not even funny.
Have you done any test to suggest, hint that ANY noticeable performance increase would occur?
Again: upgrading the version of .net not going to fix ANYTHING at all here.
In fact, in near every case of the last 20 years of software? The next version of the “OS” the next version of office, the next version of sql server?
In EVERY case, they require more memory, more CPU and more computer resources. There are VERY rare exceptions to this rule.
In other words, new versions of everything tends to run SLOWER and take MORE resources!!!
So, the newer version of .net? You not going to see much more of anything nor any difference at all.
As I noted, maybe 10% at BEST and at worse, even less.
But, as I stated, 10% for a page that takes 10 seconds to load is 1 second less (still 9 seconds). If 10 seconds is too slow for a page to load, then 9 seconds will also be too slow.
For a page that takes 1 second to load, you now load in 0.9 of a section (1 10th of a second – again, useless performance change).
I mean, you have to determine where and what parts of the applcation run slow. And you NOT EVEN defined what you mean by slow!
For example, is the applcation slow for pages without data?
Perhaps the database operations are slow. Perhaps the connection from the web server to the database is limited?
Thus, upgrading to a new framework will mean no improvises to the speed of the database.
But then again, if pages without data operations are fast, then it never was the framework anyway.
The idea that upgrading the version of .net does not out of the blue mean then that the sql server “decides” to run faster because you change the client program from ms-access to say .net? (Answer: no, the database server will run the same speed, and this is regardless – even when NOT using .net.
This whole narrative is silly, and in fact beyond silly. This is amateur hour and a comedy show at best.
And what kind of performance increase are you looking for?
I mean, let’s assume you get a magic 10% increase. (Pure speculation – but les pretend you do).
Gee, ok, say a page takes 7.5 seconds to load.
Well, ok with a 20% increase that 1.5 seconds faster. In other words, the page is now going to load in 6 seconds. Are users REALLY going to notice that much???
So, spend a huge boatload of money, all for less than 2 seconds saved? Gee, who gets to rack up those kind of billable hours!!!
As noted, this is a beyond silly position here.
And, is this a hosted solution, or do they host their own server? Same goes for the database used.
If this is an on-site server, then what kind of hard drives and serer is being used here?
I mean, how about upgrading from say older hard drives to SSD. Try raid up say 4 of them to together as one drive.
If they are using hard drives now, and jump to SSD + a raid setup?
Gee, that’s not even $1,000, and that now less than 2 days of developer cost.
Those “raid” SSD drive can give you 10x the speed you get now.
So, in place of the page taking 7.5 seconds, and then maybe with a re-write take 6 seconds?
With new disk drives, you now LESS than 1 second!!! – All for the cost of what, less than 2 days of developer time??? Don’t even have to change the software!!!
Why are you suggesting to re-write these routines? And why are you suggesting to copy all 50 of them? (Again, beyond silly here).
And have you EVEN determined that any of these routines are slow, or in fact even poorly written? (And can be speed up???).
but then again, you not even noted if you going to use the same database, or the schema is to be changed. If the schema is to be changed, then of course you making and working on a copy of the database. (so copy the database, and including the stored procedures). In other words, if you planning to run the new and old system at the same time, are you to use the SAME one database for both applications? Or is the new system to be 100% and new data entered will only exist in the new system? (again: no clear idea here by you at all).
If an existing stored procedure can be used, then it should be used.
If the goal is to keep both systems running, then you NOT talking about a database schema change, are you?
Thus, all existing store procedures should be used. If one of the existing store procedures has to be changed and WILL return different values, or different columns? Or it is now to accept different parameters? Then dead simple, that change would break existing software. If the new software for SOME VERY GOOD reason can’t use an existing stored procedure, then you have to create a new one. But that has ZERO to do with making a “copy” of the 50 existing stored procedures.
But then again, you not noted the type of database, and you not even made clear if the new and the older system is to the use the SAME database?
If the same database is to be used here, then as noted, you not going to change existing tables let alone stored procedures, since any major changes to the database will break existing software.
If an existing stored procedure currently returns the data required, then I see ZERO reasons to change such routines, copy such routines, or even modify such routines.
If a defend store procedure that is to return different columns, and accept different parameters? Then you have to create a new stored procedure, because it now doing something different than the existing ones, and thus you need a new routine.
Cleary, new software can and should use all existing store procedures, and once again you provide ZERO reasons and evidence that existing stored procedures should not be used, and you in fact provide zero evidence that they need to be changed.
I mean, either you using the existing live database, or you are not. (But then again, that seems to not even be clear in your mind, nor clear to the readers here – again, this just shows how silly this whole question, and whole process is here. I would suggest you find someone with experience in using computers and that of using .net).
If you feel comfortable walking into your local hospital and going up to the floor and managing doctors where they do advanced surgery, then by all means, go manage those doctors at the hospital.
And if you feel comfortable managing a complex software applcation, then by all means do so. But the years of experience required to manage those doctors, or the years of experience required to manage such software systems? They are the same, and in some case the software system will take more time and efforts then what those doctors spent 10 years learning).
However, given the narrative so far here? I don’t think those people giving you the information you shared here should put on a band aid on anyone, nor should they exist in any close proximity to computers.
If the new software needs one new stored procedure, then create one new stored procedure. This does not hint, suggest, imply that the 50 existing stored procedures should not continue to be used, or in fact there is ANY issue or problem with the existing stored procedures.
So, this whole narrative is all wrong from top to bottom. And whoever is feeding you this advice should be driving a truck, and have nothing at all to do with the software industry.