10 ms·

I've been running a web application for the past 6 months and it just crossed 150,000 page views/month mark. Sure, for others it's not that great, but for me, t

I've been running a web application for the past 6 months and it just crossed 150,000 page views/month mark. Sure, for others it's not that great, but for me, this is the project that is showing the biggest potential. Anyway, the funny thing is, I'm running it on $2.50/month Vultr VPS. I got so worried when it crossed 30,000 that my site will crash. But it didn't. Then when its views got higher, I optimized further. I learned more things about how to make things faster. I refactored my code to squeeze out that much more juice out of $2.50 - not because I'm cheap (well, perhaps), but because I wanted to see how far I can push it. I'll probably cross 200,000 soon and I think by then I'll need to increase it to (yikes heaven forbid!) $5/month plan. Recently, just because of all the hype about AWS (in general and also at my work) I wanted to get started with AWS. Then I looked at their ridiculous pricing calculation page and I just closed the browser. I thought my time was better spent working on my project than learning about how to deploy a simple PHP application to AWS.

empath75 9y ago
150,000 views a month is like a hit every two seconds. That's nothing. Talk to me when you're managing 150000 hits a second. Edit: sorry didn't mean to imply that your site isn't successful, only that in terms of traffic, it doesn't make aws worth it.
- jazoom 9y ago
  I don't understand the point of your comment. The parent was simply explaining why they don't need extreme scalability with their scenario. No one is under the impression that multiplying their traffic by 75000 (so you work at Google then?) will not require a big server upgrade.
  - empath75 9y ago
    He's making a judgement on the value of aws using a use case that makes no sense to use aws, anyway. He could be doing something similar with lightsail on aws at similar cost if he really wanted to, though.
    - mysterydip 9y ago
      I thought that was the point chx was making, with sideproject giving an example. How many people really do 150,000 hits a second versus how many are using AWS?
    - problems 9y ago
      > He's making a judgement on the value of aws using a use case that makes no sense to use aws, I think the problem here is that a lot of people use AWS when there's no value in using AWS. It's commonly reached for as a first choice when it's often not a good option if you're looking to run lean. AWS is extremely popular, but probably only efficient for a small percent of companies who have wildly variable traffic patterns.
      - eropple 9y ago
        Your idea of "running lean" optimizes for the operational expenses of servers, which are across-the-board cheap, rather than cost of developer time. I bill between $200 and $250 an hour. (If I had a full-time job I'd be salaried around $90-$100/hour.) Being able to pay me less because AWS's tooling makes life a hell of a lot easier once set up makes a lot of sense even for fairly small companies.
        problems 9y ago
        AWS tooling doesn't save developer time in my experience. In fact, I'd argue that optimizing for it more often than not wastes it. I've watched someone spend days learning to configure a performant DB server on AWS due to their poor disk IO performance and spend an enormous amount to get a high ram instance when a simple SSD based server where more IOPS were trivially available would have had it working out of the box. Everything has a learning cost though, so perhaps that's a somewhat unfair example as having a deep knowledge of data centers and backbone providers doesn't come free, but I can crank an ansible and docker script out and have pretty much all the advantages of AWS but deployed on my own hardware at a fraction of the cost. So I'm not sure it's fair to say that AWS tooling offers anything particularly unique to merits its market position.
- geofft 9y ago
  How many projects actually get 150,000 hits a second? (And are they not better served by buying and operating their own datacenters?)
  - neuronexmachina 9y ago
    How many hits/second does a project have to serve when they're on the front page of HN?
    - ericd 9y ago
      I don't remember exactly, but not that many, maybe a couple thousand concurrent users. My brother's webapp has hit the front page of Reddit a few times, but a single dedicated machine was more than enough to handle that.
    - Deimorz 9y ago
      Shouldn't be anything incredibly high. I haven't seen any recent traffic info for HN, but a couple of years ago dang posted some numbers here: https://news.ycombinator.com/item?id=9219581 https://news.ycombinator.com/item?id=9219581 So at that point it was 2.6M views per day, which means HN itself was getting about 30 views per second. If you look at the 200k uniques instead (which might make more sense since any individual person will probably only click through once), that's about 2 unique visitors per second. So even if HN has grown a ton in the time since that post, I'd be surprised if it sent more than about 5 hits/second to anything.
      - geofft 9y ago
        Hah, the fact that HN itself is a single server (behind Cloudflare, these days) should be enough proof that anything linked to by HN is unlikely to need more than a single server behind a caching CDN.
    - geofft 9y ago
      Well, let's also differentiate computationally-intensive hits (e.g., users adding things to a shopping cart, requests to list Pokemon in the area, etc.) from hits to a home page, which should be static or at least cached aggressively. 150,000 index.htmls per second and 150,000 database writes per second are very different. I used to run a university web hosting platform that currently has, I think, five web server VMs on about as many physical machines, two physical machines for load balancing, and two physical MySQL servers in active/passive replication (i.e., only one gets either reads or writes). We hit the front page of HN fairly frequently—for instance, we host mosh.org—and it hasn't really been a problem. I remember getting paged in ... 2009 or so? ... when a particular website in WordPress got to the front page of Reddit, but we had fewer machines then, and also I think we had not deployed FastCGI for PHP at that point (for complicated shared-hosting reasons), so each WordPress page load was its own PHP process via CGI. If you're optimizing for performance, even if you want to stay on WordPress, step one is to not use plain CGI and step two is to do one of the myriad things you're supposed to do for WordPress caching. In any case, a handful of physical machines will handle being on the front page of HN just fine. If you're doing something where you have an extremely computationally-intensive process on the first page load and you're worried you might hit HN but you might not, put it on cloud and set up autoscaling, but other than that it probably doesn't make sense. If you know you won't scale too much—and a static site on the front page of HN isn't too much—chances are that your usage is so low that you're paying a premium for the unused ability to scale and you should just pay for two cheap VPSes, and if you know you will scale (e.g., you have a large fixed workload), again you're paying a premium for the unused ability to scale down, and you should just invest in a datacenter and save in the long term. All that said, if you've got a static site, by all means stick it on a CDN, which I think is a perfectly defensible use of cloud for sites of all sizes.
- EGreg 9y ago
  What are these "hits"? Why not have a CDN serve static pages? Or better yet, an app on a mobile phone? Then the hits are just APIs.
- forgot-my-pw 9y ago
  Guess most of us should never talk to you. Oh well, nothing of value was lost.
- susam 9y ago
  A hit every two seconds is 30 * (86400 / 2) = 1296000 hits per month. 150000 hits per month is an average of a hit every 86400 * 30 / 150000 = 17.28 seconds. Yes, that's nothing. With a hit every 17 seconds, there is no performance optimization to be done. Therefore I don't understand the concern about performance in the parent comment by 'sideproject'. Sure, there could be peak times when there is a hit every 100 microseconds and that's what forced the parent commenter to focus on performance optimization but nothing about this was mentioned in the comment. Details about traffic in such peak times would have made the parent comment by 'sideproject' interesting. But with the current details in the comment right now, it is going to leave readers confused why one needs to discuss performance optimization for a hit every 17 seconds on average.
AYBABTME 9y ago
Not sure what your website is doing, but here's a quick thought exercise: If you serve a page in 10s, then you can serve 259'200 pages/month. render_time page_view/month 10s 259'200 9s 288,000 8s 324,000 7s 370,285 6s 432,000 5s 518,400 4s 648,000 3s 864,000 2s 1,296,000 1s 2,592,000 So like, think 1 million views per month with 2s render time. This is obviously skipping over a ton of details, but it's a good rule of thumb.
- tgtweak 9y ago
  Website traffic can be vary heavily during some parts of the day depending on demographics. It's good practice, unless you know that traffic profile, to inflate by 2-3x your average page views per second over any time period larger than an hour. In addition to this, one pageview may produce many requests. Both of these need to be profiled before you can estimate reasonably how much traffic a webserver can handle given it's current resources. There are some good benchmarking tools that will load the entire page, including all it's resources, and produce a more accurate load measure in terms of r/s. As a side note, those $5 vultr instances can handle a surprising amount of static requests per second using nginx.
- deleted 9y ago
  [deleted]
sockgrant 9y ago
150,000 views a month is 150000/30/24/60/60 = 0.0578 qps. If there's no heavy processing you shouldn't need to be doing any optimization for the machine's sake at that rate. Slow queries / frontend code is a different story :)
- flippant 9y ago
  The traffic likely peaks at certain hours
staticassertion 9y ago
This is all fine for a personal project. The amount that the time you spent optimizing would cost a company is very likely to outweight the cost of scaling hardware.

empath75 9y ago

150,000 views a month is like a hit every two seconds. That's nothing. Talk to me when you're managing 150000 hits a second. Edit: sorry didn't mean to imply that your site isn't successful, only that in terms of traffic, it doesn't make aws worth it.

jazoom 9y ago
I don't understand the point of your comment. The parent was simply explaining why they don't need extreme scalability with their scenario. No one is under the impression that multiplying their traffic by 75000 (so you work at Google then?) will not require a big server upgrade.
- empath75 9y ago
  He's making a judgement on the value of aws using a use case that makes no sense to use aws, anyway. He could be doing something similar with lightsail on aws at similar cost if he really wanted to, though.
  - mysterydip 9y ago
    I thought that was the point chx was making, with sideproject giving an example. How many people really do 150,000 hits a second versus how many are using AWS?
  - problems 9y ago
    > He's making a judgement on the value of aws using a use case that makes no sense to use aws, I think the problem here is that a lot of people use AWS when there's no value in using AWS. It's commonly reached for as a first choice when it's often not a good option if you're looking to run lean. AWS is extremely popular, but probably only efficient for a small percent of companies who have wildly variable traffic patterns.
    - eropple 9y ago
      Your idea of "running lean" optimizes for the operational expenses of servers, which are across-the-board cheap, rather than cost of developer time. I bill between $200 and $250 an hour. (If I had a full-time job I'd be salaried around $90-$100/hour.) Being able to pay me less because AWS's tooling makes life a hell of a lot easier once set up makes a lot of sense even for fairly small companies.
      - problems 9y ago
        AWS tooling doesn't save developer time in my experience. In fact, I'd argue that optimizing for it more often than not wastes it. I've watched someone spend days learning to configure a performant DB server on AWS due to their poor disk IO performance and spend an enormous amount to get a high ram instance when a simple SSD based server where more IOPS were trivially available would have had it working out of the box. Everything has a learning cost though, so perhaps that's a somewhat unfair example as having a deep knowledge of data centers and backbone providers doesn't come free, but I can crank an ansible and docker script out and have pretty much all the advantages of AWS but deployed on my own hardware at a fraction of the cost. So I'm not sure it's fair to say that AWS tooling offers anything particularly unique to merits its market position.
geofft 9y ago
How many projects actually get 150,000 hits a second? (And are they not better served by buying and operating their own datacenters?)
- neuronexmachina 9y ago
  How many hits/second does a project have to serve when they're on the front page of HN?
  - ericd 9y ago
    I don't remember exactly, but not that many, maybe a couple thousand concurrent users. My brother's webapp has hit the front page of Reddit a few times, but a single dedicated machine was more than enough to handle that.
  - Deimorz 9y ago
    Shouldn't be anything incredibly high. I haven't seen any recent traffic info for HN, but a couple of years ago dang posted some numbers here: https://news.ycombinator.com/item?id=9219581 https://news.ycombinator.com/item?id=9219581 So at that point it was 2.6M views per day, which means HN itself was getting about 30 views per second. If you look at the 200k uniques instead (which might make more sense since any individual person will probably only click through once), that's about 2 unique visitors per second. So even if HN has grown a ton in the time since that post, I'd be surprised if it sent more than about 5 hits/second to anything.
    - geofft 9y ago
      Hah, the fact that HN itself is a single server (behind Cloudflare, these days) should be enough proof that anything linked to by HN is unlikely to need more than a single server behind a caching CDN.
  - geofft 9y ago
    Well, let's also differentiate computationally-intensive hits (e.g., users adding things to a shopping cart, requests to list Pokemon in the area, etc.) from hits to a home page, which should be static or at least cached aggressively. 150,000 index.htmls per second and 150,000 database writes per second are very different. I used to run a university web hosting platform that currently has, I think, five web server VMs on about as many physical machines, two physical machines for load balancing, and two physical MySQL servers in active/passive replication (i.e., only one gets either reads or writes). We hit the front page of HN fairly frequently—for instance, we host mosh.org—and it hasn't really been a problem. I remember getting paged in ... 2009 or so? ... when a particular website in WordPress got to the front page of Reddit, but we had fewer machines then, and also I think we had not deployed FastCGI for PHP at that point (for complicated shared-hosting reasons), so each WordPress page load was its own PHP process via CGI. If you're optimizing for performance, even if you want to stay on WordPress, step one is to not use plain CGI and step two is to do one of the myriad things you're supposed to do for WordPress caching. In any case, a handful of physical machines will handle being on the front page of HN just fine. If you're doing something where you have an extremely computationally-intensive process on the first page load and you're worried you might hit HN but you might not, put it on cloud and set up autoscaling, but other than that it probably doesn't make sense. If you know you won't scale too much—and a static site on the front page of HN isn't too much—chances are that your usage is so low that you're paying a premium for the unused ability to scale and you should just pay for two cheap VPSes, and if you know you will scale (e.g., you have a large fixed workload), again you're paying a premium for the unused ability to scale down, and you should just invest in a datacenter and save in the long term. All that said, if you've got a static site, by all means stick it on a CDN, which I think is a perfectly defensible use of cloud for sites of all sizes.
EGreg 9y ago
What are these "hits"? Why not have a CDN serve static pages? Or better yet, an app on a mobile phone? Then the hits are just APIs.
forgot-my-pw 9y ago
Guess most of us should never talk to you. Oh well, nothing of value was lost.
susam 9y ago
A hit every two seconds is 30 * (86400 / 2) = 1296000 hits per month. 150000 hits per month is an average of a hit every 86400 * 30 / 150000 = 17.28 seconds. Yes, that's nothing. With a hit every 17 seconds, there is no performance optimization to be done. Therefore I don't understand the concern about performance in the parent comment by 'sideproject'. Sure, there could be peak times when there is a hit every 100 microseconds and that's what forced the parent commenter to focus on performance optimization but nothing about this was mentioned in the comment. Details about traffic in such peak times would have made the parent comment by 'sideproject' interesting. But with the current details in the comment right now, it is going to leave readers confused why one needs to discuss performance optimization for a hit every 17 seconds on average.

AYBABTME 9y ago

Not sure what your website is doing, but here's a quick thought exercise: If you serve a page in 10s, then you can serve 259'200 pages/month. render_time page_view/month 10s 259'200 9s 288,000 8s 324,000 7s 370,285 6s 432,000 5s 518,400 4s 648,000 3s 864,000 2s 1,296,000 1s 2,592,000 So like, think 1 million views per month with 2s render time. This is obviously skipping over a ton of details, but it's a good rule of thumb.

tgtweak 9y ago
Website traffic can be vary heavily during some parts of the day depending on demographics. It's good practice, unless you know that traffic profile, to inflate by 2-3x your average page views per second over any time period larger than an hour. In addition to this, one pageview may produce many requests. Both of these need to be profiled before you can estimate reasonably how much traffic a webserver can handle given it's current resources. There are some good benchmarking tools that will load the entire page, including all it's resources, and produce a more accurate load measure in terms of r/s. As a side note, those $5 vultr instances can handle a surprising amount of static requests per second using nginx.
deleted 9y ago
[deleted]

sockgrant 9y ago

150,000 views a month is 150000/30/24/60/60 = 0.0578 qps. If there's no heavy processing you shouldn't need to be doing any optimization for the machine's sake at that rate. Slow queries / frontend code is a different story :)

flippant 9y ago
The traffic likely peaks at certain hours

staticassertion 9y ago

This is all fine for a personal project. The amount that the time you spent optimizing would cost a company is very likely to outweight the cost of scaling hardware.