Go's performance is great, and hearing good things about it, does any one have any experience on the type of applications this language is meant for?.
Web Framework Benchmarks
291–300 of 415 posts
Re: Web Framework Benchmarks
#292I roughed up a flask benchmark but I haven't been able to test locally.
If you want to help, check out this pull request: https://github.com/TechEmpower/FrameworkBenchmarks/pull/14/f...
Re: Web Framework Benchmarks
#293I'm torn about this. On the one hand, while I've known my framework of choice (Rails) is slow, I didn't know how much slower it could be in the grand scheme of things. But on the other hand, I'm more shocked by the difference between EC2 and dedicated hardware (10x improvement with rails), and even 89 requests per second (20 query benchmark on EC2) is still a decent amount of traffic. (Plus this doesn't count any opt…
Don't be too disappointed about Rails. As a rule I like to divide this world into "Featureless" and "Featurefull" products. When you use Rails, you're aiming to pile up features. You want to react to Product managers, to users, you want to work fast and satisfy the needs of customers - or else you won't have anyone to build to. In this reality, the fact that you're doing 20req/s is OK. In fact, I'm betting that even…
Also, there are certain features about rails like thin or unicorn that can drastically increase your overall performance. So in that sense, I think it's a lot more complicated to determine.
Re: Web Framework Benchmarks
#294Earlier quoted context omitted.
I think this is a much needed and excellent point to make. Just take a look at how Go dips down when using Webgo.
I used Go's benchmarking tool to compare raw routing performance of various frameworks. The handlers all return a simple "Hello World" string. Here are the results: PASS Benchmark_Routes 100000 13945 ns/op Benchmark_Pat 500000 6068 ns/op Benchmark_GorillaHandler 200000 11042 ns/op Benchmark_Webgo 100000 26350 ns/op ok github.com/bradrydzewski/routes/bench 12.605s I then ran the same benchmark, but this time I modifie…
> Now, imagine I created a third benchmark that did something more complex, like executing a database query and serving the results using the html/template package. There would be a negligible difference in performance across frameworks because routing is not going to be your bottleneck.
If you're performing a DB query on every request, you're doing something wrong. In the real world your app will check Memcached, and if there's a cached response, it will return it. Thus making the framework performance quite important.
Re: Web Framework Benchmarks
#295The wsgi benchmark uses gunicorn, which is fine. But if you are surprised by the so-so performance, know that the worker class can be changed via the -k flag (-k gevent), and may improve performance. Of course, other wsgi servers, like uwsgi, are also available.
Are they not even using gevent? Someone please get these guys off the internet. The are worse than some personal blogs at everything except the comprehensiveness in their low-quality testing.
Re: Web Framework Benchmarks
#296Wasn't it agreed a long time ago that benchmarking against a VM was a bad idea?
Possibly, although we believe it represents precisely what we wanted to test: a realistic production environment. However, we also tested on our physical i7 hardware. Did you happen to scroll down? :)
I did, but didn't see a pretty graph for it. Full production results are interesting, but benchmarks should test on a single variable. A cloud VM adds several to the mix.
Re: Web Framework Benchmarks
#297Earlier quoted context omitted.
Do you think such a configuration could outrun the Vert.x configuration they've posted? I'm not challenging you, I'm just genuinely curious! Because if Play+Akka can outrun Vert.x, then it would be an interesting game altogether...
I think Play, with well-written asynchronous code, could approach the Netty/Vert.x speed. In other words, I'd be willing to trade the ease-of-use of Play for the slight speed impairment vs. writing directly to Netty/Vert.x/etc.
We'd love to test that theory. Can you or any Play expert rewrite our Play code and submit a pull request?
Re: Web Framework Benchmarks
#298Earlier quoted context omitted.
I'm no expert, but I think certain languages/frameworks are better suited to be behind certain servers when high concurrency is tested. E.g. from http://nichol.as/benchmark-of-python-web-servers it seems django would be better served behind gevent.
There are a lot of variables and tweaking that can be done, and it would be nearly impossible to optimize each. Similarly, I was wondering what sort of an effect connection pooling would have, as the out of the box django distribution doesn't do that. It really didn't perform too well in their tests.
At LEAST gevent with session write-through caching, psycopg2pool, Postgres SQL (hello, excellent South support?), no unnecessary middlewares or applications that rely on them (if it's a speed oriented use of Django, we're hosting on a specific API sub-domain, right?). At most, THEN you tune the settings to have an optimum number of Postgres threads staying alive and tweak some gunicorn/nginx max connections parameters for your site. If running all locally, use UNIX sockets. This article is trash when it comes to providing any useful data other than Django that's barely been configured beyond not using SQL-Lite, and who the hell uses that in production, so I don't buy their argument about "oh well we just wanted to see what It'd do out of the box" rhetoric. Might as well benchmark ./manage.py runserver. I wish they'd it right or don't publish, let alone publish to shill their company that doesn't provide what they advertise.
Re: Web Framework Benchmarks
#299I'm curious to see Django results when using the gevent worker for gunicorn. For these type of quick JSON calls, you can see huge performance increases.
[deleted]
Re: Web Framework Benchmarks
#3001) The Python version has some basic newbie coding errors. This sort of code is what Python programmers call "Java written in Python". It may be a valid algorithm in Java, but it's the wrong way to do it in Python. Code like this will work, but it will be slow. Depending on the size of "queries", you are potentially allocating gobs of memory in two different places for no reason, and then throwing it away without using it. I wouldn't be surprised if the examples in other languages had similar problems.
2) The JSON serializer in Django 1.4 uses a method which is known to be very slow, but which is easily portable across different platforms and works with older versions of Python. They no doubt included for easy bundling. In a real application you would probably want to simply use the normal JSON serializer from the standard library (which is many times faster).
3) The examples are little more than "hello world". I did some benchmark tests with several Python async frameworks, Pypy, and Node.js for an application I was working on. With small JSON objects there wasn't much difference in performance. Once you started using large JSON objects the performance lines for all versions were indistinguishable from each other. The performance bottlenecks were in libraries, and those standard libraries were all written in 'C', so interpreter versus compiler versus JIT made little difference.
4) The problem with "toy" examples is that in real life there are two performance factors which must be taken into account. Think of as y = mx + b. With a toy example you are probably only measuring "b". With most real life applications it's "m" that matters. There are often different optimization approaches that are best for varying ratios of "b" and "m". You have to know your application intimately and benchmark using data which is realistic for that application.
Python has a reputation for being "easy to learn". However, it is "easy" in the sense of being able to hack something together that works without knowing very much. There can be several different ways of doing things and doing it one way versus another way can mean a difference in performance of several orders of magnitude. The same may be true for some of the other languages, but I haven't examined them in enough detail to say.