cgbystrom

With our team, we also found shared folders performance to be too low. Our Python framework/app is very read-heavy and stat() a lot of files (the Python module loading system isn't your friend)

We ended up using the synchronization feature in PyCharm to continually rsync files from native FS into the VirtualBox instance. Huge perf improvement but a little more cumbersome for the developers. But so far it has been working good, PyCharm's sync feature does what it is supposed to.

There's also Locust, a Python powered load testing tool similar to this. It's focused on simulating user behavior rather than hitting specific URLs. This allows for much more true-to-life testing.

We used it to load test Battlelog (the online service for Battlefield 3) and successfully simulated over 2 million concurrent users hitting the service using EC2. See http://locust.io for more info. (Disclaimer: I'm one of the authors)

Totally agree about having smaller and more contained apps.

I used https://github.com/cgbystrom/jersey-netty for a one-off project wiring Jersey together with Netty. But it's not async :)

Without need to discuss security implementations - no.

Protocol handlers are a pretty shitty way of interfacing with desktop apps. There's no two-way communication and no error handling. Lots of potential screw-ups and incompatibility issues will/can happen. Sure, they don't require a browser plugin but that's about the only advantage.

I would strongly advise not to base your push mechanism solely on Web Sockets. Despite advances modern browsers are making with Web Sockets support, the current compatibility is not there yet.

For starters, IE has no support, though that is starting to change with IE10. But the biggest issue is with personal firewalls / corporate proxies. These are unfortunately quite horrible at handling Web Sockets. Many popular firewalls such as avast! and Bitdefender can’t handle the WS protocol and completely blocks traffic despite browser support and it being valid HTTP. The socket.io guys did some extensive research on what firewalls are causing these issues. I don’t think their list is exhaustive but it features most major personal firewalls out there. Have a look at https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-f... , it's no reading of joy.

I’ve deployed quite large installations of Beaconpush (a push server incidentally based on Netty as well). First going from Web Sockets with fallback, over to pure WS and we’re looking at going back to using fallbacks once again due to these incompatibility issues. This time we are looking at using SockJS instead of rolling our own (to be fair, there were no open-source libs doing this when we started). I’ve ported SockJS to Netty (https://github.com/cgbystrom/sockjs-netty) and it’s working although I wouldn’t say it is production ready.

I urge you to have a look at SockJS and socket.io. Personally I prefer SockJS since it aims at emulating the Web Socket interface and nothing more as compared to socket.io (which adds a pub/sub layer). Also, it does not rely on a Flash fallback (which is another story). The socket.io guys are however working on engine.io, which will split the transport fallback mechanisms of socket.io to a separate library. That's a good idea, but it still uses Flash and IMHO a more complex "transport upgrade".

Redis should get an an HTTP API. Would enable you to implement something like this purely in the browser. UIs are really useful from a sys admin point of view. I can also imagine adoption increasing if Redis supported a UI out-of-the-box.

The authors of Kotlin has explicitly said that fast compilation is a key feature.

A couple of the components used are actually already open-source:

https://github.com/esnme/ultrajson - Super-fast JSON serializer.

https://github.com/esnme/locust - Scalable load testing tool capable of simulating millions of users.

https://github.com/esnme/amysql - 100% async/event driven MySQL driver.

https://github.com/hjlarsson/gevent-memcache - memcached driver for gevent.

Planet Framework is designed from the ground up to be real-time and scalable, but it also uses a lot of existing open-source projects.

For Planet Framework customers, we offer "partner source". Meaning, that customers will get full access to source code and also submit their own patches.

The reason behind "yet another template language" is that we compile down to both Python and JavaScript. Allowing us to render templates both on the server-side and client-side. Sharing templates between these two gets very important when you develop real-time web sites.

(I'm one of the developers behind Planet Framework)

Yes, we do.

Rasmus Andersson wrote a good tutorial on how to set up node.js on EC2 as well. Think it was posted here on HN.

http://rsms.me/2011/03/23/ec2-wep-app-template.html

If the startup isn't considering their first employee a crucial hire then they're doing it wrong.

And if you, as a job seeker, are dependent to land a potentially low-paying job at a startup to get a "real" job, then you probably aren't that "crucial hire" the startup is looking for.

This ain't no charity business.

If you use Pageant with PuTTy you need not worry about what SSH keys for which server.

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.h...

Twitter's "commons" library also features a very good stat package. Presumably used by their own services. It's designed for the JVM, so should work with any JVM language. See http://twitter.github.com/commons/

Have used it successfully implementing stats/metrics in Beaconpush, a real-time user presence server (http://beaconpush.com).

Nice. Would be great if it was available in EPUB format.

In search of performance we also developed a non-blocking MySQL driver for Python (and gevent). It's used by our real-time web framework, Planet (http://www.planetframework.com).

While we could've gotten better performance with more processes, we wanted to stick with one process per core. Given this and a non-blocking driver we naturally got a good performance gain.

amysql, as it's called, is up on GitHub: https://github.com/esnme/amysql

The reason why GitHub has become so popular is due to the fact they put code and developers first. Surfing to a repo doesn't bring some overview or ads page.

Opening a repo actually show useful stuff for me as a developer. The source is there together with an optionally inlined README file, rendered with popular micro markups. Then add the ease of forking and you clearly get something people really like. This style of presentation isn't of course for everybody. But GitHub chose to target developers above end-users.

GitHub could have been "SVNHub" or "hghub" for all I care, the technology is secondary in this case (but close behind).

Sounds awfully a lot like the old http://code.google.com/p/thrudb/ ?

"Thrudb is a set of simple services built on top of the Apache Thrift framework that provides indexing and document storage services for building and scaling websites. Its purpose is to offer web developers flexible, fast and easy-to-use services that can enhance or replace traditional data storage and access layers."

No long under development though.

Doesn't Linux schedule interrupts on CPU0 by default?

I tried enabling RPS/RFS, which to my understanding, did this; load balance the interrupt handling among multiple cores. With this enabled, I saw little to no difference in connection rate. But then again I'm guru, I might as well double check this.

Updated my little "action plan" in the original Serverfault question with this info.

Thanks, noted. Updated the "action plan" in my question at Serverfault.

(I wrote the Serverfault question)

Thanks for the suggestions, here's some clarifications:

* I clarified what hardware I've tested in a comment (see below).

* I've run tests with my server ranging from 10 sec up to 10 minutes. They're consistently bad unfortunately.

* Interesting what you say about dom0/domU. I'm no Xen guru, but the culprit is probably something like that. I've been using a backlog of 1024 for the server tests (set both in Java land and sysctl.conf). The netperf are all defaults, both in terms of run time and backlog. Was actually trying to monitor the backlog somehow, but I'm not sure that's even possible in Linux?

* The server isn't doing anything disk IO-bound so this shouldn't be the case.

* syncookies seems like a good idea, I will definitely try that along with a lot bigger backlog and see if it makes any difference. I'll also try and see if netperf can be tweaked as well to provide a better, isolated test case.

Writing this off as Xen overhead would be such a shame, virtualization should not cause this much overhead. I'll continue investigating!

I've tried it on variety of different servers/hardware using both my server+apachebench and netperf as benchmarking tools.

* On EC2 I've tried the c1.xlarge and the giant cc1.4xlarge. With cc1.4xlarge, I saw maybe a ~10% increase accept() rate. * Two separate, virtualized servers at the office. * A private, virtualized server on Rackspace was briefly tested as well.

A compilation of netperf results are available at https://gist.github.com/985475

Open source at EA: http://gpl.ea.com/

Makes me think of why Backblaze built their own "storage pod". http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-h...

According to them, their storage costs are ~20 times less than those of S3. A bit different use-case for sure. But as wave says, once you become a storage company you will inevitably need to do it in-house to be cost-effective.

(Disclaimer: I'm the project lead on Beaconpush)

Beaconpush is a good alternative for doing this. We support user presence and you can use the API to find out what users are connected. You can even log out users from the API.

We have a contributed Ruby library (called Dimma) made by one of our users. Don't think it's EventMachine based though. Read more at https://github.com/Burgestrand/Dimma

node.js with socket.io is also a nice alternative. Played with it somewhat myself and I like it! But hosting it yourself will make you deal with scaling, deploying, uptime and hosting in general. Not exactly stuff you want to focus on when developing things on a tight schedule.

So if you're asking me, I'd naturally say Beaconpush (http://beaconpush.com) :)

Same for us, their gateway turned us down.

Are you sure it was CheddarGetter that turned you down? I've also been denied but it was one of their supported payment gateways that denied me (even though I applied through CG).

Recently been thinking of changing to Chargify now that they support a payment gateway in Scandinavia. We (http://beaconpush.com, push service for Web Sockets) currently have our custom-built system for recurring payments. It works, but I really don't want to spend time hacking on it. I rather be focusing on our core business of developing our service.

Agree with you on most points.

However on some points I'm not as convinced. Take the DOM abstraction, it works and is implemented by several SPA frameworks. You can design good looking, "desktop class" applications pretty fast. But problem arises quickly when your graphic designers send you those PSD mockups, full of great looking artwork waiting to come to life.

With a normal DOM approach you've always been able to solve this. With hacking some HTML, tuning CSS and a lot of swearing you pull through. But with SPA frameworks that favor "components" over low-level, raw DOM elements things usually aren't as straightforward. Very often you need to start picking apart the provided "ready-made components" to get any work done. Ends up being very contra-productive and usually takes way longer to do.

It has happened to me numerous times before with both GWT and Adobe Flex. Nice and shiny, given you don't try changing the layouts too much. Surely, I'd be one happy camper if this wasn't the case, web development need to move forward. And I hope the goals proclaimed by both Cappuccino and Sproutcore will work in practice some day.

Regarding your other point about routing, departing from the route paradigm will be only be true if what your designing is not a document-centric application. In my world, an SPA can be either document-centric or desktop-like (containing a lot of UI state, as you mention). Think the answer to that is the boring "it depends".

Worth mentioning, many of these issues are stuff we've been trying to resolve with the Planet Framework (http://www.planetframework.com), essentially bridging the gap between client and server.