webvet

I believe Junko Tabei - the first woman climber of Mt. Everest - did it (i.e. climb Mt. Everest) at the age of 36.

http://en.wikipedia.org/wiki/Junko_Tabei

All the best. :)

Not exactly a freelancer; more like a small web development company.

Will build a few web MVPs (fast and) for free if there are any suitable and willing takers here on HN forums.

Check out the URL below for further information:

http://httpd.co/damn_quick_mvps/

Just submitted one here - fairly quick and easy :)

Clickable link:

http://httpd.co/damn_quick_mvps/

Nice - posted one of ours.

Bug report/suggestions:

1) Can't find a way to edit our project listing

2) Consider more rigorous client-side validation on submission form (e.g. I accidentally entered a non-numeric character in the Price field - this error was reported only after I hit Submit. Would've been easier if this were reported on tabbing/clicking out of the field)

3) Upon erroneous submission, at least the 'How is your project built?' field got cleared

Also, you might want to consider an 'auto screenshot capture/display' feature once a user types in the URL. We are very shortly going to publish a (free) API to do this - we'd be glad to help if needed, let me know.

A great site/service on the whole - thanks.

Thanks to all who have responded.

We've decided to try each one-

DigitalOcean - already ordered, up and running (very well too)

Linode - will order soon

OVH - already ordered (per my comment below), now trying to figure out a way to pay them

@AznHisoka: Thanks for the reminder. Are you associated with/use them?

After you told me about them in my previous thread, we checked them out and actually ordered a server there. Turns out the only payment option they have is PayPal. We tried to make cc payment via paypal but they would make just a test transaction (successfully) and then say, can't process. We tried four times, with the same results. OVH support wasn't much help, except saying PayPal is the only available option now.

In the meanwhile, we found this:

http://www.webhostingtalk.com/showthread.php?t=672553

and this:

http://www.majidkhosravi.com/ovh-review/

I wonder what this is all about.

After you found out about this, did you find his page in your Likes list?

If you did, could it have been that you somehow - inadvertently - clicked Like on his page/ad?

If your answers are yes and no respectively, I'd say this is profound indeed!!

Clickable previous thread links:

1. https://news.ycombinator.com/item?id=6348903

2. https://news.ycombinator.com/item?id=6367198

> 3) it's not a fear, a critical mass of users won't pay for content.

Spot on!!

As an aside, pitcher.io looks cool... congrats :)

If you don't mind, I'd suggest toning down the 'Our' side of the copy a bit... e.g. 'Our amazing content. Your expert knowledge.' sounds too boastful (no offense) and might sound better with 'great' instead of 'amazing'...

Also: 'To start you off every Pitcher account comes loaded with content we love' might be better as 'To start you off every Pitcher account comes loaded with great/useful content' ...

HTH and all the best.

Wow!!! Didn't know about this - took a quick look and found it very interesting. Thanks.

We've suspected that our problem is mainly of I/O, very close to what you've described above.

>I would just post the output from top and iostat during one of the spikes here and see what people say rather than hiring an expensive consultant.

Thanks for the suggestion. Will try and do just that soon.

What I meant was feature development... that's what got frozen long ago... code revision exclusively for performance optimization has been ongoing continually.

>I can't really see how your code or queries could cause mysql or apache to gradually slow down and then speed up...

Actually, we've ascertained that it is not the code or queries that cause this per se, but it is the traffic patterns - human visitors + SE crawlers... at times, there are (natural) traffic bursts and that's when the server starts choking.

apache/mysql - stock distros, with some config tweaks, mainly in my.cnf.

>what happens if you just kill one or the other?

Good call. Actually, restarting just apache does the trick most of the times. What we suspect is, abrupt flooding in http requests causes MySQL to slow down which causes http requests to get queued up and finally choke the service.

Yes, we did investigate MySQL's internal partitioning option briefly before deciding to roll our own scheme (which, after working quite well initially, is now beginning to create problems of its own).

Perhaps, it is time for us to revisit this. Thanks again Paul.

Will try and post within a few hours. Thanks.

For now, we're making our code/queries/optimization take the blame rather than the hardware.

>so call in some help.

As is being discussed in the other thread.

Paying way more than $10/mo for the VPS, close to 200 - and hey!! thanks for the ovh.com link - looks very interesting, will certainly try them out soon. Thanks.

>What is the actual bottleneck?

As mentioned in OP, it is MySQL.

>you can't run a massive database on crappy hardware and expect it to work smoothly.

Absolutely... but we do wish to milk the VPS for every cent of its worth and we're not sure we've got there yet.

Thanks for your input.

Thanks for your in-depth reply and suggestions.

MySQL performance tuning and table structure/query optimization-wise, we've left few stones unturned (but I'm sure there still is a scope for further improvement - isn't there always?).

Not using Rails.

Server specs: 4 cores, 3.2GB RAM

>and the easiest route is just to upgrade your server.

Please refer to the other thread for more on this.

Thanks again.

Yes, as mentioned in the other thread, we're way ahead of this - but thanks for your input all the same.

>You need to examine the restart process and analyze

Like I said in OP, we've identified MySQL to be the primary bottleneck and are already working on resolving this.

>whose transactions are abandoned.

At least some saving grace here... we're not selling anything... it is purely a content site

Thanks for your input.

We are actually more than worried too, because we _know_ we're losing plenty of requests daily so trying to cut down the losses temporarily while we figure out a more long-term solution.

For the rest, this thread might give you some more info on the issue: https://news.ycombinator.com/item?id=6348903

Good call - thanks :)

>Do you really need all that data in real time? Are you querying all of it in your app?

Yes and yes. ALL the data records could potentially be queried via site navigation.

Cool !! Is it robots.txt compliant? If not, it might be a good idea to make this available as an option/parameter.

For 'quick and dirty' tasks, wget -r can come in handy too.

Thanks. We'll check out TokuDB.

Regardless of your English syntax (rusty or not), what would you define as 'huge' for a MySQL app?