We have a point-of-sale system that was developed using ado.net, our current concern is to make the application real fast in creating transactions (sales). Usually there are no performance concerns with high end PCs but with with low end PCs, the transactions take really slow.
The main concern is on saving transactions which usually calls a lot of stored procedures for inserting records within a single transaction. This usually takes time on low end PCs. We need to improve the performance since most clients will only use low end PCs to act as cashier machines. One solution we are thinking is to use entity framework for data access. The entire project is written using ado.net and development time if we shift to entity framework would be alot. Any suggestions?
5
I would like to point out that Entity Framework (full name: ADO.NET Entity Framework) is an ORM (Object Relational Mapper) that uses ADO.NET under the hood for connecting to the database. So the question “should we use ADO.NET or EF?” doesn’t really make sense in that respect. Unless you re-architect your application, adding EF to the mix is simply adding another layer on top of ADO.NET.
I sincerely doubt that ADO.NET is the source of your performance problems, however. It sounds like the problem exists in your stored procedures themselves.
I think Luc Franken’s comments are on the right track, though. You need to measure and determine exactly where the delays are happening. Then concentrate on fixing exactly that problem. Anything else is groping around in the dark.
1
If you are looking for performance stay away from EF. It is the slowest ORM out there and uses a lot of memory to keep the database metadata. Most benchmarks out there show that –
4
You say you are calling a “lot of stored procedures”. If every call includes a seperate trip to the database, that is your performance issue, because trips to the database are always expensive, no matter what they do. You should have one stored procedure to save a transaction. If that procedure has to call other procedures, fine, as long as you don’t have to make a seperate trip to the database.
2
How necessary is it that each transaction require a database call?
At what point is the db insertion being performed? Is there one call per transaction or is it inserting with every addition to the order causing a major lag throughout the user’s interaction?
Can the db call be handled through private HTTP requests to a dedicated server on the client’s own LAN?
Perhaps a better approach would be to save the transactions in a repository and post them to the server all at once using the Unit of Work pattern that is triggered as soon as there is a pause of more than 5 seconds. Or perhaps the slow client machines could post to a service that can handle the database insertions.
What else could be slowing the machine? Is the GUI processor intensive? It’s a POS, not a graphic designer’s portfolio piece.