I have a few different sized vcsims, PM me if you want to use one
Thanks
But the striking thing about the go simulator is that it seems to be part of a rewrite of the engine and isn’t just some bogus simulator.
The cvs I’m is a real environment but is just so big
Ugh. The vcsim is bloated but uses the real code, which is good. Think it is deprecated
I need to try out the go one again. It had so much promise and good VMware backing
so if you just want to see "what does 1000 vms look like" I'm sure govcsim is fine, if you want to see how your code will work on a real vcenter with 1000 vms I don't thing govcsim will do that
it sounded like the go simulator was possibly a front end for some future vcenter work - wonder if they are thinking about doing a major revamp - at least of the soap front end. Which makes sense. Quite a few vendors rewrite the web service layer in go. well in the ruby world at least.
ruby 2.6.6 on catalina if that matters
cc @gtanzillo @jrafanie @bdunne maybe this is part of why we see things are "slow" on boot in docker
I believe that the cost of two syscalls (open(2) only after successful access(2)) would, in our case, at least because we would shave-off something like 1,900,000×90µsec (2.85 minutes) from the three minute boot time for our application.
and we fall in that bucket of "huge application with a lot of load paths"
also it seems zeitwerk helps a lot because it avoids that file search that require does
Twitter threads are hard to follow haha
I was able to get the gist much easier by reading from here down: https://github.com/docker/roadmap/issues/7#issuecomment-757710368
@kbrock thought you might find this interesting https://twitter.com/josh_cheek/status/1361472100012347395?s=19
NickLaMuro @NickLaMuro is trying to figure out if that is executing the loop once... or every time the query is executed... (me thinks the latter)
i think the storage is just parent_id
I find array_arg and a couple of the "group by" type array creation queries confusing
understandable, but it requires a little extra groking for me
understandable, but it requires a little extra groking for me
whoa, I totally missed this: https://jemma.dev/blog/irb-measure /via ruby weekly 1/21
ruby 3.0 has measure :stackprof or timing for built in metrics.
I have longed thought that it SHOULD BE, but this might be one of those scenarios where Aaron added that as a default measurement, but didn't included it with the ruby lang by default
Yeah, looks like it isn't:
https://github.com/ruby/ruby/blob/v3_0_0/lib/irb/init.rb#L123-L141
Remember tech empower benchmark talking about db drivers in some programming languages multi-plexiglass requests or something. Still trying to track down.
BUT I did stumble upon pgbouncer (reminds me of dbslayer from NYtimes 10+ yes ago?) wish rails did not have so many begin/end transactions and were statement centric but I digress. https://www.percona.com/blog/2018/06/27/scaling-postgresql-with-pgbouncer-you-may-need-a-connection-pooler-sooner-than-you-expect/
We create so many connections that a pooler may make sense? Dunno
BUT I did stumble upon pgbouncer (reminds me of dbslayer from NYtimes 10+ yes ago?) wish rails did not have so many begin/end transactions and were statement centric but I digress. https://www.percona.com/blog/2018/06/27/scaling-postgresql-with-pgbouncer-you-may-need-a-connection-pooler-sooner-than-you-expect/
We create so many connections that a pooler may make sense? Dunno
Lol. Plexiglass. Thnx Siri
Aah. Pipelining. https://www.techempower.com/blog/2018/10/30/framework-benchmarks-round-17/
I’d imagine some programming languages have this while others do not. Also, some forms of pooling would probably work better for this than others
We have so few clients and our number of queries are high per client. Also the query complexity is high per call. Our app is probably not a good contender.
Does seem like a concept of interest
I’d imagine some programming languages have this while others do not. Also, some forms of pooling would probably work better for this than others
We have so few clients and our number of queries are high per client. Also the query complexity is high per call. Our app is probably not a good contender.
Does seem like a concept of interest
Aah. Maybe this is the adequate record as be prepared statement stuff. But that was a long time ago
Think this is moot because rails loves to dynamically create sql (there are always tons of ? Per request that are dynamically altered - trashing query reuse) wonder if we could use ANY instead of IN to pass a single array instead of passing a variable number of parameters.
Yea. This is probably too low level and fighting too much with the nature of rails
Think this is moot because rails loves to dynamically create sql (there are always tons of ? Per request that are dynamically altered - trashing query reuse) wonder if we could use ANY instead of IN to pass a single array instead of passing a variable number of parameters.
Yea. This is probably too low level and fighting too much with the nature of rails
And in conclusion. My question of “how hard is it to just add this pipelining to the driver?” Has an easyish answer. You’d probably need to rewrite the driver to not use libpg and need to write some code that leverages this - that is a bit much. And ruby is slow. So it looks like libpg needs to be extended to handle a better c api for pipelining. Which seems like someone would have already done this... guess that is my next step before giving up