Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I had a small Japanese oriented url shortening service. It got shut down because it used too much resources (CPU time and maybe memory) on a shared server. This was a couple of years back but I am interested in bringing back to life if I can afford to.

I am planning on using this time, and was wondering if the smallest VPS from say linode would be able to handle the work load. Most of the work is just mod_rewrites.

It is ok if the site becomes slow, but not unbearably so. If there is interest in the project then I could upgrade the VPS. But am I correct in assuming that even if the VPS gets swamped it won't get shut down because of affecting the performance of other users?

share|improve this question
You really need to give an indication on the expected load. i.e. How many calls per second/minute/hour/day do you expect to be made? The requirements for a system handling a million calls per minute is obviously quite different to one that will only get called on a couple of times a day. I realise this won't be easy to answer but without that information your question is pretty much unanswerable. – John Gardeniers Oct 2 '09 at 5:46
the last version of the site got hit pretty hard by Chinese forum users at a rate of 1 million redirects per day. I'm hoping that the blacklist features of tighturl would prevent things like that (spammers too). so I reckon about 150,000 redirects per day to start off with. – blndcat Oct 2 '09 at 6:07
is it true that tighturl hasn't been updated in >1 year? interesting – warren Oct 5 '09 at 6:39
up vote 1 down vote accepted

No, Linode won't shut you down for using resources. They will simply limit your CPU to your percentage. If nobody else is using their CPU, you can use theirs too, until their VPS requests it, so chances are, you will almost always get more than your share. You can max out RAM and CPU all day long, and if your site gets slow, just upgrade the linode.

The only thing they are particular about is HD access, since that could affect others, but that doesn't seem to apply in your situation.

I highly recommend linode.

share|improve this answer

It really depends on how you write the site. I can see a VPS becoming swamped. If your VPS uses more resources than allocated it may get shut off. The more lightweight and speedy your service (perhaps a custom fastcgi C++ backend) the better off it'll be.

share|improve this answer
>it may get shut off. I thought the whole thing about VPSes is that you get allocated a certain amount of resources and even if you max it out, it wouldn't affect others and so you wouldn't get shut off? – blndcat Oct 2 '09 at 6:09
yeah - you can't get a VPS shutoff if you exceed resources - it'd be like getting a physical server shutoff because it ran out of memory – warren Oct 2 '09 at 6:16
Not entirely what I meant. If you're constantly hitting soft limits they may ask you to upgrade to a bigger VPS or shut it off. – Xorlev Oct 2 '09 at 6:57
@Xorlev - weird.. who do you use for a provider? Mine is hard-capped at X-many MB RAM and Y-much CPU – warren Oct 5 '09 at 6:41
@Xorlev Depending on the underlying VPS architecture hard/soft limits are easier to enforce and setup. Xen is based on hard limits where as the usually cheaper OpenVZ are base on more flexible limits. Also, disk I/O on VPS systems can get you in trouble with your provider. – jemmille Nov 16 '09 at 4:10

How do you plan to implement it?

How long do the URLs stay active?

If you're killing them after X-many days/months/whatever, and you're only getting a few hundred thousand requests a day, I'd anticipate an entry-level VPS from anywhere would handle it.

I'd be most concerned about bandwidth usage, personally. I'd prefer an "unmetered" but speed-capped service to a really fast but "metered" connection - costs are easier to predict :)

If it's a really simple implementation, say the shortened item is looked-up in a db, and you return a redirect to the original URL - it's probably not going to use a lot of CPU or RAM - your only issue should really be storage. If the average URL+shortID is, say, 1KB, and you have a million URLs, you're looking at 1GB of storage already. Extend your storage by 1GB for each million URLs, and an entry-level VPS from the hosting provider I use ( is going to cap-out at ~18million records.

share|improve this answer
Thanks for taking the time to answer. As I mentioned in the original question, I am planning to implement it using tighturl. The urls would stay active indefinitely. FWIW, and it may interest you, bandwidth is not a problem. The bandwidth used in the original site (a million hits per day) was under 400MB per month. That's probably because it wasn't serving up pages but just rewriting/redirecting. OTOH Memory and CPU usage were cited as problems by the previous provider. – blndcat Oct 5 '09 at 3:28
@blndcat - I did see you were planning to use an existing package, just wanted to make sure all the bases were/are covered :) ..that being said, if your webserver (apache, lighttpd, nginx, whatever) is merely doing rewrites/lookups from a db table, CPU and memory usage shouldn't be too bad, I would expect. Of course, the best way to find out would be to try it :) ..If you aren't sure about resource needs, look at a plan that'll let you add CPU/RAM easily – warren Oct 5 '09 at 6:36

Tinyurl url compression site. optimization for better performance on VPS

Many VPS'es come with lower CPU and slower paged memory resources compared to what u can get in dedicated solution. Even HDD space can be costly. However u can try to make better C++ or even perl etc any application that uses fair algorithm for the purpose.

U can consider better optimization of algorithm of ur program, rather just try to get more costly platform or just rewrite algorithm in faster language (former and later helps to some extent however).

Some ideas u can consider is aging of all low hit records and some oldest records. U can get hit counter stored in database, however its not recommended for storing there dates, rather just delete all matching records in current database with several old months snapshot (you will not need to store dates this way, just delete all matching records that was in old snapshot and that have low hit ratio). Additionally u can separate old data and store it in highly compressed form "archive" - like using prefix for time of storage etc. U can just null old records thus preserving ids and migrate them to second "offline" db to streamline queries.

Also consider changing hashing algorithm however it present some challenges (like looking for better way to compress strings or store most frequent URLs or its parts in some fast prefix table giving "super" ids). practically u can make challenge (like wikipedia do with its 100mb random text) or question here ;-) or make ur own research or even leave as is as it will work anyway p;


share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.