Hi James, I think I was not clear enough in the previous email, maybe due to the list's moderator that is blocking links.
The success case I am looking for is exactly about focusing on one perspective - the most painful performance related problem you have. Please take a look at the other cases we have published: - Not every optimization takes months: openIMIS performance improved by over 95% in just one week! - Not every optimization takes months: How we boosted a key API endpoint by 56% in just one week - How we improved OpenLMIS import performance by over 90% I would like to have one more about Fineract. Are you able to identify such a place? Regards, Jakub. On Fri, Apr 4, 2025 at 2:14 AM James Dailey <jdai...@apache.org> wrote: > Jakub - Thanks for sharing the perspective. > > I think the challenge is that from a project perspective, having another > audit is useful but doesn't actually advance the project if we don't have > the follow up. It is a form of contribution, so I am supportive of it.... > but ... > > With a number of people looking at the code and project and identifying a > myriad of issues over a long period of time, it's pretty clear that > identifying more issues isn't the solution. > > What might be useful is to run a code "audit" and focus on one perspective > - such as making the code more maintainable and approachable. The > "performance" gain we need is speed of developer onboarding, test > environments, speed of builds. It could be a good baseline audit, and > could focus attention on an important area of improvement which could then > speed up addressing other issues. > > Also, any "audit" results may result in some security issue identification > - so please follow best practice and send those to <security AT > fineract.apache.org> private list. > > Thanks, > James > PMC > > > > On Thu, Apr 3, 2025 at 12:24 PM Jakub Sławiński > <jslawin...@soldevelo.com.invalid> wrote: > >> >> Hi, >> >> Unfortunately, it is not what I am looking for. >> The set of old issues from the backlog, general areas for improvement or >> challenges older than a decade - these do not sound like something >> important or valuable to anyone. >> >> I think I haven't shared the bigger context with the community. >> >> What we are looking for is to get one more success case for the service >> we are currently tuning up: Java Performance Scalability Audit >> >> What business problems are we targeting? For example: >> 🚀 *Performance-Related Issues* >> >> 1. >> >> *Slow Application Response Times* – Users experience delays, leading >> to frustration and lost engagement. >> 2. >> >> *High Server Costs Due to Inefficiencies* – Unoptimized code leads to >> excessive resource consumption, increasing infrastructure expenses. >> 3. >> >> *Frequent System Crashes or Downtime* – Poor memory management, >> threading issues, or resource leaks causing instability. >> 4. >> >> *Unoptimized Database Queries* – Slow or inefficient database >> operations causing bottlenecks. >> 5. >> >> *Poor User Experience (UX) Due to Lag* – Slow interactions drive >> users away and harm customer retention. >> >> 📈 *Scalability Challenges* >> >> 6. >> >> *Inability to Handle Increasing User Load* – System struggles with >> growth, leading to degraded performance. >> 7. >> >> *Lack of Proper Load Balancing and Caching* – Inefficient resource >> distribution leading to slow responses under load. >> 8. >> >> *Unscalable Architecture* – Design flaws preventing efficient >> horizontal or vertical scaling. >> 9. >> >> *Microservices Bottlenecks* – Inter-service communication issues >> causing slowdowns or failures. >> 10. >> >> *High Latency in Distributed Systems* – Delays in API responses, >> messaging queues, or inter-service communication. >> >> 🔍 *Technical Debt & Code Maintainability* >> >> 11. >> >> *Legacy Code with Performance Bottlenecks* – Old, unoptimized code >> making enhancements difficult. >> 12. >> >> *Lack of Monitoring and Profiling* – No visibility into performance >> issues until they cause failures. >> 13. >> >> *Memory Leaks and Inefficient Garbage Collection* – Leading to >> crashes and sluggish performance over time. >> 14. >> >> *Threading and Concurrency Issues* – Poor multi-threading >> implementations causing deadlocks or slow execution. >> 15. >> >> *Security Risks Due to Inefficient Code* – Performance weaknesses >> that also expose vulnerabilities. >> >> 💰 *Business Impact & Cost Reduction* >> >> 16. >> >> *Lost Revenue Due to Performance Issues* – Sluggish applications >> reduce conversion rates and customer trust. >> 17. >> >> *Missed SLAs (Service Level Agreements)* – Performance problems >> leading to contractual penalties or lost clients. >> 18. >> >> *Unnecessary Infrastructure Scaling* – Overprovisioning cloud >> resources instead of optimizing code. >> 19. >> >> *Poor DevOps Efficiency* – Developers wasting time troubleshooting >> performance instead of building new features. >> 20. >> >> *Long Release Cycles Due to Performance Issues* – Slow debugging and >> testing caused by unoptimized code. >> >> >> >> What would I like to see as the results of this particular success story? >> For example: >> >> 1. Cut infrastructure costs by 50%. >> 2. Increase the number of clients/transactions handled in a stable manner >> without changing infrastructure by 100%. >> 3. Decrease the time needed by critical operations by 70%. >> >> What do you think? Are there any business problems we could help you with? >> >> Please contact me directly if you are ready to check our services. >> >> >> Regards, >> Jakub. >> >> >> -- >> >> *Jakub Sławiński* >> Chief Technical Officer >> jslawin...@soldevelo.com / +48 514 780 384 >> >> >> *SolDevelo* Sp. z o.o. [LLC] / www.soldevelo.com >> Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland >> Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41 >> > -- *Jakub Sławiński* Chief Technical Officer jslawin...@soldevelo.com / +48 514 780 384 -- * SolDevelo* Sp. z o.o. [LLC] / www.soldevelo.com <http://www.soldevelo.com> Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41
