cgbystrom

Netty is not the problem. Java NIO has that limitation. And performance isn't in any way bad, just that there's more to extract (I believe).

It turns out that Java synchronizes on accept() capping the number of socket accepts that can made each second on a single port.

But even if that would be solved or if you used something more low-level like, say nginx, you'd still be limited of how fast you can accept().

Try using ApacheBench and hit one server with keep-alive on and off respectively. Even nginx, which I would say is a performant web server, show quite some discrepancies between having to reconnect each time and having a permanent connection.

I file this under the penalty of having to set up and tear down a socket each time. Something that only can be avoided by doing less reconnecting.

I could of course be wrong but these are the findings from doing performance testing and discussing it on the Netty mailing list. But I'd gladly accept suggestions on how to improve this situation for our service.

An ordinary Comet server with long-poll can actually end up eating quite some CPU.

I run beaconpush.com which is a cloud-based service for browser push messages. We're based on Netty and Java, which works out well for us. We've looked at Erlang and wrote some initial prototypes in it but Java became our language of choice. Mainly because we knew it and had some experiences with Netty, a NIO library for Java. Netty did also outperform Erlang and mochiweb (both vanilla configured).

Anyway, the problem tend to be with long-poll that users re-establish their connection back to the servers each time they receive a message or navigate to another page (or reload the page). This end up taking a big toll on the system. We're to some extent limited to how fast we can perform accept() on our sockets.

If you use long-polling with multi-part you can get away with sending more messages on a single established connection (it becomes request/response/response/response or similar). That can reduce the system load and the use of WebSockets can eliminate the use of reconnections altogether (disregarding any page reloads).

Facebook's use of AJAX navigation (i.e not reloading the entire page when user clicks on links etc) also reduces this load. This due to not having to re-establish a connection each time a user reloads a page.

So yes, we're actually CPU bound by the accept() behavior (at least to how the JVM does accept()). But would our connection be more permanent in nature then no, we would of course be more I/O bound if not completely.

You host a lot of open-source projects and GitHub itself is even built on it.

What would you say is the best way to monetize your open-source product?

I find Celerity with its completely headless browser much more interesting for doing acceptance/functional tests.

Sports both CSS and JavaScript without requiring rendering.

Thanks for your feedback!

1. Right now we offer up to one million messages for free. After that, we charge per each initiated million messages delivered. Meaning, if you send 900 000 you will be charged for 1 MM. Much how Amazon bills hours on EC2.

2. Well, sure. Our endpoint server (where all browsers connect) is written in Java. We're using the Netty framework, which we are incredibly happy with. Highly recommend it for doing high-performance networking in Java. Also, using the JVM instead of, say node.js, makes it very easy to utilize all our CPUs.

The user-facing website is implemented in our own framework called Planet. Developed in-house using Python with focus on real-time web sites. Both Beacon and Planet share the same underlying push technology and we have some major customers using it. You can read more about it at http://www.esn.me

The REST API is also implemented in Python and coordinates the message sending among our end-point servers. It's quite simple actually, just 200 lines of code.

3. Sounds like a good idea. It's just a few lines of code that's needed to integrate it. But yeah, a simple chat app hosted on GitHub would be helpful for newcomers.

-- Carl

For Java reloading, I'd recommend you check out http://www.zeroturnaround.com/jrebel/

I think Alex confuses "scaling in the small" with performance. Rewriting Starling in Scala most probably improved Twitter but it did it make it more scalable?

To me as an outsider, it sounds more as Starling (or Kestrel) got its performance upgraded, not scalability.

May sound pedantic, but it's important to differentiate performance from scalability.

This the exact reason why I dumped Twisted in favor for gevent (greenlet/coroutine-based NIO library)

Paul Tyma discusses some other myths regarding evented vs threaded servers: http://www.mailinator.com/tymaPaulMultithreaded.pdf

In comparison, how many hosted repositories do BitBucket have?

Tried Google with no luck.

Well, you can either monkey patch the socket module OR do the callback hell + completely alienate you from the Python ecosystem.

I'm not saying these are perfect solutions. But gevent with greenlet addresses the problem at the right level. Making developers care about asynchronous I/O only when they need it. Not the other way around as with many other async/event based frameworks.

We're actually using it for our real-time web framework Planet (http://www.esn.me) and our cloud-hosted WebSocket service, Beacon (http://beaconpush.com). So far, so good!

That must be the biggest cheat sheet I've ever seen!

But good work, will come in handy when playing with Clojure.

Replacing just the internals could work. But don't forget that both the battery and exterior gets worn down quickly.

Great, now I can actually host my private yum/apt repository on S3. These are the different keys you can use in your bucket policy conditions:

aws:CurrentTime — For date/time conditions (see Date Conditions)

aws:SecureTransport — Boolean representing whether the request was sent using SSL (see Boolean Conditions)

aws:SourceIp — The requester's IP address, for use with IP address conditions (see IP Address)

aws:UserAgent — Information about the requester's client application, for use with string conditions (see String Conditions)

aws:EpochTime — Number of seconds since epoch.

aws:Referer — Same the the HTTP referer field.

(from http://docs.amazonwebservices.com/AmazonS3/latest/dev/Access...)

Here we go again. Getting a bit tiresome hearing about this "durability issue".

I really don't understand the problem. No, MongoDB isn't durable the same way MyISAM/InnoDB is with MySQL.

But I think that is clear as day, certainly no news to me when choosing MongoDB.

Been running it in production for 3 months, working fine. If it for some reason would be data loss or corruption, I wouldn't come crying to the devs. I know what risks I took when making the decision.

If the backups aren't there I can only blame myself when such event happen.

Doing headless integration testing really is superior. Requiring one machine per concurrent test isn't scalable. Sure, works great for your weekly/daily test. But if you want integration testing to run at every commit it's not going to work.

I've done some experimenting with Celerity (headless integration testing with JS support) and it works quite well. Can even emulate CSS and it scales much better. One thread becomes one test. So running 50 tests in parallel on one machine is no problem. This really is a requirement for me if you want it to work with CI.

Celerity is based on Watir (similar to Selenium) and Ruby. See http://celerity.rubyforge.org/

List of changes (from the mailing list)

What's new:

   * fixed a bug with subdomains that was caused by the inability to
     specify the server name.  The server name can now be set with the
     SERVER_NAME config key.  This key is now also used to set the
     session cookie cross-subdomain wide.
   * autoescaping is no longer active for all templates. Instead it is
     only active for .html, .htm, .xml and .xhtml.  Inside templates
     this behaviour can be changed with the autoescape tag.
   * refactored Flask internally. It now consists of more than a single
     file.
   * flask.send_file() now emits etags and has the ability to do
     conditional responses builtin.
   * (temporarily) dropped support for zipped applications.  This was a
     rarely used feature and led to some confusing behaviour.
   * added support for per-package template and static-file directories.
   * removed support for create_jinja_loader which is no longer used in
     0.5 due to the improved module support.
   * added a helper function to expose files from any directory.

Links:

     Online Documentation: http://flask.pocoo.org/docs/
     Downloadable PDF: http://flask.pocoo.org/docs/flask-docs.pdf
     Website: http://flask.pocoo.org/
     On Github: http://github.com/mitsuhiko/flask
     PyPI Record: http://pypi.python.org/pypi/Flask

http://flask.pocoo.org/mailinglist/archive/2010/7/6/ann-flas...

Much of Java's complexity is cultural and not imposed.

Take the Java web framework, Play, as an example. http://www.playframework.org/

http://beaconpush.com is also a similar service.

Languages aside, I don't think the world needs another VM. Can't people just target an existing one? Please?

To me it sounds that BigPipe is as applicable as Flash or GWT - solutions already known for their problems with SEO. However, if that's not a problem for you then it's probably a good optimization for your site.

Keeping two different output formats for a site (one for crawlers and one for humans) sounds complex. To date, none of the sites I've developed could have justified such overhead in development.

It's not easy balancing on the bleeding edge.

Right now I've already made http://beaconpush.com support two different versions of Web Sockets implemented by different versions of Google Chrome. (There were differences in the handshake origin URL).

Don't get me wrong though, I'm not complaining. I knew what could happen. It's just that the hype surrounding Web Sockets rarely mention these more cumbersome details of the protocol still being a draft.