12:25:15 GMT <stan_man_can_> Anyone around right now?
12:25:58 GMT <stan_man_can_> Not the best sysadmin but I have to scale one of my sites a bit
12:26:10 GMT <stan_man_can_> right now it's a single server running php/mysql/redis
12:26:15 GMT <stan_man_can_> i can drop the mysql portion of the server
12:26:25 GMT <stan_man_can_> but need some more application servers; it's a super simple API
12:26:40 GMT <stan_man_can_> once a day i run a cron job that populates redis with the data, then the API accepts a query string
12:26:48 GMT <stan_man_can_> i look that string up in redis and return the value if ones found
12:27:13 GMT <stan_man_can_> it gets like 30million requests a month and my single vps is having issues so i want to scale it to multiple application servers behind a load balancer
12:27:34 GMT <stan_man_can_> i don't need anything fancy since there's no sessions or whatever
12:27:45 GMT <stan_man_can_> what i'm thinking is 3 webservers all running php/redis
12:28:24 GMT <stan_man_can_> i was thinking if there's a way to cluster redis so each server has the full keyset and they can just query themselves
12:28:32 GMT <stan_man_can_> so each machine will connect to redis locally
12:28:48 GMT <stan_man_can_> i mean, i guess i can just set each one up to update it's own database
12:28:55 GMT <stan_man_can_> and not worry about clustering
12:29:00 GMT <stan_man_can_> hm
12:29:06 GMT <stan_man_can_> oh, but i do want it to cluster since
12:29:10 GMT <stan_man_can_> i log activity in redis
16:42:09 GMT <xiaomiao> stan_man_can_: don't use a crappy vps then
17:18:22 GMT <minus> yeah, rather than scaling it just go with a larger server unless you're expecting continuous growth. it's not worth adding the complexity if it's not necessary
18:30:57 GMT <xep> heh room topic is out of date
18:31:00 GMT <xep> 3.2.3 is out :)
18:40:25 GMT <stan_man_can_> xiaomiao, what's considered a crappy vps?
18:40:47 GMT <stan_man_can_> minus, not a super good sysadmin but i'm running out of filedescriptors i think?
18:41:25 GMT <minus> stan_man_can_: are you not closing connections?
18:41:35 GMT <minus> anyway, you can increase the fd limit
18:42:03 GMT <xiaomiao> stan_man_can_: 1M req/day is just around 10/sec
18:42:22 GMT <xiaomiao> that should not be a performance problem
18:42:56 GMT <xiaomiao> stan_man_can_: depends a bit on your requirements, but I usually avoid vps because price/performance isn't that good (imo)
18:43:05 GMT <xep> 10/sec isn't much
18:43:10 GMT <stan_man_can_> one sec
18:43:21 GMT <stan_man_can_> running a query to see growth over the last 36 months
18:43:54 GMT <stan_man_can_> so i made this API for free like 5 years ago and then sometime in the last 3 years it started getting used and it's been steadily growing ever since
18:44:30 GMT <stan_man_can_> i'm just an average web developer with super basic sysadmin stuff so i'm a bit out of my league but want to keep it running
18:44:31 GMT <xep> yeah, I can't say I have experience running Redis on a VM either. All my Redis build-outs so far have involved beefy dedicated hardware. My requirements are thousands of queries per second with <1ms latency
18:44:43 GMT <stan_man_can_> ah
18:45:48 GMT <xep> you can see how many fds are open
18:45:50 GMT <xep> lsof | wc -l
18:47:16 GMT <xep> what minus said -- it's best if you can avoid opening+closing connections constantly. if you're trying to use Redis with short-running processes as one would with PHP, you might consider running something to handle the connection pooling for you
18:47:20 GMT <stan_man_can_> says 902 right now
18:47:24 GMT <xep> well that's not much
18:47:30 GMT <stan_man_can_> no but
18:47:32 GMT <stan_man_can_> it bursts
18:47:35 GMT <minus> 1024 us the default limit afaik
18:47:42 GMT <minus> s/us/is
18:47:49 GMT <xep> ah ... oh, yeah, 1024 .. I was off an order of magnitude thinking about the default
18:47:53 GMT <minus> `ulimit` shows the limit
18:48:06 GMT <stan_man_can_> ulimit says unlimited ?
18:48:08 GMT <xep> we use a fork of twemproxy that has Sentinel failover support
18:48:18 GMT <minus> oh, might be different on the shell
18:48:21 GMT <xep> handles all our pooling
18:48:45 GMT <stan_man_can_> okay so just as a frame of reference
18:49:11 GMT <stan_man_can_> Oct 2015 it did 95m requests
18:49:37 GMT <stan_man_can_> it's been steadily increasing and last month did 33.6 million
18:49:45 GMT <stan_man_can_> sorry, oct 2015 was 9.5 million***
18:49:57 GMT <stan_man_can_> last month was 33.6
18:50:11 GMT <stan_man_can_> this month is already at 3.5m
18:51:10 GMT <stan_man_can_> but yeah the issue is that it's not super stead throughout the day, if it was 10req/s constant that wouldn't be an issue, but somehours might be 150+ req/s while some are 1-2
18:52:04 GMT <stan_man_can_> i started getting "Bad Gateway" for 1-2 minutes a week about a month ago
18:52:12 GMT <stan_man_can_> but lately it's been happening 3-4 times a day for 3-4 minutes
18:52:29 GMT <stan_man_can_> logs just seem to be that out of file descriptor things
18:52:38 GMT <stan_man_can_> (sorry just giving you guys a bit of history)
18:52:39 GMT <minus> make sure you either close your redis connections in your application code or use a pool
18:52:55 GMT <stan_man_can_> minus, does redis us a lot of file descriptors?
18:52:57 GMT <minus> because it sure sounds like you're not closing them to run into the limit with just 10req/s
18:53:07 GMT <minus> redis itself uses a handful
18:53:16 GMT <minus> but each connection is a fd
18:53:59 GMT <stan_man_can_> minus, in php i just to $redis->open() then do my selects and icnrements and then just exit out of the php script
18:54:59 GMT <minus> maybe try to $redis->close() at the end??
18:55:05 GMT <stan_man_can_> hm
18:55:05 GMT <stan_man_can_> ok
18:55:08 GMT <minus> s/??/?/
18:55:45 GMT <stan_man_can_> my naive solution was to just run the API on a couple VPS's behind a load balancer
18:55:48 GMT <minus> not sure if PHP (esp. with FPM) automatically frees such stuff
18:57:57 GMT <stan_man_can_> the whole API is stupid simple, someone literally sends a get/post request with a string, then i $return = $redis->get($string); if($return) { return $return } else { header("Status: 404 Not Found"); }
18:58:43 GMT <stan_man_can_> i mean there's a couple other things in there, use redis to log a few stats too, so there's a couple $redis->incr() in there, but that's it
18:59:03 GMT <minus> can't say i miss writing PHP :D
19:00:41 GMT <stan_man_can_> i've been thinking about if there's a better way to write it
19:01:00 GMT <stan_man_can_> i'm no genius but it seems like it should be easy enough to handle without running PHP or something
19:01:37 GMT <stan_man_can_> i haven't any experience writing my own webserver or something though
19:02:17 GMT <stan_man_can_> but it seems like accepting a get/post parameter, querying redis, and returning a string shouldn't be super difficult on something a bit more native ?
19:03:13 GMT <minus> yeah, that should work well even in C(++)/Rust/Go/etc
19:05:22 GMT <stan_man_can_> yeah
19:05:29 GMT <stan_man_can_> if i was going to pick one, what would you suggest?
19:05:41 GMT <stan_man_can_> get more performance out of a single machine
19:13:18 GMT <minus> not much difference between those and it probably doesn't really matter
19:18:17 GMT <stan_man_can_> either one easier to pick up?
19:18:31 GMT <stan_man_can_> googling around seems to say that GO has a bigger/better community around it? might be helpful when learning..
19:23:08 GMT <minus> if you don't know any Go is probably the easiest
19:23:14 GMT <minus> Rust is definitely the hardest
19:27:29 GMT <stan_man_can_> Go it is