Re-posted from: http://thenewphalls.wordpress.com/2014/07/11/web-development-in-julia-a-progress-report-warning-contains-benchmarks/
Continuing my quest to explore the idea of using Julia for web development, I wanted to address some of my own questions around performance and implementation. My two biggest concerns were:
- Should Julia web pages be served by a Julia HTTP server (such as HttpServer.jl) – or would it be better to have Julia work with existing software such as Apache and nginx?
- How would Julia perform on the web compared to the competition?
Addressing the HTTP server question
After some consideration, my personal conclusion is that a server implemented in Julia would be another codebase that would need to be maintained; would mean missing out on tools available to existing server software, such as .htaccess, modules and SDKs; and would ultimately feel like reinventing the wheel. I feel it would be more sensible to leverage existing software that already has active development and has been tried and tested in the wild.
Following from this, I knew that my primary performance concern should be the interface between the server and Julia. In my previous posts, I was using Apache and running Julia via CGI. CGI is slow enough, but a known fact of Julia is that the binary is somewhat slow to start due to internal processes/compilation. I figured that FastCGI would be the next best option – and as there are no existing solutions (except for an incomplete FastCGI library), I set about creating a FastCGI process manager for Julia.
FYI: I’ve decided to release all of my web-Julia-related code under the GitHub organisation Jaylle, which can be found at https://github.com/Jaylle. Currently only the FPM and CGI module are available, but in future that’s where I’ll add the web framework and whatever else gets developed.
I plan to elaborate on the process manager more in a future post, but in short there are two parts:
- The FastCGI server / process manager (coded in C). This accepts requests and manages and delegates to the workers.
- The worker (coded in Julia). This listens for TCP connections from the FPM, accepts a bunch of commands and then runs the requested Julia page/code.
This way, there’s always a pre-loaded version of Julia in memory, circumventing any startup concerns (unless a worker crashes, of course).
Some early benchmarks
Now that the FPM is in a usable prerelease state, I wanted to see how it could perform compared to the alternatives. In this case, I chose PHP (obvious) and Python. I chose Python because the name often crops up in Julia discussions and there’s a FastCGI module available for it.
To run these tests, I used the Apache ab tool from my Windows machine. The server is a cheap 1-core VPS running CentOS 6 64-bit.
In all tests, the server software used was nginx. For the languages, I used PHP-FPM for PHP, Web.py for Python and the Jaylle FPM for Julia.
The individual tests are superficial and the results anecdotal, but I just wanted something to give me an idea of how my FPM performed by comparison. To elaborate:
- Basic output: Printed “Hello, [name]” – with [name] taken from the query string (?name=…)
- Looped arithmetic: Adding and outputting numbers in a loop with 7000 iterations.
- Looped method calls: Calling arithmetic-performing methods from within a loop with 7000 iterations.
Below is a table of the results. The numbers shown are requests per second; higher is better.
| Basic output | Looped arithmetic | Looped method calls | |
| PHP | 28.17 | 11.29 | 10.92 |
| Web.py (Python) | 24.61 | 7.92 | 7.25 |
| Jaylle (Julia) | 24.85 | 5.27 | 5.12 |
The only thing that I can say from these results is that I’m comforted seeing that my FPM’s performance isn’t obviously terrible compared to the others, but that there’s probably some work that does need to be done to at least get it up to the same level as Python, if not PHP.
In other news, I’ve realised (4 years late) that all the cool people use Twitter now. I therefore have started actively using my account. I can’t promise that following me will improve your quality of life, but feel free to give it a chance: @phollocks
Coming soon: FPM documentation + writeup (as soon as I’m comfortable enough to tag a release).
