[sehrope]

Regarding the JVM performance:

> Under minimum load the best page rendering time was 233ms

Regarding the node.js performance:

> Under minimum load the best page rendering time was 249ms

What the heck are they doing that takes 250ms that could possibly be app code related? That's a lot of CPU usage if its actually doing CPU-bound work. Since these are web apps that's obviously not the case. The request time is going to be mostly waiting for external resources (DB, message queue, etc).

Without knowing how much time is spent on those external requests these numbers are meaningless.

Language choice is no where near as important as your DB-access patterns (and more generally DB performance, caching, etc).

If every request you process involves serially accessing a 50-100ms external resource four or five times then it will always take 250ms (though you could increase parallelism of multiple requests if done right).

[cgh]

The fact that both implementations are ridiculously slow tells me to look for commonalities. In this case, how much do you want to bet that there are some truly scary, gigantic and all-but-incomprehensible stored procedures underlying everything?

[Xorlev]

No bet. :)

[kalleboo]

> Language choice is no where near as important as your DB-access patterns (and more generally DB performance, caching, etc).

I bet they have a really crappy backend storage system for account history/data.

We have a PayPal transaction history with a low 6 digits record count. Searching for a specific email address, name, or transaction ID can take literally minutes. Exporting a transaction history CSV takes hours.

[Negitivefrags]

It only gets worse from there.

When we exported a CSV of our transaction history there were entries missing. We knew this because each line has a running balance and it wasn't adding up with the line before it.

When we told our paypal account manager about this it triggered an investigation. They claimed they had never seen it before and they sounded very worried about it.

They then told us that they have multiple different databases with transaction histories and that they were not consistent. They said that they had investigated the problem and found that it affected only a small percentage of customers.

They then pointed us to another CSV export form that doesn't seem to be able to be accessed via the normal UI and were told that this one would give us correct results. Unfortunately we were unable to export an entire year at once with this form as it seems to have some kind of time limit.

We had to export our history in little chunks that would take hours each. We asked our paypal account manager to prepare the CSV for us after finding this out, but she refused.

Having a large number of transactions in paypal sucks very bad.

Compare this to Stripe that proactively emailed us saying that they had noticed that queries for filtered transaction sets were taking a very long time so they had done some optimizations and were asking us to see if it had improved.

[camus2]

> Language choice is no where near as important as your DB-access patterns (and more generally DB performance, caching, etc).

i'm pretty sure the paypal node app does not directly access the db , the node app talks to a private api.

[Helianthus]

That doesn't really change the point, it just wraps it with a layer of abstraction.

[empthought]

Well, it adds another opportunity for a chatty API to add latency.