DWUTKA at marlow.com
DWUTKA at marlow.com
Mon Jun 19 12:45:45 CDT 2006
Very common misconception when dealing with web stuff. I listen to people over sell web servers/applications all the time. Getting a person/company to buy 10x the machine they really need. We run several web sites here. 9 times out of 10, if a website is slow, it's due to the pipe, not the machine. For example, we're behind a T1 here. So if you hit any of our sites, it's limited by the speed of the T1. Now let's think about that. If you are behind a T1, you are talking a 1.5 megabit/sec connection. That is 1/60th the speed of a normal 100 megabit LAN connection. Do you need 4 processors, 20 gigs of Ram, with a RAID 10 SCSI setup to work on a 100 megabit network connection? Of course not, a standard computer works just fine. Same with web stuff. When building a machine to serve as a webserver, the only real consideration should be the RAM. (Because the more ram you have, the more the webserver can cache). Of course I am talking about single site hosting. If you are a hosting company, and are going to host hundreds of websites on one machine (and have a screaming connection to the internet back bone), then you obviously need a heftier machine. Take a look at our website: www.marlow.com . No comments on the actual 'look' please, I'm not an artist, and my company is too busy to get a 'pro' to make it look better. But that site is running on a PIII 800 mhz desktop, with 384 megs of RAM running Windows 2000 Server. We get about 300 users a day on our website. Our site has a product database and a shopping cart, both of which are run off of an Access 97 .mdb. It's been running for years, and has NEVER had a problem. In fact, in the 3 or 4 years that it's been running, the first and only 'issue' was a design complication that came up a few weeks ago. The way the products database worked, there was no way to add non 'standard coolers' to the RoHS Product listing. I could do it directly in the database, but the guy that 'controls' the product listing didn't have the ability in the 'control' pages I built for him. I know this goes against a lot of what many IT departments say about Access. But let's look at some facts. If you have an .mdb running locally on a webserver, then the .mdb is being used by one machine, and therefore only has one user in it. It doesn't matter if you have 1000 web users hit your site at the same time, the webserver itself is going to only process them one at a time, and therefore is only going to hit the .mdb as a single process, it will just do that 1000 times in a row. With the .mdb being local, the process itself is screaming fast. (We are running a raid setup on our webserver, faster HD access is definitely a plus). So what kind of performance can an .mdb really handle? Well, a webserver can log all of it's activity. Our webserver(s) all log their activity to an .mdb. They fill up relatively fast. (The webserver takes about a year to fill, our intranet we just stopped logging, because it was filling up once a month, and didn't really need the info). That is the only true consideration to think about when deciding if Access is right (other then needing very tight security), the database size potential. But a properly designed shopping cart/ product database shouldn't be immense. Our products database is still under 3 megs. Back to performance, we ran some performance tests with our webservers, and we maxed our 100 mbit LAN connections to them without the webserver or the .mdb's blinking. Drew -----Original Message----- From: Kath Pelletti [mailto:kp at sdsonline.net] Sent: Monday, June 19, 2006 1:22 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] SQL and Access Drew - no, they don't have SQL Server. I thought that since this really should be viewed as a web application that Access wouldn't be the best back end for future growth. This company sells DVD's online - they are getting into selling more and more products which will be available for downloading to mobile phones etc. It sounds to me like I should plan for significant growth, so that put me off Access. Kath ----- Original Message ----- From: DWUTKA at marlow.com To: accessd at databaseadvisors.com Sent: Sunday, June 18, 2006 7:28 AM Subject: Re: [AccessD] SQL and Access Do they already have SQL Server? If not, why not just stick with an Access .mdb backend? Drew -----Original Message----- From: Kath Pelletti [mailto:kp at sdsonline.net] Sent: Friday, June 16, 2006 3:14 AM To: Access D Normal List Subject: [AccessD] SQL and Access Hi everyone - Can I pick your brains? I have a client who needs to put some data on the web which will connect to a 3rd party shopping cart product, ie. they want to display their goods on the web and allow them to be sold on to retail clients. They already have the shopping cart side organised, but they have a statically typed website - no database to feed it. They also need an internal system which will meet administration, management and reporting requirements - but fairly simple stuff. They are very strapped for cash (smirk) and want a fairly inexpensive solution. Lately I have been working on .net with SQL Server 2005 systems which would be a great solution - but way too expensive in development costs. So what about SQL Server BE with Access front end? I know it's very common but can someone tell me: - any gotchas - cost for client in terms of licences they would need for SQL? I can't seem to find a clear answer by googling. Thanks. ______________________________________ Kath Pelletti Software Design and Solutions Pty Ltd. Ph: 9505-6714 Fax: 9505-6430 Email: KP at SDSOnline.net -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com