Yes! That’s one of the things I definitely want to see in OSM-NG :-)

@mmd exactly!

@快乐的老鼠宝宝 I don’t believe the Python will be a performance issue here - most of the heavy lifting is done by the postgres database. Also, OSM-NG uses https://cython.org to further improve performance by reducing Python interpreter overhead. 1) The demo site will be available at the end of May. Although, it won’t be feature-complete - more focussed on technical demo and development tests. 2) The export scale is not currently implemented, I wanted to simplify the share experience. The initial demo site will only consist of shortlinks. I’ll see what people have to say and go on from there.

I agree the file picker could be nicer. I’ll write it down in my notes, since I am currently focusing on reaching feature parity with the current website. About the other suggestion, that’s a good catch. I made a quick fix https://img.monicz.dev/-P5SbRuQJa4 and it looks good :-)

Please fix the maximum password length of 12 characters :-)

@rtnf This is something that’s already planned 🫢. I want to take inspiration from the osm deep history, but make it an integral part of the website project and interface. We shouldn’t have such core features being served on 3rd party sites.

@Woazboat, Hey! I originally also thought so, but since it happened 2nd time, I just wanted to clarify it further. Honestly it’s not a big deal, people are busy and sometimes forget. 🙂👍

(If the feedback is: some parts of the website don’t work properly; then yes, I know. If it were otherwise, the website would already be open for public access.).

@GovernorKeagan @PlayzinhoAgro ❤️!

@PlayzinhoAgro, I have noted down your suggestions and I will create GitHub issues when the time comes. They will not be lost!

I will definitely try it out! Looks promising 😃. Thanks!

I also enjoy making 360 streetview. It’s a really fun and unique hobby! 👍👍👍

As before, you are testing parts of the application that are under development. I really can’t help you with troubleshooting work-in-progress software.

Here’s a resource to help you: the Systems Development Life Cycle (SDLC). This concept is similar to how OpenStreetMap-NextGen is developed and might clear things up for you.

@rtnf I am actively working towards that goal. Whenever it’s ready, I’ll make sure to include it in a diary 🙂. It’s really nice to see interest - Thank You!

@o_andras They are different deployment environments. Local is the same environment as the NextGen code has been tested in (local machine). I included other deployments for extra comparison because the current osm-website deployment documentation seems to be outdated and I did not want to make the benchmark so one-sided.

@mmd Isn’t production also using docker images? I followed the project’s deployment documentation so I assume that’s the issue (that it differs from the actual deployment). I am looking forward to revisiting the benchmarks once details like that are sorted out. That’s also the reason why I started with such simple benchmark first, to test out the waters. I am only planning on benchmarking applications as deployed using official instructions.

@Woazboat Those are really good suggestion! I will apply them during my work on the 2nd benchmark some time soon. The full set of benchmarks will consist of 4 tests with increasing level of complexity. This first test focused just on static and unauthenticated requests as this part of the NextGen codebase is unlikely to be changed.

@Firefishy I suppose it’s better to say that thrice than twice 👍

@Andy Allan, here when talking about configuring Phusion Passenger, the link seems to be dead, and there is no other guidance on reproducing that part of the production behavior. When you are at this, could you please check if this section is generally up-to-date? Many steps have been unchanged for 10-11 years and my recent benchmarks show a 2-4x performance gap between local and official deployments. I am not quite sure if such a difference would be purely a result of not using Phusion Passenger, perhaps something else is outdated too?

@Andy Allan, I have added the correction. I am Ruby-noob and when I originally reviewed this ActiveRecord class I misunderstood how it works. The new system makes a lot of sense, I like it!

I am currently super-focused on the NextGen development as I want to reach the stable-ish release and invite new contributors to join in. I don’t know Ruby at all so I would be quite useless in contributing to the current codebase.

However, I see a great starting point for collaboration that would benefit both projects. I would need to get some help with benchmarking the openstreetmap-website project. The current deployment documentation seems to be slightly outdated and I failed to reproduce the official deployment scenario. This could additionally involve writing scripts for populating database with test user data etc. Basically something that will make the benchmarks more realistic in terms of database index usage.

By the way, I’m a bit surprised not to see any Javascript of CSRF issues (we’ve been fixing some of these in the past). Is this still to come?

Hey, I did not review the HTML templates. The application already has a well defined CSP so impact of such issues would be close to none.

“(…) as any other performance numbers of synthetic benchmarks”, not really. Small p values are least impacted by external factors, meaning that if you want to measure absolute CPU performance they would be the most reliable. Big p values are most impacted by external factors, meaning that you would want to use them to measure overall system performance. Because of that, they are mostly meaningful when measured in actual deployment scenario with real requests. It’s very difficult (if possible) to mimic actual system usage during synthetic benchmarks.

Hey! I believe the p95/99 during synthetic benchmarks would be at best non-informative and at worst misleading. Those numbers are easily impacted by background load and are best if measured during real usage. OpenStreetMap-NG will measure those numbers after deployment on real requests (it includes optional Sentry tracing integration). You will need to wait a little bit more to see them. I don’t know how to get those numbers out of osm-ruby though. As for memory utilization, I agree that it would be nice to see it, but for an average map user, it doesn’t matter. And because of that, it’s not currently on my list of priorities.

“We don’t have to agree with every design decision right now, because that can all be tweaked later.” Exactly this! I am trying to optimize my time by implementing the ideas that make the most sense to me from the get-go - as a Proof of Concept for later discussion, rather than coding the website one-to-one and then working on improvements. My goal for this project is to: do first, talk second. 🦀

I have gone ahead and investigated the issues today 🙂. I removed the global LD_LIBRARY_PATH override, which is now only applicable to the Python process and nothing else. This should get rid of any potential conflicts you have experienced (you may need to reset your env: rm -r .venv). Regarding the StrEnum issue, this is most likely because FastAPI expects “str, Enum” type instead of the one that is currently used. I will fix it whenever I work on that portion of the code. Nonetheless, I would recommend waiting for the official documentation to avoid unforeseen issues and unnecessary stress — for both of us 😃.