New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Genie v1 prod with own renderers #1
Conversation
I thought about the logging. In my opinion, logging is necessary for a production server, so it should be retained. If it makes this slower, then it is slower. |
I found it easier to combine some of your changes with my local changes and commit them separately. |
Oh course re logging. What matters is that: |
I created a ticket about the difference between Genie.jl and HTTP.jl. |
I'm not sure what to do about the logging in tests. Maybe it should be disabled. |
Oh, and another thing re logging is that in production Genie logs to file (which is the right thing to do). So logging needs to be similar between frameworks (either disable file logging for Genie or enable for others). Overall the best approach would be to start off with the requirements for the tests, and make sure every framework meets them. These could be: |
While setup up similarly (same output), logging should not make any difference, given that they use Julia's logger. Disabling should be fine (it will remove noise from both frameworks). Flask should run in the same conditions though in terms of logging. If any framework makes optimizations for logging (eg batching writes or something) these would be then relevant, as they'd employ different/smarter strategies (so maybe Flask?) |
Removing the logging sounds good, at least for the moment. As to Flask, it’s not a good test target. I spent 15 minutes coding it, and the reason was debugging problems when running on a Mac. Flask would also be the one benefiting most from a nginx in front. Nginx won’t happen for a while at least. |
I removed logging. My plan is that I run the official benchmarks always on Google Cloud. I created terraform/ansible scripts that set up the environment. (They don't quite work yet; they install things but communication doesn't work possibly due to firewall rules.) Then I'd have shell scripts that start one of the servers, or the goose attack client. They worked locally, but not yet on the cloud. I'll close this PR as it's no longer serving a useful purpose, but further PRs are welcome. |
This setup produced the best performance on my machine.