I'm planning on hosting 3 or 4 WCF/.NET 3.5 REST webservices to be used by a new iPhone application.
I've heard good reviews about DiscountASP.NET (http://www.discountasp.net/index.aspx), but I'm pretty ignorant about shared hosting performance. At the same time, I think it's still early to pay $90 a month for a scalable Amazon EC2 server instance.
So, any idea how many hits/month would a shared hosting website handle?
It depends on how good your shared hosting is. To determine simultaneous users, you can try to benchmark the performance of your server by hitting with many requests.
Your host will likely yell at you if they see you using a lot of your cpu. For web services, bandwidth isn't so much an issue as is your cpu/memory availability.
You should be more concerned about simultaneous users instead of hits per month. You want to be able to handle any spikes in traffic. Shared hosting is less predictable because you don't control the usage of the other users on the machine.
I would say if you're starting out, shared hosting would probably be fine, just monitor it and upgrade when you see decreasing response times. Your host will probably let you know when you are affecting the performance of everyone else on the server.
They are all different. It depends on how much bandwidth they are giving you. (GB/Month is a typical metric).
I would say that hits per month could range in the low hundred thousands without causing major issues on many managed hosting. It all depends how intenst your WCF services are. The advantage is that many managed hosting facilities will allow you to dynamically add more hosting power to your site. (For more $ obviously).
Related
My application currently has around 5k regular users and is growing by about 100 users per month. I am considering having it deployed on this new Uffizzi cloud so that I don't have to think so much about maintaining my deployment but am not sure what level I need at my size or if I will outgrow the lower tier soon.
Much will depend on your application is built and how it handles requests.
The Standard Tier is designed for anything that is for Dev and Test purposes or anything that just a few people will be accessing. Good use cases are running your app in a Dev, QA, or Staging environment so you can see how it is working before it goes live to an audience (this process is very important - most features don't come out of the box working exactly as everyone on the team expected them to - or at least as your product lead expected them to)
The Performance Tier has auto-scaling and is a good choice for a public facing app that you don't want to crash under load or have delays serving up responses. If you have users in the 10s to 100s this is appropriate.
The Enterprise Tier is a good choice for several 100 to hundreds of thousands of users. The key decision is how reliable do you want your app to be. Obviously if you have an outage at any point that may hurt your reputation and the more people using your app the worse it will be. The Enterprise Tier has automated High Availability. This means your app will be deployed and load-balanced across three data centers also known as "AZs" (Availability Zones). You've effectively decreased your risk factor of a hardware failure or any other incident that would cause an outage by a factor of three.
If I want to stress test a 'classic' client-server (desktop app <-> LAN <-> database server) Windows Forms desktop application to see how it performs when many concurrent PC users are using it, how should I go about it? I want to simulate many PC users concurrently going through a work flow, to see if it all stands up and at what point the system degrades unacceptably. I've looked at many test tools but they all seems to be skewed toward testing functionality or web app performance, which is quite different.
Clearly having many actual people on actual PCs is not practical, and lots of virtual machines on a few PCs is not representative either. 'Cloud' computing (EC2, Azure etc) looks promising but the documentation and pricing information all seems to be skewed towards mobile apps or web servers, again not the same (but that could just be presentation so I remain open to the idea). I need to be able to virtualise a small LAN of many client machines running the application and a database server.
Can anyone suggest how to do this, or recommend something?
TIA
IMHO the real question is - do you really need to do performance testing in your case? Consider this - where is your business and functional logic?
Performance testing of Desktop applications is oxymoron by itself. Desktop application is made to be used by one person at a time. So if getting a response takes 5 seconds, it will take (pretty much) 5 seconds no matter how many users are clicking the button. The only real thing close to your backend is the DB and they by design support serious asynchronous load. In case this is not enough - just make a cluster.
Right now, I am hosting a site on a dedicated server, 8 GB ram, Intel Xeon E3 1230 V3. I am using long polling techniques in order to display information which gets added into a database consistently.
The problem is: so far, after around let's say 20 users come onto the site, it starts lagging and slowing down dramatically. I'm pretty sure the server is strong enough to handle way more people than that. Thus, I am not sure what exactly is the problem. Can long polling using Apache handle that many users? If not, how should I implement real-time information being displayed. And if it can, how should I configure Apache or anything in order to handle around 500-1000 concurrent users.
Any help is appreciated.
Am using Lucene API in my web portal which is going to have 1000s of concurrent users.
Our web server will call Lucene API which will be sitting on an app server.We plan to use 2 app servers for load balancing.
Given this, what should be our strategy for replicating lucene indexes on the 2nd app server?any tips please?
You could use solr, which contains built in replication. This is possibly the best and easiest solution, since it probably would take quite a lot of work to implement your own replication scheme.
That said, I'm about to do exactly that myself, for a project I'm working on. The difference is that since we're using PHP for the frontend, we've implemented lucene in a socket server that accepts queries and returns a list of db primary keys. My plan is to push changes to the server and store them in a queue, where I'll first store them into the the memory index, and then flush the memory index to disk when the load is low enough.
Still, it's a complex thing to do and I'm set on doing quite a lot of work before we have a stable final solution that's reliable enough.
From experience, Lucene should have no problem scaling to thousands of users. That said, if you're only using your second App server for load balancing and not for fail over situations, you should be fine hosting Lucene on only one of those servers and accessing it via NDS (if you have a unix environment) or shared directory (in windows environment) from the second server.
Again, this is dependent on your specific situation. If you're talking about having millions (5 or more) of documents in your index and needing your lucene index to be failoverable, you may want to look into Solr or Katta.
We are working on a similar implementation to what you are describing as a proof of concept. What we see as an end-product for us consists of three separate servers to accomplish this.
There is a "publication" server, that is responsible for generating the indices that will be used. There is a service implementation that handles the workflows used to build these indices, as well as being able to signal completion (a custom management API exposed via WCF web services).
There are two "site-facing" Lucene.NET servers. Access to the API is provided via WCF Services to the site. They sit behind a physical load balancer and will periodically "ping" the publication server to see if there is a more current set of indicies than what is currently running. If it is, it requests a lock from the publication server and updates the local indices by initiating a transfer to a local "incoming" folder. Once there, it is just a matter of suspending the searcher while the index is attached. It then releases its lock and the other server is available to do the same.
Like I said, we are only approaching the proof of concept stage with this, as a replacement for our current solution, which is a load balanced Endeca cluster. The size of the indices and the amount of time it will take to actually complete the tasks required are the larger questions that have yet to be proved out.
Just some random things that we are considering:
The downtime of a given server could be reduced if two local folders are used on each machine receiving data to achieve a "round-robin" approach.
We are looking to see if the load balancer allows programmatic access to have a node remove and add itself from the cluster. This would lessen the chance that a user experiences a hang if he/she accesses during an update.
We are looking at "request forwarding" in the event that cluster manipulation is not possible.
We looked at solr, too. While a lot of it just works out of the box, we have some bench time to explore this path as a learning exercise - learning things like Lucene.NET, improving our WF and WCF skills, and implementing ASP.NET MVC for a management front-end. Worst case scenario, we go with something like solr, but have gained experience in some skills we are looking to improve on.
I'm creating the Indices on the publishing Backend machines into the filesystem and replicate those over to the marketing.
That way every single, load & fail balanced, node has it's own index without network latency.
Only drawback is, you shouldn't try to recreate the index within the replicated folder, as you'll have the lockfile lying around at every node, blocking the indexreader until your reindex finished.
There's alot of information out there on setting up LAMP stacks on a single box, or perhaps moving MySQL onto it's own box, but growing beyond that doesn't seem to be very well documented.
My current web environment is having capacity issues, and so I'm looking for best-practices regarding configuration tuning, determining bottlenecks, security, etc.
I presently host around 400 sites, with a fair need for redundany and security, and so I've grown beyond the single-box solution - but am not at the level of a full ISP or dedicated web-hosting company.
Can anyone point me in the direction of some good expertise on setting up a great apache web-farm with a view to security and future expansion?
My web environment consists of 2 redundant MySQL servers, 2 redundant web-content servers, 2 load balancing front-end apache servers that mount the content via nfs and share apache config and sessions directories between them, and a single "developer's" server which also mounts the web-content via nfs, and contains all the developer accounts.
I'm pretty happy with alot of this setup, but it seems to be choking on the load prematurely.
Thanks!!
--UPDATE--
Turns out the "choking on the load" is related to mod_log_sql, which I use to send my apache logs to a mysql database. By re-configuring the webservers to write their sql statements to a disk file, and then creating a separate process to submit those to the database it allows the webservers to free up their threads much quicker, and handle a much greater load.
You need to be able to identify bottlenecks and test improvements.
To identify bottlenecks, you need to use your system's reporting tools. Some examples:
MySQL has a slow query log.
Linux provides stats like load average, iostat, vmstat, netstat, etc.
Apache has the access log and the server-status page.
Programming languages have profilers, like Pear Benchmark.
Use these tools to identifyy the slowest/biggest offenders and concentrate on them. Try an improvement and measure to see if it actually improves performance.
This becomes a never ending loop for two reasons: there's always something in a complex system that can be faster and as your system grows, different functions will start slowing down.
Based on the description of your system, my first hunch would be disk io and network io on the NFS servers, then I'd look at MySQL query times. I'd also check the performance of the shared sessions.
The schoolbook way of doing it would be to identify the bottlenecks with real empirical data.
Is it the database, apache, network, cpu, memory,io? Do you need more ram, sharding(+), is the DiskIO, the NFS network load, cpu for doing full table scans?
When you find out where the problem is you might run into the problem that its not enough to scale the infrastructure, because of the way the code works, and you end up with the need to either just create more instances of you current setup or make the code different.
I would also recommend as a first step in terms of scalability, off-load your content to a CDN like Edgecast. Use your current two content servers as additional web servers.