search

mcpa-stlouis / hack-the-arch

Welcome to HackTheArch! A free open source scoring server for cyber Capture the Flag competitions!
https://hackthearch.herokuapp.com
MIT License
67 stars 28 forks source link

General Cache #43

Open jetbalsa opened 6 years ago

jetbalsa commented 6 years ago

I didn't spot one, but does the platform have an internal cache for things? page loads on my end are getting a little slow under problems due to the amount of challenges I have added (up to 151)

Memcache or Redis would be suggested.

paullj1 commented 6 years ago

We have implemented a simple cache for what I expected to be a bottle neck (calculating scores), but not for the challenges. The problem is that the current implementation makes several queries for each problem, which should be changed without a doubt. I just honestly never expect > 100 challenges.

jetbalsa commented 6 years ago

Leave it to me to break things :) My CTF is still two months out so I'm doing all kinds of testing of the platform

paullj1 commented 6 years ago

I really appreciate the feedback. It's good to have actual use cases that occur more frequently than once per year. That last commit implements the built-in rails caching for each problem page. That might start to solve your problem. I won't be able to generate a test case that large until this weekend (I'll automate it, but writing the automation won't be trivial). If you get a chance, see if that scratches your itch. The commits are in the 'dev' branch.

paullj1 commented 6 years ago

Also, worth mentioning, the cache will only actually work in a "production" environment... so you'll have to run it inside the container or on Heroku to test.

jetbalsa commented 6 years ago

Nice, I am running the app in "Production" just using a .env to set all the env vars I need beforehand

Also, I'm running my CTF from an ARM64 2GB Scaleway and its been doing pretty well, Just docker tends to not work to well in that method.

On Fri, Feb 16, 2018 at 6:55 AM, Paul Jordan notifications@github.com wrote:

Also, worth mentioning, the cache will only actually work in a "production" environment... so you'll have to run it inside the container or on Heroku to test.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mcpa-stlouis/hack-the-arch/issues/43#issuecomment-366216920, or mute the thread https://github.com/notifications/unsubscribe-auth/AAxE1PpWL0gdSeFNW1h-QxrQibNFyWlyks5tVWzIgaJpZM4SG-iN .

jetbalsa commented 6 years ago

RAILS_ENV=production RACK_ENV=production RAILS_SERVE_STATIC_FILES=enabled LANG=en_US.UTF-8 PORT=3000 SSL_KEY=certs/server.key SSL_CERT=certs/server.crt DATABASE_URL=postgresql://xx:xx@localhost/postgres REDISTOGO_URL=redis://127.0.0.1:6379/ HOST=ctf.bsidesroc.com

On Fri, Feb 16, 2018 at 7:21 AM, Forrest Fuqua email@jrwr.io wrote:

Nice, I am running the app in "Production" just using a .env to set all the env vars I need beforehand

Also, I'm running my CTF from an ARM64 2GB Scaleway and its been doing pretty well, Just docker tends to not work to well in that method.

On Fri, Feb 16, 2018 at 6:55 AM, Paul Jordan notifications@github.com wrote:

Also, worth mentioning, the cache will only actually work in a "production" environment... so you'll have to run it inside the container or on Heroku to test.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mcpa-stlouis/hack-the-arch/issues/43#issuecomment-366216920, or mute the thread https://github.com/notifications/unsubscribe-auth/AAxE1PpWL0gdSeFNW1h-QxrQibNFyWlyks5tVWzIgaJpZM4SG-iN .

paullj1 commented 6 years ago

Awesome! Did the caching improve the performance? Yeah, it looks like ARM64 isn't "officially" supported. Does it not build, or does it just not work?

jetbalsa commented 6 years ago

Arm64 is fine outside of docker, ill look into it more for you, scaleways are amazing for setting up small VPS quickly

On Sat, Feb 17, 2018 at 1:20 PM, Paul Jordan notifications@github.com wrote:

Awesome! Did the caching improve the performance? Yeah, it looks like ARM64 isn't "officially" supported. Does it not build, or does it just not work?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mcpa-stlouis/hack-the-arch/issues/43#issuecomment-366460856, or mute the thread https://github.com/notifications/unsubscribe-auth/AAxE1ICktWgy-8suqHGr_M-m6Xjm3Gpoks5tVxhlgaJpZM4SG-iN .

jetbalsa commented 6 years ago

should note, I think getting a docker version running on a rpi might be the best target to approach

On Sat, Feb 17, 2018 at 1:27 PM, Forrest Fuqua email@jrwr.io wrote:

Arm64 is fine outside of docker, ill look into it more for you, scaleways are amazing for setting up small VPS quickly

On Sat, Feb 17, 2018 at 1:20 PM, Paul Jordan notifications@github.com wrote:

Awesome! Did the caching improve the performance? Yeah, it looks like ARM64 isn't "officially" supported. Does it not build, or does it just not work?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mcpa-stlouis/hack-the-arch/issues/43#issuecomment-366460856, or mute the thread https://github.com/notifications/unsubscribe-auth/AAxE1ICktWgy-8suqHGr_M-m6Xjm3Gpoks5tVxhlgaJpZM4SG-iN .

paullj1 commented 6 years ago

Interesting. So getting Docker running these days on arm is pretty straight forward (I've got an old Pi running it right now). I'm just not sure if the image needs to be specified. I'm pretty sure it does, but that's easy. You'd just change the "FROM" directive to: "FROM: arm64v8/ruby:2.5" (I'm currently in the process of overhauling the Dockerfile though, so I'd hold off for a few minutes).